RELEASE NOTES FOR: 13
====================================================================================================

Notes generated: Fri Oct 01 03:16:24 CEST 2021

Hint: Prefix bug IDs with https://bugs.openjdk.java.net/browse/ to reach the relevant JIRA entry.

JAVA ENHANCEMENT PROPOSALS (JEP):

  JEP 350: Dynamic CDS Archives

      Extend [application class-data sharing](https://openjdk.java.net/jeps/310) to allow the dynamic
      archiving of classes at the end of Java application execution. The archived classes will include all
      loaded application classes and library classes that are not present in the default, base-layer CDS
      archive.

  JEP 351: ZGC: Uncommit Unused Memory (Experimental)

      Enhance ZGC to return unused heap memory to the operating system.

  JEP 353: Reimplement the Legacy Socket API

      Replace the underlying implementation used by the `java.net.Socket` and `java.net.ServerSocket` APIs
      with a simpler and more modern implementation that is easy to maintain and debug. The new
      implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being
      explored in [Project Loom](https://openjdk.java.net/projects/loom).

  JEP 354: Switch Expressions (Second Preview)

      Extend `switch` so it can be used as either a statement or an expression, and so that both forms can
      use either traditional `case ... :` labels (with fall through) or new `case ... ->` labels (with no
      fall through), with a further new statement for yielding a value from a `switch` expression. These
      changes will simplify everyday coding, and prepare the way for the use of [pattern matching (JEP
      305)](https://openjdk.java.net/jeps/305) in `switch`.  This is a [preview language
      feature](http://openjdk.java.net/jeps/12) in JDK 13.

  JEP 355: Text Blocks (Preview)

      Add _text blocks_ to the Java language. A text block is a multi-line string literal that avoids the
      need for most escape sequences, automatically formats the string in a predictable way, and gives the
      developer control over format when desired. This is a [preview language
      feature](http://openjdk.java.net/jeps/12) in JDK 13.


RELEASE NOTES, BY COMPONENT:

tools/javac:

  JDK-8226955: Bad EnclosingMethod Attribute on Classes Declared in Lambdas

      If an anonymous or local inner class is declared inside of a lambda, the `EnclosingMethod`
      attribute on that class refers to the synthetic lambda method rather than to the method that
      enclosed the original declaration. The original method should be considered as the closest
      lexically enclosing method.
      
      The proposed solution to this issue is to point the `EnclosingMethod` attribute of inner
      classes declared inside a lambda to the original enclosing method. The Java compiler was
      updated, so that the `EnclosingMethod` attribute of anonymous or local inner classes declared
      inside a lambda point to the method enclosing the declaration.
      
      The following is the related section in the Java Language Specification:  JVMS 11 4.7.7: It is
      the responsibility of a Java compiler to ensure that the method identified via the
      method_index is indeed the closest lexically enclosing method of the class that contains this
      `EnclosingMethod` attribute.

  JDK-8222335: javac Rejects Class Files with Broken EnclosingMethod Attribute

      javac now rejects class files that have an invalid `EnclosingMethod` attribute, in which the
      name of the enclosing class is not a prefix of the name of the current class, as required by
      JLS 13.1.

  JDK-8226955: Bad EnclosingMethod Attribute on Classes Declared in Lambdas

      If an anonymous or local inner class is declared inside of a lambda, the `EnclosingMethod`
      attribute on that class refers to the synthetic lambda method rather than to the method that
      enclosed the original declaration. The original method should be considered as the closest
      lexically enclosing method.
      
      The proposed solution to this issue is to point the `EnclosingMethod` attribute of inner
      classes declared inside a lambda to the original enclosing method. The Java compiler was
      updated, so that the `EnclosingMethod` attribute of anonymous or local inner classes declared
      inside a lambda point to the method enclosing the declaration.
      
      The following is the related section in the Java Language Specification:  JVMS 11 4.7.7: It is
      the responsibility of a Java compiler to ensure that the method identified via the
      method_index is indeed the closest lexically enclosing method of the class that contains this
      `EnclosingMethod` attribute.

  JDK-8222335: javac Rejects Class Files with Broken EnclosingMethod Attribute

      javac now rejects class files that have an invalid `EnclosingMethod` attribute, in which the
      name of the enclosing class is not a prefix of the name of the current class, as required by
      JLS 13.1.

core-libs/java.util:

  JDK-8217706: Base64.Encoder and Base64.Decoder Methods Can Throw OutOfMemoryError

      The behavior of `Base64.Encoder.encode` and `Base64.Decoder.decode` methods have been changed
      for large arrays. The methods previously threw an unspecified exception, such as,
      `NegativeArraySizeException`. The new behavior throws an `OutOfMemoryError` exception if the
      `encode` and `decode` methods fail to allocate the output array/buffer or memory.

  JDK-8226735: Properties Files Containing Malformed Unicode Was Sometimes Misparsed

      An `IllegalArgumentException` is always thrown now when loading a properties file with
      malformed unicode sequences. Previously, a malformed unicode sequence appearing at the end of
      a line was parsed using the contents of the preceding line, which in rare cases meant it could
      be parsed as a valid (but likely incorrect) sequence.

  JDK-8217706: Base64.Encoder and Base64.Decoder Methods Can Throw OutOfMemoryError

      The behavior of `Base64.Encoder.encode` and `Base64.Decoder.decode` methods have been changed
      for large arrays. The methods previously threw an unspecified exception, such as,
      `NegativeArraySizeException`. The new behavior throws an `OutOfMemoryError` exception if the
      `encode` and `decode` methods fail to allocate the output array/buffer or memory.

  JDK-8226735: Properties Files Containing Malformed Unicode Was Sometimes Misparsed

      An `IllegalArgumentException` is always thrown now when loading a properties file with
      malformed unicode sequences. Previously, a malformed unicode sequence appearing at the end of
      a line was parsed using the contents of the preceding line, which in rare cases meant it could
      be parsed as a valid (but likely incorrect) sequence.

core-libs/java.net:

  JDK-8226239: Pre-JDK 1.4 SocketImpl Implementations No Longer Supported

      Support for custom `java.net.SocketImpl` implementations compiled for Java SE 1.3 and older
      has been removed in this release. This change has no impact on `SocketImpl` implementations
      compiled for Java SE 1.4 (released in 2002) or newer.

  JDK-8223354: JEP 353: Reimplement the Legacy Socket API

      The underlying implementation for the `java.net.Socket` and `java.net.ServerSocket` APIs has
      been replaced in this release. JEP 353 provides all the details on this change.
      
      Every effort has been made to ensure that the new implementation is compatible with the old
      implementation but it is possible that there is existing code that depends on unspecified
      behavior in corner cases where the old and new implementations behave differently. The JDK
      continues to include the old implementation (known as "PlainSocketImpl" or the "plain"
      implementation) to allow such code continue to run. The old implementation is selected by
      running with the system property "`jdk.net.usePlainSockteImpl`" set, or set to the value
      "`true`", i.e. run with `-Djdk.net.usePlainSocketImpl` or `-Djdk.net.usePlainSocketImpl=true`.
      The property can also be configured in the JDK network configuration file, located in
      `${java.home}/conf/net.properties`. The old implementation, and the system property to select
      the old implementation, will be removed in a future release. 

  JDK-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption

      The default implementation of the `supportedOptions()`, `getOption(SocketOption<T>)` and
      `setOption(SocketOption<T>, T)` methods, defined by `java.net.SocketImpl` and
      `java.net.DatagramSocketImpl`, have changed in this release. The default implementation of the
      `supportedOptions()` method has been changed to return an empty set. The default
      implementations of the `getOption(SocketOption<T>)` and `setOption(SocketOption<T>, T)`
      methods have been changed to throw `UnsupportedOperationException`.
      
      Developers extending `java.net.SocketImpl` or `java.net.DatagramSocketImpl` to create their
      own socket or datagram socket implementations need to override these methods to support the
      socket options that the custom socket implementation supports.

  JDK-8225154: Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set

      Developers using the `java.net.Socket.setSocketImplFactory` or
      `java.net.ServerSocket.setSocketFactory` APIs to change the system-wide factories for client
      socket or server socket implementations should note the following changes:
      
      1.  Invoking `ServerSocket::accept` on a `ServerSocket` using a system-default `SocketImpl` to
      accept a connection will always return a `Socket` with a system-default `SocketImpl`. In this
      case, the system-wide factory for client socket implementations will not be invoked to create
      the client socket implementation.
      
      2. `java.net.ServerSocket::implAccept` has been changed to disallow a `ServerSocket` using a
      system-default `SocketImpl` from accepting a connection with a `Socket` using a custom
      `SocketImpl`. It has also been changed to disallow a `ServerSocket` using a custom
      `SocketImpl` to accept a connection with a `Socket` using a system-default `SocketImpl`.
      Disallowing these nonsensical combinations of `SocketImpl` improves reliability in cases where
      an application sets one, but not both, socket implementation factories.
      
      The changes should have no impact on applications that set the same factory for both client
      and server socket implementations.

  JDK-8226239: Pre-JDK 1.4 SocketImpl Implementations No Longer Supported

      Support for custom `java.net.SocketImpl` implementations compiled for Java SE 1.3 and older
      has been removed in this release. This change has no impact on `SocketImpl` implementations
      compiled for Java SE 1.4 (released in 2002) or newer.

  JDK-8223354: JEP 353: Reimplement the Legacy Socket API

      The underlying implementation for the `java.net.Socket` and `java.net.ServerSocket` APIs has
      been replaced in this release. JEP 353 provides all the details on this change.
      
      Every effort has been made to ensure that the new implementation is compatible with the old
      implementation but it is possible that there is existing code that depends on unspecified
      behavior in corner cases where the old and new implementations behave differently. The JDK
      continues to include the old implementation (known as "PlainSocketImpl" or the "plain"
      implementation) to allow such code continue to run. The old implementation is selected by
      running with the system property "`jdk.net.usePlainSockteImpl`" set, or set to the value
      "`true`", i.e. run with `-Djdk.net.usePlainSocketImpl` or `-Djdk.net.usePlainSocketImpl=true`.
      The property can also be configured in the JDK network configuration file, located in
      `${java.home}/conf/net.properties`. The old implementation, and the system property to select
      the old implementation, will be removed in a future release. 

  JDK-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption

      The default implementation of the `supportedOptions()`, `getOption(SocketOption<T>)` and
      `setOption(SocketOption<T>, T)` methods, defined by `java.net.SocketImpl` and
      `java.net.DatagramSocketImpl`, have changed in this release. The default implementation of the
      `supportedOptions()` method has been changed to return an empty set. The default
      implementations of the `getOption(SocketOption<T>)` and `setOption(SocketOption<T>, T)`
      methods have been changed to throw `UnsupportedOperationException`.
      
      Developers extending `java.net.SocketImpl` or `java.net.DatagramSocketImpl` to create their
      own socket or datagram socket implementations need to override these methods to support the
      socket options that the custom socket implementation supports.

  JDK-8225154: Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set

      Developers using the `java.net.Socket.setSocketImplFactory` or
      `java.net.ServerSocket.setSocketFactory` APIs to change the system-wide factories for client
      socket or server socket implementations should note the following changes:
      
      1.  Invoking `ServerSocket::accept` on a `ServerSocket` using a system-default `SocketImpl` to
      accept a connection will always return a `Socket` with a system-default `SocketImpl`. In this
      case, the system-wide factory for client socket implementations will not be invoked to create
      the client socket implementation.
      
      2. `java.net.ServerSocket::implAccept` has been changed to disallow a `ServerSocket` using a
      system-default `SocketImpl` from accepting a connection with a `Socket` using a custom
      `SocketImpl`. It has also been changed to disallow a `ServerSocket` using a custom
      `SocketImpl` to accept a connection with a `Socket` using a system-default `SocketImpl`.
      Disallowing these nonsensical combinations of `SocketImpl` improves reliability in cases where
      an application sets one, but not both, socket implementation factories.
      
      The changes should have no impact on applications that set the same factory for both client
      and server socket implementations.

  JDK-8226239: Pre-JDK 1.4 SocketImpl Implementations No Longer Supported

      Support for custom `java.net.SocketImpl` implementations compiled for Java SE 1.3 and older
      has been removed in this release. This change has no impact on `SocketImpl` implementations
      compiled for Java SE 1.4 (released in 2002) or newer.

  JDK-8223354: JEP 353: Reimplement the Legacy Socket API

      The underlying implementation for the `java.net.Socket` and `java.net.ServerSocket` APIs has
      been replaced in this release. JEP 353 provides all the details on this change.
      
      Every effort has been made to ensure that the new implementation is compatible with the old
      implementation but it is possible that there is existing code that depends on unspecified
      behavior in corner cases where the old and new implementations behave differently. The JDK
      continues to include the old implementation (known as "PlainSocketImpl" or the "plain"
      implementation) to allow such code continue to run. The old implementation is selected by
      running with the system property "`jdk.net.usePlainSockteImpl`" set, or set to the value
      "`true`", i.e. run with `-Djdk.net.usePlainSocketImpl` or `-Djdk.net.usePlainSocketImpl=true`.
      The property can also be configured in the JDK network configuration file, located in
      `${java.home}/conf/net.properties`. The old implementation, and the system property to select
      the old implementation, will be removed in a future release. 

  JDK-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption

      The default implementation of the `supportedOptions()`, `getOption(SocketOption<T>)` and
      `setOption(SocketOption<T>, T)` methods, defined by `java.net.SocketImpl` and
      `java.net.DatagramSocketImpl`, have changed in this release. The default implementation of the
      `supportedOptions()` method has been changed to return an empty set. The default
      implementations of the `getOption(SocketOption<T>)` and `setOption(SocketOption<T>, T)`
      methods have been changed to throw `UnsupportedOperationException`.
      
      Developers extending `java.net.SocketImpl` or `java.net.DatagramSocketImpl` to create their
      own socket or datagram socket implementations need to override these methods to support the
      socket options that the custom socket implementation supports.

  JDK-8225154: Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set

      Developers using the `java.net.Socket.setSocketImplFactory` or
      `java.net.ServerSocket.setSocketFactory` APIs to change the system-wide factories for client
      socket or server socket implementations should note the following changes:
      
      1.  Invoking `ServerSocket::accept` on a `ServerSocket` using a system-default `SocketImpl` to
      accept a connection will always return a `Socket` with a system-default `SocketImpl`. In this
      case, the system-wide factory for client socket implementations will not be invoked to create
      the client socket implementation.
      
      2. `java.net.ServerSocket::implAccept` has been changed to disallow a `ServerSocket` using a
      system-default `SocketImpl` from accepting a connection with a `Socket` using a custom
      `SocketImpl`. It has also been changed to disallow a `ServerSocket` using a custom
      `SocketImpl` to accept a connection with a `Socket` using a system-default `SocketImpl`.
      Disallowing these nonsensical combinations of `SocketImpl` improves reliability in cases where
      an application sets one, but not both, socket implementation factories.
      
      The changes should have no impact on applications that set the same factory for both client
      and server socket implementations.

  JDK-8226239: Pre-JDK 1.4 SocketImpl Implementations No Longer Supported

      Support for custom `java.net.SocketImpl` implementations compiled for Java SE 1.3 and older
      has been removed in this release. This change has no impact on `SocketImpl` implementations
      compiled for Java SE 1.4 (released in 2002) or newer.

  JDK-8223354: JEP 353: Reimplement the Legacy Socket API

      The underlying implementation for the `java.net.Socket` and `java.net.ServerSocket` APIs has
      been replaced in this release. JEP 353 provides all the details on this change.
      
      Every effort has been made to ensure that the new implementation is compatible with the old
      implementation but it is possible that there is existing code that depends on unspecified
      behavior in corner cases where the old and new implementations behave differently. The JDK
      continues to include the old implementation (known as "PlainSocketImpl" or the "plain"
      implementation) to allow such code continue to run. The old implementation is selected by
      running with the system property "`jdk.net.usePlainSockteImpl`" set, or set to the value
      "`true`", i.e. run with `-Djdk.net.usePlainSocketImpl` or `-Djdk.net.usePlainSocketImpl=true`.
      The property can also be configured in the JDK network configuration file, located in
      `${java.home}/conf/net.properties`. The old implementation, and the system property to select
      the old implementation, will be removed in a future release. 

  JDK-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption

      The default implementation of the `supportedOptions()`, `getOption(SocketOption<T>)` and
      `setOption(SocketOption<T>, T)` methods, defined by `java.net.SocketImpl` and
      `java.net.DatagramSocketImpl`, have changed in this release. The default implementation of the
      `supportedOptions()` method has been changed to return an empty set. The default
      implementations of the `getOption(SocketOption<T>)` and `setOption(SocketOption<T>, T)`
      methods have been changed to throw `UnsupportedOperationException`.
      
      Developers extending `java.net.SocketImpl` or `java.net.DatagramSocketImpl` to create their
      own socket or datagram socket implementations need to override these methods to support the
      socket options that the custom socket implementation supports.

  JDK-8225154: Change to ServerSocket.accept() When the System-Wide Factory for Client or Server Socket Implementations Is Set

      Developers using the `java.net.Socket.setSocketImplFactory` or
      `java.net.ServerSocket.setSocketFactory` APIs to change the system-wide factories for client
      socket or server socket implementations should note the following changes:
      
      1.  Invoking `ServerSocket::accept` on a `ServerSocket` using a system-default `SocketImpl` to
      accept a connection will always return a `Socket` with a system-default `SocketImpl`. In this
      case, the system-wide factory for client socket implementations will not be invoked to create
      the client socket implementation.
      
      2. `java.net.ServerSocket::implAccept` has been changed to disallow a `ServerSocket` using a
      system-default `SocketImpl` from accepting a connection with a `Socket` using a custom
      `SocketImpl`. It has also been changed to disallow a `ServerSocket` using a custom
      `SocketImpl` to accept a connection with a `Socket` using a system-default `SocketImpl`.
      Disallowing these nonsensical combinations of `SocketImpl` improves reliability in cases where
      an application sets one, but not both, socket implementation factories.
      
      The changes should have no impact on applications that set the same factory for both client
      and server socket implementations.

security-libs/javax.security:

  JDK-8227564: Allow SASL Mechanisms to Be Restricted

      A security property named `jdk.sasl.disabledMechanisms` has been added that can be used to
      disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the
      `mechanisms` argument of `Sasl.createSaslClient` or the `mechanism` argument of
      `Sasl.createSaslServer`. The default value for this security property is empty, which means
      that no mechanisms are disabled out-of-the-box.

tools/javap:

  JDK-8225811: javap Checksum Uses SHA-256

      javap includes a checksum of the contents of the class file in verbose output. The checksum is
      now calculated with the SHA-256 algorithm, instead of the older MD5 algorithm.

core-libs/java.util:i18n:

  JDK-8218762: New Japanese Era Name: Reiwa

      An instance representing the new Reiwa era has been added to this update. Unlike other eras,
      there is no public field for this era. It can be obtained by calling `JapaneseEra.of(3)` or
      `JapaneseEra.valueOf("Reiwa")`. JDK 13 and later will have a new public field to represent
      this era.
      
      The placeholder name, "`NewEra`", for the Japanese era that started from May 1st, 2019 has
      been replaced with the new official name. Applications that relied on the placeholder name
      (see JDK-8202088) to obtain the new era singleton (`JapaneseEra.valueOf("NewEra")`) will no
      longer work.

  JDK-8223587: Upgraded CLDR to Version 35.1

      Locale data based on Unicode Consortium's CLDR has been upgraded to their version 35.1, which
      includes several localized display names for the Japanese new era, Reiwa. There are some
      notable locale data changes, such as year formatting in Dutch locale (JDK-8225240) and French
      grouping separator change (JDK-8225245). For the detailed locale data changes, please refer to
      the cumulative CLDR changes from the previously supported version v.33. The following are
      links to each CLDR upgrade release: - CLDR 33.1:
      http://cldr.unicode.org/index/downloads/cldr-33-1 - CLDR 34:
      http://cldr.unicode.org/index/downloads/cldr-34 - CLDR 35, 35.1:
      http://cldr.unicode.org/index/downloads/cldr-35

  JDK-8218762: New Japanese Era Name: Reiwa

      An instance representing the new Reiwa era has been added to this update. Unlike other eras,
      there is no public field for this era. It can be obtained by calling `JapaneseEra.of(3)` or
      `JapaneseEra.valueOf("Reiwa")`. JDK 13 and later will have a new public field to represent
      this era.
      
      The placeholder name, "`NewEra`", for the Japanese era that started from May 1st, 2019 has
      been replaced with the new official name. Applications that relied on the placeholder name
      (see JDK-8202088) to obtain the new era singleton (`JapaneseEra.valueOf("NewEra")`) will no
      longer work.

  JDK-8223587: Upgraded CLDR to Version 35.1

      Locale data based on Unicode Consortium's CLDR has been upgraded to their version 35.1, which
      includes several localized display names for the Japanese new era, Reiwa. There are some
      notable locale data changes, such as year formatting in Dutch locale (JDK-8225240) and French
      grouping separator change (JDK-8225245). For the detailed locale data changes, please refer to
      the cumulative CLDR changes from the previously supported version v.33. The following are
      links to each CLDR upgrade release: - CLDR 33.1:
      http://cldr.unicode.org/index/downloads/cldr-33-1 - CLDR 34:
      http://cldr.unicode.org/index/downloads/cldr-34 - CLDR 35, 35.1:
      http://cldr.unicode.org/index/downloads/cldr-35

core-libs/java.lang:

  JDK-8228689: Removal of Runtime Trace Methods

      The obsolete methods `traceInstructions(boolean)` and `traceMethodCalls(boolean)` have been
      removed from the `java.lang.Runtime` class. These methods have been non-functional for many
      releases, and their intended functions are provided by the Java Virtual Machine Tool Interface
      (JVMTI).

  JDK-8218924: Default Process launch mechanism on Linux now uses posix_spawn

      `Runtime.exec()` and `ProcessBuilder`, on Linux now use `posix_spawn(3)` to spawn child
      processes. This increases reliability and performance in low-memory situations.

  JDK-8218884: StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument

      The behavior of `StringBuffer(CharSequence)` and `StringBuilder(CharSequence)` is changed for
      the argument reporting a negative length.  The constructors were inconsistently throwing
      either `NegativeArraySizeException` or `IndexOutOfBoundException`.  The new behavior is to
      always throw `NegativeArraySizeException` for any argument reporting a negative length.

  JDK-8223588: Support for Unicode 12.1

      This release upgrades Unicode support to 12.1 which includes the following: -
      `java.lang.Character` supports Unicode Character Database of 12.1 level, in which 12.0 adds
      554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new
      scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one
      character, `U+32FF SQUARE ERA NAME REIWA`, since 12.0. - `java.text.Bidi` and
      `java.text.Normalizer` classes support 12.0 level of Unicode Standard Annexes, #9 and #15,
      respectively. - `java.util.regex` package supports Extended Grapheme Clusters based on 12.0
      level of Unicode Standard Annex #29

  JDK-8228689: Removal of Runtime Trace Methods

      The obsolete methods `traceInstructions(boolean)` and `traceMethodCalls(boolean)` have been
      removed from the `java.lang.Runtime` class. These methods have been non-functional for many
      releases, and their intended functions are provided by the Java Virtual Machine Tool Interface
      (JVMTI).

  JDK-8218924: Default Process launch mechanism on Linux now uses posix_spawn

      `Runtime.exec()` and `ProcessBuilder`, on Linux now use `posix_spawn(3)` to spawn child
      processes. This increases reliability and performance in low-memory situations.

  JDK-8218884: StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument

      The behavior of `StringBuffer(CharSequence)` and `StringBuilder(CharSequence)` is changed for
      the argument reporting a negative length.  The constructors were inconsistently throwing
      either `NegativeArraySizeException` or `IndexOutOfBoundException`.  The new behavior is to
      always throw `NegativeArraySizeException` for any argument reporting a negative length.

  JDK-8223588: Support for Unicode 12.1

      This release upgrades Unicode support to 12.1 which includes the following: -
      `java.lang.Character` supports Unicode Character Database of 12.1 level, in which 12.0 adds
      554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new
      scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one
      character, `U+32FF SQUARE ERA NAME REIWA`, since 12.0. - `java.text.Bidi` and
      `java.text.Normalizer` classes support 12.0 level of Unicode Standard Annexes, #9 and #15,
      respectively. - `java.util.regex` package supports Extended Grapheme Clusters based on 12.0
      level of Unicode Standard Annex #29

  JDK-8228689: Removal of Runtime Trace Methods

      The obsolete methods `traceInstructions(boolean)` and `traceMethodCalls(boolean)` have been
      removed from the `java.lang.Runtime` class. These methods have been non-functional for many
      releases, and their intended functions are provided by the Java Virtual Machine Tool Interface
      (JVMTI).

  JDK-8218924: Default Process launch mechanism on Linux now uses posix_spawn

      `Runtime.exec()` and `ProcessBuilder`, on Linux now use `posix_spawn(3)` to spawn child
      processes. This increases reliability and performance in low-memory situations.

  JDK-8218884: StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument

      The behavior of `StringBuffer(CharSequence)` and `StringBuilder(CharSequence)` is changed for
      the argument reporting a negative length.  The constructors were inconsistently throwing
      either `NegativeArraySizeException` or `IndexOutOfBoundException`.  The new behavior is to
      always throw `NegativeArraySizeException` for any argument reporting a negative length.

  JDK-8223588: Support for Unicode 12.1

      This release upgrades Unicode support to 12.1 which includes the following: -
      `java.lang.Character` supports Unicode Character Database of 12.1 level, in which 12.0 adds
      554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new
      scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one
      character, `U+32FF SQUARE ERA NAME REIWA`, since 12.0. - `java.text.Bidi` and
      `java.text.Normalizer` classes support 12.0 level of Unicode Standard Annexes, #9 and #15,
      respectively. - `java.util.regex` package supports Extended Grapheme Clusters based on 12.0
      level of Unicode Standard Annex #29

  JDK-8228689: Removal of Runtime Trace Methods

      The obsolete methods `traceInstructions(boolean)` and `traceMethodCalls(boolean)` have been
      removed from the `java.lang.Runtime` class. These methods have been non-functional for many
      releases, and their intended functions are provided by the Java Virtual Machine Tool Interface
      (JVMTI).

  JDK-8218924: Default Process launch mechanism on Linux now uses posix_spawn

      `Runtime.exec()` and `ProcessBuilder`, on Linux now use `posix_spawn(3)` to spawn child
      processes. This increases reliability and performance in low-memory situations.

  JDK-8218884: StringBuffer(CharSequence) and StringBuilder(CharSequence) Throw NegativeArraySizeException for Negatively Sized Argument

      The behavior of `StringBuffer(CharSequence)` and `StringBuilder(CharSequence)` is changed for
      the argument reporting a negative length.  The constructors were inconsistently throwing
      either `NegativeArraySizeException` or `IndexOutOfBoundException`.  The new behavior is to
      always throw `NegativeArraySizeException` for any argument reporting a negative length.

  JDK-8223588: Support for Unicode 12.1

      This release upgrades Unicode support to 12.1 which includes the following: -
      `java.lang.Character` supports Unicode Character Database of 12.1 level, in which 12.0 adds
      554 characters since 11.0, for a total of 137,928 characters. These additions include 4 new
      scripts, for a total of 150 scripts, as well as 61 new emoji characters. 12.1 adds exactly one
      character, `U+32FF SQUARE ERA NAME REIWA`, since 12.0. - `java.text.Bidi` and
      `java.text.Normalizer` classes support 12.0 level of Unicode Standard Annexes, #9 and #15,
      respectively. - `java.util.regex` package supports Extended Grapheme Clusters based on 12.0
      level of Unicode Standard Annex #29

client-libs/2d:

  JDK-8218009: GraphicsEnvironment.getCenterPoint() and getMaximumWindowBounds() are Unified Across Platforms

      Two methods were added to the `GraphicsEnvironment` class in JDK 1.4:  - `getCenterPoint()`  -
      `getMaximumWindowBounds()` 
      
      See
      [https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering](https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering).
      
      The page in the preceding link includes the following description:
      
      "X-Window, Xinerama All monitors share a single virtual coordinate space, as on Microsoft
      Windows. However, it is possible for the user to specify through X resources where windows
      should be centered. If these resources are set, `getCenterPoint` reflects their value.
      Otherwise, it returns the point at the center of the virtual coordinate space. (In practice,
      this will almost always be set - CDE sets it by default.)"
      
      Now, in JDK 13, the implementation of  `getCenterPoint()` and `getMaximumWindowBounds()` has
      been unified across the platforms (Windows, Linux, Solaris, and macOS):  - `getCenterPoint`
      returns the coordinates of the center of the primary display, for all platforms.  -
      `getMaximumWindowBounds` returns the bounds of the primary display minus display insets, for
      all platforms.

security-libs/javax.crypto:pkcs11:

  JDK-8221441: SunPKCS11 Provider Upgraded with Support for PKCS#11 v2.40

      The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds
      support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2
      family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms
      are supported by the underlying PKCS11 library.

  JDK-8215018: Memory Growth Issue in SunPKCS11 Fixed

      A memory growth issue in the SunPKCS11 cryptographic provider that affects the NSS back-end
      has been fixed.
      
      A system property, `sun.security.pkcs11.disableKeyExtraction` has been introduced to disable
      the fix. A "`true`" value disables the fix, while a "`false`" value (default) keeps it
      enabled.
      
      When enabled, PKCS#11 attributes of the NSS native keys are copied to Java byte buffers after
      key creation. Once used, NSS keys are destroyed and native heap space is freed up. If NSS keys
      are required again, they are recreated with the previously saved attributes.
      
      Further information and implementation details can be found in the CSR: JDK-8213430

  JDK-8221441: SunPKCS11 Provider Upgraded with Support for PKCS#11 v2.40

      The SunPKCS11 provider has been updated with support for PKCS#11 v2.40. This version adds
      support for more algorithms such as the AES/GCM/NoPadding cipher, DSA signatures using SHA-2
      family of message digests, and RSASSA-PSS signatures when the corresponding PKCS11 mechanisms
      are supported by the underlying PKCS11 library.

  JDK-8215018: Memory Growth Issue in SunPKCS11 Fixed

      A memory growth issue in the SunPKCS11 cryptographic provider that affects the NSS back-end
      has been fixed.
      
      A system property, `sun.security.pkcs11.disableKeyExtraction` has been introduced to disable
      the fix. A "`true`" value disables the fix, while a "`false`" value (default) keeps it
      enabled.
      
      When enabled, PKCS#11 attributes of the NSS native keys are copied to Java byte buffers after
      key creation. Once used, NSS keys are destroyed and native heap space is freed up. If NSS keys
      are required again, they are recreated with the previously saved attributes.
      
      Further information and implementation details can be found in the CSR: JDK-8213430

security-libs/org.ietf.jgss:

  JDK-8214079: Added a Default Native GSS-API Library on Windows

      A native GSS-API library has been added to JDK on the Windows platform. The library is
      client-side only and uses the default credentials. It will be loaded when the
      `sun.security.jgss.native` system property is set to "true". A user can still load a
      third-party native GSS-API library by setting the system property `sun.security.jgss.lib` to
      its path.

specification/language:

  JDK-8236934: JEP 378: Text Blocks

      Summary -------
      
      Add _text blocks_ to the Java language. A text block is a multi-line string literal that
      avoids the need for most escape sequences, automatically formats the string in a predictable
      way, and gives the developer control over the format when desired.
      
      History -------
      
      Text blocks were proposed by [JEP 355](https://openjdk.java.net/jeps/355) in early 2019 as a
      follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String
      Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear
      in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html).
      JEP 355 was [targeted to JDK 13 in June
      2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview
      feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks
      should be previewed again in JDK 14, with the addition of [two new escape
      sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368)
      was [targeted to JDK 14 in November
      2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) as a preview
      feature. Feedback on JDK 14 suggested that text blocks were ready to become final and
      permanent in JDK 15 with no further changes.
      
      Goals -----
      
      - Simplify the task of writing Java programs by making it easy to express strings that span
      several lines of source code, while avoiding escape sequences in common cases.
      
      - Enhance the readability of strings in Java programs that denote code written in non-Java
      languages.
      
      - Support migration from string literals by stipulating that any new construct can express the
      same set of strings as a string literal, interpret the same escape sequences, and be
      manipulated in the same ways as a string literal.
      
      - Add escape sequences for managing explicit white space and newline control.
      
      Non-Goals ---------
      
      - It is not a goal to define a new reference type, distinct from `java.lang.String`, for the
      strings expressed by any new construct.
      
      - It is not a goal to define new operators, distinct from `+`, that take `String` operands.
      
      - Text blocks do not directly support string interpolation. Interpolation may be considered in
      a future JEP. In the meantime, the new instance method `String::formatted` aids in situations
      where interpolation might be desired.
      
      - Text blocks do not support raw strings, that is, strings whose characters are not processed
      in any way.
      
      Motivation ----------
      
      In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal `"..."` usually
      requires significant editing with escapes and concatenation before the code containing the
      snippet will compile. The snippet is often difficult to read and arduous to maintain.
      
      More generally, the need to denote short, medium, and long blocks of text in a Java program is
      near universal, whether the text is code from other programming languages, structured text
      representing golden files, or messages in natural languages. On the one hand, the Java
      language recognizes this need by allowing strings of unbounded size and content; on the other
      hand, it embodies a design default that strings should be small enough to denote on a single
      line of a source file (surrounded by " characters), and simple enough to escape easily. This
      design default is at odds with the large number of Java programs where strings are too long to
      fit comfortably on a single line.
      
      Accordingly, it would improve both the readability and the writability of a broad class of
      Java programs to have a linguistic mechanism for denoting strings more literally than a string
      literal -- across multiple lines and without the visual clutter of escapes. In essence, a
      two-dimensional block of text, rather than a one-dimensional sequence of characters.
      
      Still, it is impossible to predict the role of every string in Java programs. Just because a
      string spans multiple lines of source code does not mean that newline characters are desirable
      in the string. One part of a program may be more readable when strings are laid out over
      multiple lines, but the embedded newline characters may change the behavior of another part of
      the program. Accordingly, it would be helpful if the developer had precise control over where
      newlines appear, and, as a related matter, how much white space appears to the left and right
      of the "block" of text.
      
      ### HTML example
      
      _Using "one-dimensional" string literals_
      
      ``` String html = "<html>\n" +               "    <body>\n" +               "        <p>Hello,
      world</p>\n" +               "    </body>\n" +               "</html>\n"; ```
      
      _Using a "two-dimensional" block of text_
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>               """; ```
      
      ### SQL example
      
      _Using "one-dimensional" string literals_
      
      ``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" +               
      "WHERE \"CITY\" = 'INDIANAPOLIS'\n" +                "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";
      ```
      
      _Using a "two-dimensional" block of text_
      
      ``` String query = """                SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"         
      WHERE "CITY" = 'INDIANAPOLIS'                ORDER BY "EMP_ID", "LAST_NAME";               
      """; ```
      
      ### Polyglot language example
      
      _Using "one-dimensional" string literals_
      
      ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
      engine.eval("function hello() {\n" +                          "    print('\"Hello,
      world\"');\n" +                          "}\n" +                          "\n" +              
      "hello();\n"); ```
      
      _Using a "two-dimensional" block of text_
      
      ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
      engine.eval("""                          function hello() {                             
      print('"Hello, world"');                          }                                           
      hello();                          """); ```
      
      Description -----------
      
      > _This section is identical to the same section in this JEP's predecessor, [JEP
      355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new
      escape sequences](#New-escape-sequences)._
      
      A _text block_ is a new kind of literal in the Java language. It may be used to denote a
      string anywhere that a _[string
      literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could
      appear, but offers greater expressiveness and less accidental complexity.
      
      A text block consists of zero or more content characters, enclosed by opening and closing
      delimiters.
      
      The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by
      zero or more white spaces followed by a line terminator. The _content_ begins at the first
      character after the line terminator of the opening delimiter.
      
      The _closing delimiter_ is a sequence of three double quote characters. The content ends at
      the last character before the first double quote of the closing delimiter.
      
      The content may include double quote characters directly, unlike the characters in a string
      literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat
      delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to
      visually distinguish a text block from a string literal.
      
      The content may include line terminators directly, unlike the characters in a string literal.
      The use of `\n` in a text block is permitted, but not necessary or recommended. For example,
      the text block:
      
      ``` """ line 1 line 2 line 3 """ ```
      
      is equivalent to the string literal:
      
      ``` "line 1\nline 2\nline 3\n" ```
      
      or a concatenation of string literals:
      
      ``` "line 1\n" + "line 2\n" + "line 3\n" ```
      
      If a line terminator is not required at the end of the string, then the closing delimiter can
      be placed on the last line of content. For example, the text block:
      
      ``` """ line 1 line 2 line 3""" ```
      
      is equivalent to the string literal:
      
      ``` "line 1\nline 2\nline 3" ```
      
      A text block can denote the empty string, although this is not recommended because it needs
      two lines of source code:
      
      ``` String empty = """ """; ```
      
      Here are some examples of ill-formed text blocks:
      
      ``` String a = """""";   // no line terminator after opening delimiter String b = """ """;  //
      no line terminator after opening delimiter String c = """            ";        // no closing
      delimiter (text block continues to EOF) String d = """            abc \ def            """;   
      // unescaped backslash (see below for escape processing) ``` 
      
      ### Compile-time processing
      
      A text block is a [constant
      expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type
      `String`, just like a string literal. However, unlike a string literal, the content of a text
      block is processed by the Java compiler in three distinct steps:
      
      1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this
      translation is to follow the principle of least surprise when moving Java source code across
      platforms.
      
      2. Incidental white space surrounding the content, introduced to match the indentation of Java
      source code, is removed.
      
      3. Escape sequences in the content are interpreted. Performing interpretation as the final
      step means developers can write escape sequences such as `\n` without them being modified or
      deleted by earlier steps.
      
      The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the
      constant pool, just like the characters of a string literal. The `class` file does not record
      whether a `CONSTANT_String_info` entry was derived from a text block or a string literal.
      
      At run time, a text block is evaluated to an instance of `String`, just like a string literal.
      Instances of `String` that are derived from text blocks are indistinguishable from instances
      derived from string literals. Two text blocks with the same processed content will refer to
      the same instance of `String` due to
      [interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just
      like for [string
      literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410).
      
      The following sections discuss compile-time processing in more detail.
      
      #### 1. Line terminators
      
      Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`)
      to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content
      is equivalent across platforms, even if the source code has been translated to a platform
      encoding (see `javac -encoding`).
      
      For example, if Java source code that was created on a Unix platform (where the line
      terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then
      without normalization, the content would become one character longer for each line. Any
      algorithm that relied on LF being the line terminator might fail, and any test that needed to
      verify string equality with `String::equals` would fail.
      
      The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during
      normalization; escape processing happens later.
      
      #### 2. Incidental white space
      
      The text blocks [shown above](#Motivation) were easier to read than their concatenated string
      literal counterparts, but the obvious interpretation for the content of a text block would
      include the spaces added to indent the embedded string so that it lines up neatly with the
      opening delimiter. Here is the HTML example using dots to visualize the spaces that the
      developer added for indentation:
      
      ``` String html = """ ..............<html> ..............    <body> ..............       
      <p>Hello, world</p> ..............    </body> ..............</html> .............."""; ```
      
      Since the opening delimiter is generally positioned to appear on the same line as the
      statement or expression which consumes the text block, there is no real significance to the
      fact that 14 visualized spaces start each line. Including those spaces in the content would
      mean the text block denotes a string different from the one denoted by the concatenated string
      literals. This would hurt migration, and be a recurring source of surprise: it is
      overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the
      closing delimiter is generally positioned to align with the content, which further suggests
      that the 14 visualized spaces are insignificant.
      
      Spaces may also appear at the end of each line, especially when a text block is populated by
      copy-pasting snippets from other files (which may themselves have been formed by copy-pasting
      from yet more files). Here is the HTML example reimagined with some trailing white space,
      again using dots to visualize spaces:
      
      ``` String html = """ ..............<html>... ..............    <body> ..............       
      <p>Hello, world</p>.... ..............    </body>. ..............</html>... ..............""";
      ```
      
      Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is
      overwhelmingly likely that the developer does not care about it. Trailing white space
      characters are similar to line terminators, in that both are invisible artifacts of the source
      code editing environment. With no visual guide to the presence of trailing white space
      characters, including them in the content would be a recurring source of surprise, as it would
      affect the length, hash code, etc, of the string.
      
      Accordingly, an appropriate interpretation for the content of a text block is to differentiate
      _incidental white space_ at the start and end of each line, from _essential white space_. The
      Java compiler processes the content by removing incidental white space to yield what the
      developer intended. `String::indent` can then be used to further manipulate indentation if
      desired. Using `|` to visualize margins:
      
      ``` |<html>| |    <body>| |        <p>Hello, world</p>| |    </body>| |</html>| ```
      
      The _re-indentation algorithm_ takes the content of a text block whose line terminators have
      been normalized to LF. It removes the same amount of white space from each line of content
      until at least one of the lines has a non-white space character in the leftmost position. The
      position of the opening `"""` characters has no effect on the algorithm, but the position of
      the closing `"""` characters does have an effect if placed on its own line. The algorithm is
      as follows:
      
      1. Split the content of the text block at every LF, producing a list of _individual lines_.
      Note that any line in the content which was just an LF will become an empty line in the list
      of individual lines.
      
      2. Add all _non-blank_ lines from the list of individual lines into a set of _determining
      lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no
      visible influence on the indentation. Excluding blank lines from the set of determining lines
      avoids throwing off step 4 of the algorithm.)
      
      3. If the last line in the list of individual lines (i.e., the line with the closing
      delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the
      closing delimiter should influence the indentation of the content as a whole -- a
      [_significant trailing line_](#Significant-trailing-line-policy) policy.)
      
      4. Compute the _common white space prefix_ of the set of determining lines, by counting the
      number of leading white space characters on each line and taking the minimum count.
      
      5. Remove the common white space prefix from each _non-blank_ line in the list of individual
      lines.
      
      6. Remove all trailing white space from all lines in the modified list of individual lines
      from step 5. This step collapses wholly-white-space lines in the modified list so that they
      are empty, but does not discard them.
      
      7. Construct the result string by joining all the lines in the modified list of individual
      lines from step 6, using LF as the separator between lines. If the final line in the list from
      step 6 is empty, then the joining LF from the previous line will be the last character in the
      result string.
      
      The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by
      the algorithm; escape processing happens later. Similarly, the `\<line-terminator>` escape
      sequence does not prevent the splitting of lines on the line-terminator since the sequence is
      treated as two separate characters until escape processing. 
      
      The re-indentation algorithm will be normative in _The Java Language Specification_.
      Developers will have access to it via `String::stripIndent`, a new instance method.
      
      #### Significant trailing line policy
      
      Normally, one would format a text block in two ways: first, position the left edge of the
      content to appear under the first `"` of the opening delimiter, and second, place the closing
      delimiter on its own line to appear exactly under the opening delimiter. The resulting string
      will have no white space at the start of any line, and will not include the trailing blank
      line of the closing delimiter.
      
      However, because the trailing blank line is considered a _determining line_, moving it to the
      left has the effect of reducing the common white space prefix, and therefore reducing the the
      amount of white space that is stripped from the start of every line. In the extreme case,
      where the closing delimiter is moved all the way to the left, that reduces the common white
      space prefix to zero, effectively opting out of white space stripping.
      
      For example, with the closing delimiter moved all the way to the left, there is no incidental
      white space to visualize with dots:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html> """; ```
      
      Including the trailing blank line with the closing delimiter, the common white space prefix is
      zero, so zero white space is removed from the start of each line. The algorithm thus produces:
      (using `|` to visualize the left margin)
      
      ``` |              <html> |                  <body> |                      <p>Hello, world</p>
      |                  </body> |              </html> ```
      
      Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather
      under the `t` of `html` so it is eight spaces deeper than the variable declaration:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>         """; ```
      
      The spaces visualized with dots are considered to be incidental:
      
      ``` String html = """ ........      <html> ........          <body> ........             
      <p>Hello, world</p> ........          </body> ........      </html> ........"""; ```
      
      Including the trailing blank line with the closing delimiter, the common white space prefix is
      eight, so eight white spaces are removed from the start of each line. The algorithm thus
      preserves the essential indentation of the content relative to the closing delimiter:
      
      ``` |      <html> |          <body> |              <p>Hello, world</p> |          </body> |   
      </html> ```
      
      Finally, suppose the closing delimiter is moved slightly to the _right_ of the content:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>                   """; ```
      
      The spaces visualized with dots are considered to be incidental:
      
      ``` String html = """ ..............<html> ..............    <body> ..............       
      <p>Hello, world</p> ..............    </body> ..............</html> ..............    """; ```
      
      The common white space prefix is 14, so 14 white spaces are removed from the start of each
      line. The trailing blank line is stripped to leave an empty line, which being the last line is
      then discarded. In other words, moving the closing delimiter to the right of the content has
      no effect, and the algorithm again preserves the essential indentation of the content:
      
      ``` |<html> |    <body> |        <p>Hello, world</p> |    </body> |</html> ``` 
      
      #### 3. Escape sequences
      
      After the content is re-indented, any _escape sequences_ in the content are interpreted. Text
      blocks support all of the escape sequences supported in string literals, including `\n`, `\t`,
      `\'`, `\"`, and `\\`. See [section
      3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The
      Java Language Specification_ for the full list. Developers will have access to escape
      processing via `String::translateEscapes`, a new instance method.
      
      Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for
      vertical formatting of a string without it affecting the translation of line terminators in
      step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting
      the removal of incidental white space in step 2. For example, consider this text block that
      contains the `\r` escape sequence (CR):
      
      ``` String html = """               <html>\r                   <body>\r                      
      <p>Hello, world</p>\r                   </body>\r               </html>\r               """;
      ```
      
      The CR escapes are not processed until after the line terminators have been normalized to LF.
      Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is:
      
      ``` |<html>\u000D\u000A |    <body>\u000D\u000A |        <p>Hello, world</p>\u000D\u000A |   
      </body>\u000D\u000A |</html>\u000D\u000A ```
      
      Note that it is legal to use `"` and `""` freely inside a text block, except immediately
      before the closing delimiter. For example, the following text blocks are legal:
      
      ``` String story = """     "When I use a word," Humpty Dumpty said,     in rather a scornful
      tone, "it means just what I     choose it to mean - neither more nor less."     "The question
      is," said Alice, "whether you     can make words mean so many different things."     "The
      question is," said Humpty Dumpty,     "which is to be master - that's all."     """;    //
      Note the newline before the closing delimiter
      
      String code =     """     String empty = "";     """; ```
      
      However, a sequence of three `"` characters requires at least one `"` to be escaped, in order
      to avoid mimicking the closing delimiter. (A sequence of n `"` characters requires at least
      `Math.floorDiv(n,3)` of them to be escaped.) The use of `"` immediately before the closing
      delimiter also requires escaping. For example:
      
      ``` String code =      """     String text = \"""         A text block inside a text block    
      \""";     """;
      
      String tutorial1 =     """     A common character     in Java programs     is \"""";
      
      String tutorial2 =     """     The empty string literal     is formed from " characters     as
      follows: \"\"""";
      
      System.out.println("""      1 "      2 ""      3 ""\"      4 ""\""      5 ""\"""      6
      ""\"""\"      7 ""\"""\""      8 ""\"""\"""      9 ""\"""\"""\"     10 ""\"""\"""\""     11
      ""\"""\"""\"""     12 ""\"""\"""\"""\" """); ```
      
      ### New escape sequences
      
      To allow finer control of the processing of newlines and white space, we introduce two new
      escape sequences.
      
      First, the `\<line-terminator>` escape sequence explicitly suppresses the insertion of a
      newline character.
      
      For example, it is common practice to split very long string literals into concatenations of
      smaller substrings, and then hard wrap the resulting string expression onto multiple lines:
      
      String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +                     
      "elit, sed do eiusmod tempor incididunt ut labore " +                      "et dolore magna
      aliqua.";
      
      With the `\<line-terminator>` escape sequence this could be expressed as:
      
      String text = """                     Lorem ipsum dolor sit amet, consectetur adipiscing \    
      elit, sed do eiusmod tempor incididunt ut labore \                     et dolore magna
      aliqua.\                     """;
      
      For the simple reason that character literals and traditional string literals don't allow
      embedded newlines, the `\<line-terminator>` escape sequence is only applicable to text blocks.
      
      Second, the new `\s` escape sequence simply translates to a single space (`\u0020`).
      
      Escape sequences aren't translated until after incidental space stripping, so `\s` can act as
      fence to prevent the stripping of trailing white space. Using `\s` at the end of each line in
      this example guarantees that each line is exactly six characters long:
      
      String colors = """         red  \s         green\s         blue \s         """;
      
      The `\s` escape sequence can be used in text blocks, traditional string literals, and
      character literals.
      
      ### Concatenation of text blocks
      
      Text blocks can be used anywhere a string literal can be used. For example, text blocks and
      string literals may be concatenated interchangeably:
      
      ``` String code = "public void print(Object o) {" +               """                  
      System.out.println(Objects.toString(o));               }               """; ```
      
      However, concatenation involving a text block can become rather clunky. Take this text block
      as a starting point:
      
      ``` String code = """               public void print(Object o) {                  
      System.out.println(Objects.toString(o));               }               """; ```
      
      Suppose it needs to be changed so that the type of `o` comes from a variable. Using
      concatenation, the text block that contains the trailing code will need to start on a new
      line. Unfortunately, the straightforward insertion of a newline in the program, as below, will
      cause a long span of white space between the type and the text beginning `o` :
      
      ``` String code = """               public void print(""" + type + """                        
      o) {                   System.out.println(Objects.toString(o));               }              
      """; ```
      
      The white space can be removed manually, but this hurts readability of the quoted code:
      
      ``` String code = """               public void print(""" + type + """                o) {    
      System.out.println(Objects.toString(o));               }               """; ```
      
      A cleaner alternative is to use `String::replace` or `String::format`, as follows:
      
      ``` String code = """               public void print($type o) {                  
      System.out.println(Objects.toString(o));               }               """.replace("$type",
      type); ```
      
      ``` String code = String.format("""               public void print(%s o) {                  
      System.out.println(Objects.toString(o));               }               """, type); ```
      
      Another alternative involves the introduction of a new instance method, `String::formatted`,
      which could be used as follows:
      
      ``` String source = """                 public void print(%s object) {                    
      System.out.println(Objects.toString(object));                 }                
      """.formatted(type); ```
      
      ### Additional Methods
      
      The following methods will be added to support text blocks;
      
      - `String::stripIndent()`: used to strip away incidental white space from the text block
      content - `String::translateEscapes()`: used to translate escape sequences -
      `String::formatted(Object... args)`: simplify value substitution in the text block
      
      Alternatives ------------
      
      ### Do nothing
      
      Java has prospered for over 20 years with string literals that required newlines to be
      escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation
      of strings that span several lines of source code. The `String` class has also evolved to
      include methods that simplify the processing and formatting of long strings, such as a method
      that presents a string as a [stream of
      lines](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#lines()).
      However, strings are such a fundamental part of the Java language that the shortcomings of
      string literals are apparent to [vast numbers of
      developers](https://stackoverflow.com/questions/878573/java-multiline-string). Other JVM
      languages have also made advances in how long and complex strings are denoted. Unsurprisingly,
      then, multi-line string literals have consistently been one of the most requested features for
      Java. Introducing a multi-line construct of low to moderate complexity would have a high
      payoff.
      
      ### Allow a string literal to span multiple lines
      
      Multi-line string literals could be introduced in Java simply by allowing line terminators in
      existing string literals. However, this would do nothing about the pain of escaping `"`
      characters. `\"` is the most frequently occurring escape sequence after `\n`, because of
      frequency of code snippets. The only way to avoid escaping `"` in a string literal would be to
      provide an alternate delimiter scheme for string literals. Delimiters were much discussed for
      [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), and the lessons learned
      were used to inform the design of text blocks, so it would be misguided to upset the stability
      of string literals.
      
      ### Adopt another language's multi-string literal
      
      According to [Brian
      Goetz](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html):
      
      > Many people have suggested that Java should adopt multi-line string literals from Swift or
      Rust. However, the approach of “just do what language X does” is intrinsically irresponsible;
      nearly every feature of every language is conditioned by other features of that language.
      Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve
      chosen (explicitly and implicitly), and ask what can be applied to the constraints of the
      language we have and user expectations within the community we have.
      
      For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we surveyed many
      modern programming languages and their support for multi-line string literals. The results of
      these surveys influenced the current proposal, such as the choice of three `"` characters for
      delimiters (although there were other reasons for this choice too) and the recognition of the
      need for automatic indentation management.
      
      ### Do not remove incidental white space
      
      If Java introduced multi-line string literals without support for automatically removing
      incidental white space, then many developers would write a method to remove it themselves, or
      lobby for the `String` class to include a removal method. However, that implies a potentially
      expensive computation every time the string is instantiated at run time, which would reduce
      the benefit of string interning. Having the Java language mandate the removal of incidental
      white space, both in leading and trailing positions, seems the most appropriate solution.
      Developers can opt out of leading white space removal by careful placement of the closing
      delimiter.
      
      ### Raw string literals
      
      For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we took a different
      approach to the problem of denoting strings without escaping newlines and quotes, focusing on
      the raw-ness of strings. We now believe that this focus was wrong, because while raw string
      literals could easily span multiple lines of source code, the cost of supporting unescaped
      delimiters in their content was extreme. This limited the effectiveness of the feature in the
      multi-line use case, which is a critical one because of the frequency of embedding multi-line
      (but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness
      to multi-line-ness was a renewed focus on having a consistent escape language between string
      literals, text blocks, and related features that may be added in future.
      
      Testing -------
      
      Tests that use string literals for the creation, interning, and manipulation of instances of
      `String` should be duplicated to use text blocks too. Negative tests should be added for
      corner cases involving line terminators and EOF.
      
      Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java,
      SQL-in-Java, and at least one JVM-language-in-Java. 

  JDK-8226915: JEP 354: Switch Expressions (Preview)

      Extend `switch` so it can be used as either a statement or an expression, and so that both
      forms can use either traditional `case ... :` labels (with fall through) or new `case ... ->`
      labels (with no fall through), with a further new statement for yielding a value from a
      `switch` expression. These changes will simplify everyday coding, and prepare the way for the
      use of [pattern matching](https://openjdk.java.net/jeps/8213076) in `switch`.  This is a
      [preview language feature](http://openjdk.java.net/jeps/12) in JDK 13.

  JDK-8236934: JEP 378: Text Blocks

      Summary -------
      
      Add _text blocks_ to the Java language. A text block is a multi-line string literal that
      avoids the need for most escape sequences, automatically formats the string in a predictable
      way, and gives the developer control over the format when desired.
      
      History -------
      
      Text blocks were proposed by [JEP 355](https://openjdk.java.net/jeps/355) in early 2019 as a
      follow-on to explorations begun in [JEP 326](https://openjdk.java.net/jeps/326) (Raw String
      Literals), which was initially targeted to JDK 12 but eventually [withdrawn and did not appear
      in that release](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html).
      JEP 355 was [targeted to JDK 13 in June
      2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003050.html) as a [preview
      feature](http://openjdk.java.net/jeps/12). Feedback on JDK 13 suggested that text blocks
      should be previewed again in JDK 14, with the addition of [two new escape
      sequences](#New-escape-sequences). Consequently, [JEP 368](https://openjdk.java.net/jeps/368)
      was [targeted to JDK 14 in November
      2019](https://mail.openjdk.java.net/pipermail/jdk-dev/2019-November/003653.html) as a preview
      feature. Feedback on JDK 14 suggested that text blocks were ready to become final and
      permanent in JDK 15 with no further changes.
      
      Goals -----
      
      - Simplify the task of writing Java programs by making it easy to express strings that span
      several lines of source code, while avoiding escape sequences in common cases.
      
      - Enhance the readability of strings in Java programs that denote code written in non-Java
      languages.
      
      - Support migration from string literals by stipulating that any new construct can express the
      same set of strings as a string literal, interpret the same escape sequences, and be
      manipulated in the same ways as a string literal.
      
      - Add escape sequences for managing explicit white space and newline control.
      
      Non-Goals ---------
      
      - It is not a goal to define a new reference type, distinct from `java.lang.String`, for the
      strings expressed by any new construct.
      
      - It is not a goal to define new operators, distinct from `+`, that take `String` operands.
      
      - Text blocks do not directly support string interpolation. Interpolation may be considered in
      a future JEP. In the meantime, the new instance method `String::formatted` aids in situations
      where interpolation might be desired.
      
      - Text blocks do not support raw strings, that is, strings whose characters are not processed
      in any way.
      
      Motivation ----------
      
      In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal `"..."` usually
      requires significant editing with escapes and concatenation before the code containing the
      snippet will compile. The snippet is often difficult to read and arduous to maintain.
      
      More generally, the need to denote short, medium, and long blocks of text in a Java program is
      near universal, whether the text is code from other programming languages, structured text
      representing golden files, or messages in natural languages. On the one hand, the Java
      language recognizes this need by allowing strings of unbounded size and content; on the other
      hand, it embodies a design default that strings should be small enough to denote on a single
      line of a source file (surrounded by " characters), and simple enough to escape easily. This
      design default is at odds with the large number of Java programs where strings are too long to
      fit comfortably on a single line.
      
      Accordingly, it would improve both the readability and the writability of a broad class of
      Java programs to have a linguistic mechanism for denoting strings more literally than a string
      literal -- across multiple lines and without the visual clutter of escapes. In essence, a
      two-dimensional block of text, rather than a one-dimensional sequence of characters.
      
      Still, it is impossible to predict the role of every string in Java programs. Just because a
      string spans multiple lines of source code does not mean that newline characters are desirable
      in the string. One part of a program may be more readable when strings are laid out over
      multiple lines, but the embedded newline characters may change the behavior of another part of
      the program. Accordingly, it would be helpful if the developer had precise control over where
      newlines appear, and, as a related matter, how much white space appears to the left and right
      of the "block" of text.
      
      ### HTML example
      
      _Using "one-dimensional" string literals_
      
      ``` String html = "<html>\n" +               "    <body>\n" +               "        <p>Hello,
      world</p>\n" +               "    </body>\n" +               "</html>\n"; ```
      
      _Using a "two-dimensional" block of text_
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>               """; ```
      
      ### SQL example
      
      _Using "one-dimensional" string literals_
      
      ``` String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n" +               
      "WHERE \"CITY\" = 'INDIANAPOLIS'\n" +                "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";
      ```
      
      _Using a "two-dimensional" block of text_
      
      ``` String query = """                SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"         
      WHERE "CITY" = 'INDIANAPOLIS'                ORDER BY "EMP_ID", "LAST_NAME";               
      """; ```
      
      ### Polyglot language example
      
      _Using "one-dimensional" string literals_
      
      ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
      engine.eval("function hello() {\n" +                          "    print('\"Hello,
      world\"');\n" +                          "}\n" +                          "\n" +              
      "hello();\n"); ```
      
      _Using a "two-dimensional" block of text_
      
      ``` ScriptEngine engine = new ScriptEngineManager().getEngineByName("js"); Object obj =
      engine.eval("""                          function hello() {                             
      print('"Hello, world"');                          }                                           
      hello();                          """); ```
      
      Description -----------
      
      > _This section is identical to the same section in this JEP's predecessor, [JEP
      355](https://openjdk.java.net/jeps/355), except for the addition of the subsection on [new
      escape sequences](#New-escape-sequences)._
      
      A _text block_ is a new kind of literal in the Java language. It may be used to denote a
      string anywhere that a _[string
      literal](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5)_ could
      appear, but offers greater expressiveness and less accidental complexity.
      
      A text block consists of zero or more content characters, enclosed by opening and closing
      delimiters.
      
      The _opening delimiter_ is a sequence of three double quote characters (`"""`) followed by
      zero or more white spaces followed by a line terminator. The _content_ begins at the first
      character after the line terminator of the opening delimiter.
      
      The _closing delimiter_ is a sequence of three double quote characters. The content ends at
      the last character before the first double quote of the closing delimiter.
      
      The content may include double quote characters directly, unlike the characters in a string
      literal. The use of `\"` in a text block is permitted, but not necessary or recommended. Fat
      delimiters (`"""`) were chosen so that `"` characters could appear unescaped, and also to
      visually distinguish a text block from a string literal.
      
      The content may include line terminators directly, unlike the characters in a string literal.
      The use of `\n` in a text block is permitted, but not necessary or recommended. For example,
      the text block:
      
      ``` """ line 1 line 2 line 3 """ ```
      
      is equivalent to the string literal:
      
      ``` "line 1\nline 2\nline 3\n" ```
      
      or a concatenation of string literals:
      
      ``` "line 1\n" + "line 2\n" + "line 3\n" ```
      
      If a line terminator is not required at the end of the string, then the closing delimiter can
      be placed on the last line of content. For example, the text block:
      
      ``` """ line 1 line 2 line 3""" ```
      
      is equivalent to the string literal:
      
      ``` "line 1\nline 2\nline 3" ```
      
      A text block can denote the empty string, although this is not recommended because it needs
      two lines of source code:
      
      ``` String empty = """ """; ```
      
      Here are some examples of ill-formed text blocks:
      
      ``` String a = """""";   // no line terminator after opening delimiter String b = """ """;  //
      no line terminator after opening delimiter String c = """            ";        // no closing
      delimiter (text block continues to EOF) String d = """            abc \ def            """;   
      // unescaped backslash (see below for escape processing) ``` 
      
      ### Compile-time processing
      
      A text block is a [constant
      expression](https://docs.oracle.com/javase/specs/jls/se12/html/jls-15.html#jls-15.28) of type
      `String`, just like a string literal. However, unlike a string literal, the content of a text
      block is processed by the Java compiler in three distinct steps:
      
      1. Line terminators in the content are translated to LF (`\u000A`). The purpose of this
      translation is to follow the principle of least surprise when moving Java source code across
      platforms.
      
      2. Incidental white space surrounding the content, introduced to match the indentation of Java
      source code, is removed.
      
      3. Escape sequences in the content are interpreted. Performing interpretation as the final
      step means developers can write escape sequences such as `\n` without them being modified or
      deleted by earlier steps.
      
      The processed content is recorded in the `class` file as a `CONSTANT_String_info` entry in the
      constant pool, just like the characters of a string literal. The `class` file does not record
      whether a `CONSTANT_String_info` entry was derived from a text block or a string literal.
      
      At run time, a text block is evaluated to an instance of `String`, just like a string literal.
      Instances of `String` that are derived from text blocks are indistinguishable from instances
      derived from string literals. Two text blocks with the same processed content will refer to
      the same instance of `String` due to
      [interning](https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-5.html#jvms-5.1-300), just
      like for [string
      literals](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.5-410).
      
      The following sections discuss compile-time processing in more detail.
      
      #### 1. Line terminators
      
      Line terminators in the content are _normalized_ from CR (`\u000D`) and CRLF (`\u000D\u000A`)
      to LF (`\u000A`) by the Java compiler. This ensures that the string derived from the content
      is equivalent across platforms, even if the source code has been translated to a platform
      encoding (see `javac -encoding`).
      
      For example, if Java source code that was created on a Unix platform (where the line
      terminator is LF) is edited on a Windows platform (where the line terminator is CRLF), then
      without normalization, the content would become one character longer for each line. Any
      algorithm that relied on LF being the line terminator might fail, and any test that needed to
      verify string equality with `String::equals` would fail.
      
      The escape sequences `\n` (LF), `\f` (FF), and `\r` (CR) are _not_ interpreted during
      normalization; escape processing happens later.
      
      #### 2. Incidental white space
      
      The text blocks [shown above](#Motivation) were easier to read than their concatenated string
      literal counterparts, but the obvious interpretation for the content of a text block would
      include the spaces added to indent the embedded string so that it lines up neatly with the
      opening delimiter. Here is the HTML example using dots to visualize the spaces that the
      developer added for indentation:
      
      ``` String html = """ ..............<html> ..............    <body> ..............       
      <p>Hello, world</p> ..............    </body> ..............</html> .............."""; ```
      
      Since the opening delimiter is generally positioned to appear on the same line as the
      statement or expression which consumes the text block, there is no real significance to the
      fact that 14 visualized spaces start each line. Including those spaces in the content would
      mean the text block denotes a string different from the one denoted by the concatenated string
      literals. This would hurt migration, and be a recurring source of surprise: it is
      overwhelmingly likely that the developer does _not_ want those spaces in the string. Also, the
      closing delimiter is generally positioned to align with the content, which further suggests
      that the 14 visualized spaces are insignificant.
      
      Spaces may also appear at the end of each line, especially when a text block is populated by
      copy-pasting snippets from other files (which may themselves have been formed by copy-pasting
      from yet more files). Here is the HTML example reimagined with some trailing white space,
      again using dots to visualize spaces:
      
      ``` String html = """ ..............<html>... ..............    <body> ..............       
      <p>Hello, world</p>.... ..............    </body>. ..............</html>... ..............""";
      ```
      
      Trailing white space is most often unintentional, idiosyncratic, and insignificant. It is
      overwhelmingly likely that the developer does not care about it. Trailing white space
      characters are similar to line terminators, in that both are invisible artifacts of the source
      code editing environment. With no visual guide to the presence of trailing white space
      characters, including them in the content would be a recurring source of surprise, as it would
      affect the length, hash code, etc, of the string.
      
      Accordingly, an appropriate interpretation for the content of a text block is to differentiate
      _incidental white space_ at the start and end of each line, from _essential white space_. The
      Java compiler processes the content by removing incidental white space to yield what the
      developer intended. `String::indent` can then be used to further manipulate indentation if
      desired. Using `|` to visualize margins:
      
      ``` |<html>| |    <body>| |        <p>Hello, world</p>| |    </body>| |</html>| ```
      
      The _re-indentation algorithm_ takes the content of a text block whose line terminators have
      been normalized to LF. It removes the same amount of white space from each line of content
      until at least one of the lines has a non-white space character in the leftmost position. The
      position of the opening `"""` characters has no effect on the algorithm, but the position of
      the closing `"""` characters does have an effect if placed on its own line. The algorithm is
      as follows:
      
      1. Split the content of the text block at every LF, producing a list of _individual lines_.
      Note that any line in the content which was just an LF will become an empty line in the list
      of individual lines.
      
      2. Add all _non-blank_ lines from the list of individual lines into a set of _determining
      lines_. (Blank lines -- lines that are empty or are composed wholly of white space -- have no
      visible influence on the indentation. Excluding blank lines from the set of determining lines
      avoids throwing off step 4 of the algorithm.)
      
      3. If the last line in the list of individual lines (i.e., the line with the closing
      delimiter) is _blank_, then add it to the set of determining lines. (The indentation of the
      closing delimiter should influence the indentation of the content as a whole -- a
      [_significant trailing line_](#Significant-trailing-line-policy) policy.)
      
      4. Compute the _common white space prefix_ of the set of determining lines, by counting the
      number of leading white space characters on each line and taking the minimum count.
      
      5. Remove the common white space prefix from each _non-blank_ line in the list of individual
      lines.
      
      6. Remove all trailing white space from all lines in the modified list of individual lines
      from step 5. This step collapses wholly-white-space lines in the modified list so that they
      are empty, but does not discard them.
      
      7. Construct the result string by joining all the lines in the modified list of individual
      lines from step 6, using LF as the separator between lines. If the final line in the list from
      step 6 is empty, then the joining LF from the previous line will be the last character in the
      result string.
      
      The escape sequences `\b` (backspace), `\t` (tab) and `\s` (space) are _not_ interpreted by
      the algorithm; escape processing happens later. Similarly, the `\<line-terminator>` escape
      sequence does not prevent the splitting of lines on the line-terminator since the sequence is
      treated as two separate characters until escape processing. 
      
      The re-indentation algorithm will be normative in _The Java Language Specification_.
      Developers will have access to it via `String::stripIndent`, a new instance method.
      
      #### Significant trailing line policy
      
      Normally, one would format a text block in two ways: first, position the left edge of the
      content to appear under the first `"` of the opening delimiter, and second, place the closing
      delimiter on its own line to appear exactly under the opening delimiter. The resulting string
      will have no white space at the start of any line, and will not include the trailing blank
      line of the closing delimiter.
      
      However, because the trailing blank line is considered a _determining line_, moving it to the
      left has the effect of reducing the common white space prefix, and therefore reducing the the
      amount of white space that is stripped from the start of every line. In the extreme case,
      where the closing delimiter is moved all the way to the left, that reduces the common white
      space prefix to zero, effectively opting out of white space stripping.
      
      For example, with the closing delimiter moved all the way to the left, there is no incidental
      white space to visualize with dots:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html> """; ```
      
      Including the trailing blank line with the closing delimiter, the common white space prefix is
      zero, so zero white space is removed from the start of each line. The algorithm thus produces:
      (using `|` to visualize the left margin)
      
      ``` |              <html> |                  <body> |                      <p>Hello, world</p>
      |                  </body> |              </html> ```
      
      Alternatively, suppose the closing delimiter is not moved all the way to the left, but rather
      under the `t` of `html` so it is eight spaces deeper than the variable declaration:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>         """; ```
      
      The spaces visualized with dots are considered to be incidental:
      
      ``` String html = """ ........      <html> ........          <body> ........             
      <p>Hello, world</p> ........          </body> ........      </html> ........"""; ```
      
      Including the trailing blank line with the closing delimiter, the common white space prefix is
      eight, so eight white spaces are removed from the start of each line. The algorithm thus
      preserves the essential indentation of the content relative to the closing delimiter:
      
      ``` |      <html> |          <body> |              <p>Hello, world</p> |          </body> |   
      </html> ```
      
      Finally, suppose the closing delimiter is moved slightly to the _right_ of the content:
      
      ``` String html = """               <html>                   <body>                      
      <p>Hello, world</p>                   </body>               </html>                   """; ```
      
      The spaces visualized with dots are considered to be incidental:
      
      ``` String html = """ ..............<html> ..............    <body> ..............       
      <p>Hello, world</p> ..............    </body> ..............</html> ..............    """; ```
      
      The common white space prefix is 14, so 14 white spaces are removed from the start of each
      line. The trailing blank line is stripped to leave an empty line, which being the last line is
      then discarded. In other words, moving the closing delimiter to the right of the content has
      no effect, and the algorithm again preserves the essential indentation of the content:
      
      ``` |<html> |    <body> |        <p>Hello, world</p> |    </body> |</html> ``` 
      
      #### 3. Escape sequences
      
      After the content is re-indented, any _escape sequences_ in the content are interpreted. Text
      blocks support all of the escape sequences supported in string literals, including `\n`, `\t`,
      `\'`, `\"`, and `\\`. See [section
      3.10.6](https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.html#jls-3.10.6) of the _The
      Java Language Specification_ for the full list. Developers will have access to escape
      processing via `String::translateEscapes`, a new instance method.
      
      Interpreting escapes as the final step allows developers to use `\n`, `\f`, and `\r` for
      vertical formatting of a string without it affecting the translation of line terminators in
      step 1, and to use `\b` and `\t` for horizontal formatting of a string without it affecting
      the removal of incidental white space in step 2. For example, consider this text block that
      contains the `\r` escape sequence (CR):
      
      ``` String html = """               <html>\r                   <body>\r                      
      <p>Hello, world</p>\r                   </body>\r               </html>\r               """;
      ```
      
      The CR escapes are not processed until after the line terminators have been normalized to LF.
      Using Unicode escapes to visualize LF (`\u000A`) and CR (`\u000D`), the result is:
      
      ``` |<html>\u000D\u000A |    <body>\u000D\u000A |        <p>Hello, world</p>\u000D\u000A |   
      </body>\u000D\u000A |</html>\u000D\u000A ```
      
      Note that it is legal to use `"` and `""` freely inside a text block, except immediately
      before the closing delimiter. For example, the following text blocks are legal:
      
      ``` String story = """     "When I use a word," Humpty Dumpty said,     in rather a scornful
      tone, "it means just what I     choose it to mean - neither more nor less."     "The question
      is," said Alice, "whether you     can make words mean so many different things."     "The
      question is," said Humpty Dumpty,     "which is to be master - that's all."     """;    //
      Note the newline before the closing delimiter
      
      String code =     """     String empty = "";     """; ```
      
      However, a sequence of three `"` characters requires at least one `"` to be escaped, in order
      to avoid mimicking the closing delimiter. (A sequence of n `"` characters requires at least
      `Math.floorDiv(n,3)` of them to be escaped.) The use of `"` immediately before the closing
      delimiter also requires escaping. For example:
      
      ``` String code =      """     String text = \"""         A text block inside a text block    
      \""";     """;
      
      String tutorial1 =     """     A common character     in Java programs     is \"""";
      
      String tutorial2 =     """     The empty string literal     is formed from " characters     as
      follows: \"\"""";
      
      System.out.println("""      1 "      2 ""      3 ""\"      4 ""\""      5 ""\"""      6
      ""\"""\"      7 ""\"""\""      8 ""\"""\"""      9 ""\"""\"""\"     10 ""\"""\"""\""     11
      ""\"""\"""\"""     12 ""\"""\"""\"""\" """); ```
      
      ### New escape sequences
      
      To allow finer control of the processing of newlines and white space, we introduce two new
      escape sequences.
      
      First, the `\<line-terminator>` escape sequence explicitly suppresses the insertion of a
      newline character.
      
      For example, it is common practice to split very long string literals into concatenations of
      smaller substrings, and then hard wrap the resulting string expression onto multiple lines:
      
      String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +                     
      "elit, sed do eiusmod tempor incididunt ut labore " +                      "et dolore magna
      aliqua.";
      
      With the `\<line-terminator>` escape sequence this could be expressed as:
      
      String text = """                     Lorem ipsum dolor sit amet, consectetur adipiscing \    
      elit, sed do eiusmod tempor incididunt ut labore \                     et dolore magna
      aliqua.\                     """;
      
      For the simple reason that character literals and traditional string literals don't allow
      embedded newlines, the `\<line-terminator>` escape sequence is only applicable to text blocks.
      
      Second, the new `\s` escape sequence simply translates to a single space (`\u0020`).
      
      Escape sequences aren't translated until after incidental space stripping, so `\s` can act as
      fence to prevent the stripping of trailing white space. Using `\s` at the end of each line in
      this example guarantees that each line is exactly six characters long:
      
      String colors = """         red  \s         green\s         blue \s         """;
      
      The `\s` escape sequence can be used in text blocks, traditional string literals, and
      character literals.
      
      ### Concatenation of text blocks
      
      Text blocks can be used anywhere a string literal can be used. For example, text blocks and
      string literals may be concatenated interchangeably:
      
      ``` String code = "public void print(Object o) {" +               """                  
      System.out.println(Objects.toString(o));               }               """; ```
      
      However, concatenation involving a text block can become rather clunky. Take this text block
      as a starting point:
      
      ``` String code = """               public void print(Object o) {                  
      System.out.println(Objects.toString(o));               }               """; ```
      
      Suppose it needs to be changed so that the type of `o` comes from a variable. Using
      concatenation, the text block that contains the trailing code will need to start on a new
      line. Unfortunately, the straightforward insertion of a newline in the program, as below, will
      cause a long span of white space between the type and the text beginning `o` :
      
      ``` String code = """               public void print(""" + type + """                        
      o) {                   System.out.println(Objects.toString(o));               }              
      """; ```
      
      The white space can be removed manually, but this hurts readability of the quoted code:
      
      ``` String code = """               public void print(""" + type + """                o) {    
      System.out.println(Objects.toString(o));               }               """; ```
      
      A cleaner alternative is to use `String::replace` or `String::format`, as follows:
      
      ``` String code = """               public void print($type o) {                  
      System.out.println(Objects.toString(o));               }               """.replace("$type",
      type); ```
      
      ``` String code = String.format("""               public void print(%s o) {                  
      System.out.println(Objects.toString(o));               }               """, type); ```
      
      Another alternative involves the introduction of a new instance method, `String::formatted`,
      which could be used as follows:
      
      ``` String source = """                 public void print(%s object) {                    
      System.out.println(Objects.toString(object));                 }                
      """.formatted(type); ```
      
      ### Additional Methods
      
      The following methods will be added to support text blocks;
      
      - `String::stripIndent()`: used to strip away incidental white space from the text block
      content - `String::translateEscapes()`: used to translate escape sequences -
      `String::formatted(Object... args)`: simplify value substitution in the text block
      
      Alternatives ------------
      
      ### Do nothing
      
      Java has prospered for over 20 years with string literals that required newlines to be
      escaped. IDEs ease the maintenance burden by supporting automatic formatting and concatenation
      of strings that span several lines of source code. The `String` class has also evolved to
      include methods that simplify the processing and formatting of long strings, such as a method
      that presents a string as a [stream of
      lines](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/String.html#lines()).
      However, strings are such a fundamental part of the Java language that the shortcomings of
      string literals are apparent to [vast numbers of
      developers](https://stackoverflow.com/questions/878573/java-multiline-string). Other JVM
      languages have also made advances in how long and complex strings are denoted. Unsurprisingly,
      then, multi-line string literals have consistently been one of the most requested features for
      Java. Introducing a multi-line construct of low to moderate complexity would have a high
      payoff.
      
      ### Allow a string literal to span multiple lines
      
      Multi-line string literals could be introduced in Java simply by allowing line terminators in
      existing string literals. However, this would do nothing about the pain of escaping `"`
      characters. `\"` is the most frequently occurring escape sequence after `\n`, because of
      frequency of code snippets. The only way to avoid escaping `"` in a string literal would be to
      provide an alternate delimiter scheme for string literals. Delimiters were much discussed for
      [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), and the lessons learned
      were used to inform the design of text blocks, so it would be misguided to upset the stability
      of string literals.
      
      ### Adopt another language's multi-string literal
      
      According to [Brian
      Goetz](https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001082.html):
      
      > Many people have suggested that Java should adopt multi-line string literals from Swift or
      Rust. However, the approach of “just do what language X does” is intrinsically irresponsible;
      nearly every feature of every language is conditioned by other features of that language.
      Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve
      chosen (explicitly and implicitly), and ask what can be applied to the constraints of the
      language we have and user expectations within the community we have.
      
      For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we surveyed many
      modern programming languages and their support for multi-line string literals. The results of
      these surveys influenced the current proposal, such as the choice of three `"` characters for
      delimiters (although there were other reasons for this choice too) and the recognition of the
      need for automatic indentation management.
      
      ### Do not remove incidental white space
      
      If Java introduced multi-line string literals without support for automatically removing
      incidental white space, then many developers would write a method to remove it themselves, or
      lobby for the `String` class to include a removal method. However, that implies a potentially
      expensive computation every time the string is instantiated at run time, which would reduce
      the benefit of string interning. Having the Java language mandate the removal of incidental
      white space, both in leading and trailing positions, seems the most appropriate solution.
      Developers can opt out of leading white space removal by careful placement of the closing
      delimiter.
      
      ### Raw string literals
      
      For [JEP 326](https://openjdk.java.net/jeps/326) (Raw String Literals), we took a different
      approach to the problem of denoting strings without escaping newlines and quotes, focusing on
      the raw-ness of strings. We now believe that this focus was wrong, because while raw string
      literals could easily span multiple lines of source code, the cost of supporting unescaped
      delimiters in their content was extreme. This limited the effectiveness of the feature in the
      multi-line use case, which is a critical one because of the frequency of embedding multi-line
      (but not truly raw) code snippets in Java programs. A good outcome of the pivot from raw-ness
      to multi-line-ness was a renewed focus on having a consistent escape language between string
      literals, text blocks, and related features that may be added in future.
      
      Testing -------
      
      Tests that use string literals for the creation, interning, and manipulation of instances of
      `String` should be duplicated to use text blocks too. Negative tests should be added for
      corner cases involving line terminators and EOF.
      
      Tests should be added to ensure that text blocks can embed Java-in-Java, Markdown-in-Java,
      SQL-in-Java, and at least one JVM-language-in-Java. 

  JDK-8226915: JEP 354: Switch Expressions (Preview)

      Extend `switch` so it can be used as either a statement or an expression, and so that both
      forms can use either traditional `case ... :` labels (with fall through) or new `case ... ->`
      labels (with no fall through), with a further new statement for yielding a value from a
      `switch` expression. These changes will simplify everyday coding, and prepare the way for the
      use of [pattern matching](https://openjdk.java.net/jeps/8213076) in `switch`.  This is a
      [preview language feature](http://openjdk.java.net/jeps/12) in JDK 13.

core-libs/java.nio.charsets:

  JDK-8216588: Corrected UnicodeDecoder U+FFFE Handling

      The behavior of decoding the code point `U+FFFE` in the middle of the buffer has been
      corrected for `StandardCharsets.UTF_16[LE/BE]`. The decoders have been reporting the code
      point as "malformed". They now pass through the code point in order to conform to the [Unicode
      Consortium's Corrigendum#9](http://www.unicode.org/versions/corrigendum9.html).

hotspot/runtime:

  JDK-8226529: JEP 350 Dynamic CDS Archiving

      JEP 350 extends application class-data sharing ([AppCDS](https://openjdk.java.net/jeps/310))
      to allow the dynamic archiving of classes as a Java application is exiting. It also improves
      the usability of AppCDS by eliminating the need for users to do trial runs to create a class
      list for each application. The existing static archiving enabled by the `-Xshare:dump` option,
      using a class list, continues work as is.
      
      The dynamically-generated archive is created on top of the default system archive packaged
      with the running JDK image. A separate top-layer archive file is generated for each
      application. The user can  specify the filename of the dynamic archive name as the argument to
      the `-XX:ArchiveClassesAtExit` option. For example, the following command creates `hello.jsa`:
      ```     % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello ``` To run the same
      application using this dynamic archive: ```     % bin/java -XX:SharedArchiveFile=hello.jsa -cp
      hello.jar Hello ```
      
      The user could also specify both the base and the dynamic archives in the
      `-XX:SharedArchiveFile` option such as: ```     -XX:SharedArchiveFile=<base archive>:<dynamic
      archive> ```
      
      [CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the
      command line option.

  JDK-8230630: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used: 
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release. 
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code. 
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime. 
      
      Note that if you encounter issues while using either of these options, it is very likely that
      you will be required to reproduce the problem without using these options before Oracle
      Support can assist with an investigation.

  JDK-8218003: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used:
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release.
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code.
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime.

  JDK-8216320: Removal of VM option -XX:+AggressiveOpts

      The VM option `-XX:+AggressiveOpts` was deprecated in JDK 11 and support for it was removed in
      JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now
      cause an error on VM initialization.

  JDK-8226529: JEP 350 Dynamic CDS Archiving

      JEP 350 extends application class-data sharing ([AppCDS](https://openjdk.java.net/jeps/310))
      to allow the dynamic archiving of classes as a Java application is exiting. It also improves
      the usability of AppCDS by eliminating the need for users to do trial runs to create a class
      list for each application. The existing static archiving enabled by the `-Xshare:dump` option,
      using a class list, continues work as is.
      
      The dynamically-generated archive is created on top of the default system archive packaged
      with the running JDK image. A separate top-layer archive file is generated for each
      application. The user can  specify the filename of the dynamic archive name as the argument to
      the `-XX:ArchiveClassesAtExit` option. For example, the following command creates `hello.jsa`:
      ```     % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello ``` To run the same
      application using this dynamic archive: ```     % bin/java -XX:SharedArchiveFile=hello.jsa -cp
      hello.jar Hello ```
      
      The user could also specify both the base and the dynamic archives in the
      `-XX:SharedArchiveFile` option such as: ```     -XX:SharedArchiveFile=<base archive>:<dynamic
      archive> ```
      
      [CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the
      command line option.

  JDK-8230630: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used: 
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release. 
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code. 
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime. 
      
      Note that if you encounter issues while using either of these options, it is very likely that
      you will be required to reproduce the problem without using these options before Oracle
      Support can assist with an investigation.

  JDK-8218003: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used:
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release.
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code.
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime.

  JDK-8216320: Removal of VM option -XX:+AggressiveOpts

      The VM option `-XX:+AggressiveOpts` was deprecated in JDK 11 and support for it was removed in
      JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now
      cause an error on VM initialization.

  JDK-8226529: JEP 350 Dynamic CDS Archiving

      JEP 350 extends application class-data sharing ([AppCDS](https://openjdk.java.net/jeps/310))
      to allow the dynamic archiving of classes as a Java application is exiting. It also improves
      the usability of AppCDS by eliminating the need for users to do trial runs to create a class
      list for each application. The existing static archiving enabled by the `-Xshare:dump` option,
      using a class list, continues work as is.
      
      The dynamically-generated archive is created on top of the default system archive packaged
      with the running JDK image. A separate top-layer archive file is generated for each
      application. The user can  specify the filename of the dynamic archive name as the argument to
      the `-XX:ArchiveClassesAtExit` option. For example, the following command creates `hello.jsa`:
      ```     % bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello ``` To run the same
      application using this dynamic archive: ```     % bin/java -XX:SharedArchiveFile=hello.jsa -cp
      hello.jar Hello ```
      
      The user could also specify both the base and the dynamic archives in the
      `-XX:SharedArchiveFile` option such as: ```     -XX:SharedArchiveFile=<base archive>:<dynamic
      archive> ```
      
      [CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the
      command line option.

  JDK-8230630: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used: 
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release. 
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code. 
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime. 
      
      Note that if you encounter issues while using either of these options, it is very likely that
      you will be required to reproduce the problem without using these options before Oracle
      Support can assist with an investigation.

  JDK-8218003: Deprecated Java Options -Xverify:none and -noverify

      The Java options `-Xverify:none` and `-noverify` have been deprecated in this release. The
      options will continue to work as intended but will generate the following warning when used:
      
      warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be
      removed in a future release.
      
      Deprecating these options helps prevent users from running code that violates the JVM
      Specification, which can leave their applications open to malicious code.
      
      Users who need to run without startup verification can use AppCDS to archive their classes.
      The classes are verified during archiving and avoid verification at runtime.

  JDK-8216320: Removal of VM option -XX:+AggressiveOpts

      The VM option `-XX:+AggressiveOpts` was deprecated in JDK 11 and support for it was removed in
      JDK 12 (where its use was ignored other than generating a warning). Use of this flag will now
      cause an error on VM initialization.

core-libs/java.util.logging:

  JDK-8219540: NullPointerException in java.util.logging.Handler#isLoggable

      The default implementation of `java.util.logging.Handler.isLoggable` has been updated to match
      its specification and to return `false` if the `record` parameter is `null`.  The
      implementation of `java.util.logging.MemoryHandler.isLoggable` and
      `java.util.logging.MemoryHandler.publish` will no longer throw `NullPointerException` if the
      `record` parameter is `null`, which conforms to their specification.

security-libs/java.security:

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

  JDK-8223161: Removal of T-Systems Deutsche Telekom Root CA 2 Certificate

      The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the
      `cacerts` keystore:  + alias name "deutschetelekomrootca2 [jdk]"
      
      Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche
      Telekom AG, C=DE

  JDK-8225688: Support for MS Cryptography Next Generation (CNG)

      The SunMSCAPI provider now supports reading private keys in Cryptography Next Generation (CNG)
      format. This means that RSA and EC keys in CNG format are loadable from Windows keystores,
      such as "Windows-MY". Signature algorithms related to EC (`SHA1withECDSA`, `SHA256withECDSA`,
      etc.) are also supported.

  JDK-8224004: Removal of Two DocuSign Root CA Certificates

      Two DocuSign root CA certificates have expired and were removed from the `cacerts` keystore: 
      + alias name "certplusclass2primaryca [jdk]"
      
      Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
      
      + alias name "certplusclass3pprimaryca [jdk]"
      
      Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR

  JDK-8221983: New keytool -showinfo -tls Command for Displaying TLS Configuration Information

      A new `keytool -showinfo -tls` command has been added that displays TLS configuration
      information.

  JDK-8223976: Removal of Two Comodo Root CA Certificates

      Two Comodo root CA certificates have expired and were removed from the `cacerts` keystore:  +
      alias name "utnuserfirstclientauthemailca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email,
      OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
      
      + alias name "utnuserfirsthardwareca [jdk]"
      
      Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST
      Network, L=Salt Lake City, ST=UT, C=US

  JDK-8223648: Configurable Read Timeout for CRLs

      The `com.sun.security.crl.readtimeout` system property sets the maximum read timeout for CRL
      retrievals, in seconds. If the property has not been set, or if its value is negative, it is
      set to the default value of 15 seconds. A value of 0 means an infinite timeout.

core-libs/java.time:

  JDK-8225062: DateTimeFormatter now throws DateTimeParseException on Invalid HOUR_OF_AMPM

      The parsing behavior of `DateTimeFormatter` with `HOUR_OF_AMPM` has changed. It now correctly
      throws a `DateTimeParseException` with an out-of-bounds input values, such as `12`.

xml/jaxp:

  JDK-8224556: New Methods for Creating DOM and SAX Factories with Namespace Support

      New methods have been added for instantiating DOM and SAX factories with Namespace support by
      default. These methods are prefixed over their existing counterparts with "NS," which stands
      for NamespaceAware. Below is a list of the new methods:
      
      - `newDefaultNSInstance()`  - `newNSInstance()`  - `newNSInstance(String factoryClassName,
      ClassLoader classLoader)`
      
      Using these new methods, a parser created through the factory will be NamespaceAware by
      default. For example, the following statement:
      
      DocumentBuilder db = DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder(); 
      
      is equivalent to:
      
      DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance();     
      dbf.setNamespaceAware(true);      DocumentBuilder db = dbf.newDocumentBuilder();  

security-libs/org.ietf.jgss:krb5:

  JDK-8225387: Support for Kerberos Cross-Realm Referrals (RFC 6806)

      The Kerberos client has been enhanced with the support of principal name canonicalization and
      cross-realm referrals, as defined by the RFC 6806 protocol extension.
      
      As a result of this new feature, the Kerberos client can take advantage of more dynamic
      environment configurations and does not necessarily need to know (in advance) how to reach the
      realm of a target principal (user or service).
      
      Support is enabled by default and 5 is the maximum number of referral hops allowed. To turn it
      off, set the `sun.security.krb5.disableReferrals` security or system property to false. To
      configure a custom maximum number of referral hops, set the `sun.security.krb5.maxReferrals`
      security or system property to any positive value.
      
      See further information in JDK-8223172.

core-libs/java.lang.invoke:

  JDK-8221613: Lookup.unreflectSetter(Field) Now Throws IllegalAccessException for Static Final Fields

      `java.lang.invoke.MethodHandles.Lookup::unreflectSetter` returns a `MethodHandle` giving write
      access to the given `Field` object.  A `Field` object for a static final field does not have
      write access even if its accessible flag is true (i.e. `Field.setAccessibe(true)` has been
      called).  In JDK 13, `Lookup::unreflectSetter` is fixed to throw `IllegalAccessException` if
      the given `Field` object is a static final field.

security-libs/javax.xml.crypto:

  JDK-8225051: New String Constants for Canonical XML 1.1 URIs

      New String constants named `INCLUSIVE_11` and `INCLUSIVE_11_WITH_COMMENTS` have been added to
      the `javax.xml.crypto.dsig.CanonicalizationMethod` API. These represent the URIs for the
      Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

  JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3

      The XML Signature implementation in the `java.xml.crypto` module has been updated to version
      2.1.3 of Apache Santuario. New features include:  * Added support for embedding elliptic curve
      public keys in the KeyValue element

  JDK-8264194: com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property

      An Apache Santuario library version upgrade, used by the javax.xml.crypto.* packages,
      introduces a behavioral change where a new Base64 encoder uses "\r\n" as end-of-line
      terminator. By default, XML signatures signed using API calls form the javax.xml.crypto.dsig
      package includes the escaped '\r' character, encoded as "&#xd;" or  "&#13;".  
      
      A new `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` system property may be set
      to a value of "true" if an application is unable to handle the encoded output data changes
      where "&#xd;" or "&#13;" get appended to new lines in encoding operations. The effect of this
      property is to not include the carriage return character in base64-encoded fields in XML
      signature generated by calls to the javax.xml.crypto.* packages.
      
      Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482. 

  JDK-8224943: [xmldsig] Added KeyValue::EC_TYPE

      The `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and
      Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue) is now supported. A new
      `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface.
      Please note that only the `NamedCurve` domain parameter type is currently supported, and the
      `ECParameters` explicit curve parameter type is not supported.

  JDK-8225051: New String Constants for Canonical XML 1.1 URIs

      New String constants named `INCLUSIVE_11` and `INCLUSIVE_11_WITH_COMMENTS` have been added to
      the `javax.xml.crypto.dsig.CanonicalizationMethod` API. These represent the URIs for the
      Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

  JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3

      The XML Signature implementation in the `java.xml.crypto` module has been updated to version
      2.1.3 of Apache Santuario. New features include:  * Added support for embedding elliptic curve
      public keys in the KeyValue element

  JDK-8264194: com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property

      An Apache Santuario library version upgrade, used by the javax.xml.crypto.* packages,
      introduces a behavioral change where a new Base64 encoder uses "\r\n" as end-of-line
      terminator. By default, XML signatures signed using API calls form the javax.xml.crypto.dsig
      package includes the escaped '\r' character, encoded as "&#xd;" or  "&#13;".  
      
      A new `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` system property may be set
      to a value of "true" if an application is unable to handle the encoded output data changes
      where "&#xd;" or "&#13;" get appended to new lines in encoding operations. The effect of this
      property is to not include the carriage return character in base64-encoded fields in XML
      signature generated by calls to the javax.xml.crypto.* packages.
      
      Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482. 

  JDK-8224943: [xmldsig] Added KeyValue::EC_TYPE

      The `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and
      Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue) is now supported. A new
      `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface.
      Please note that only the `NamedCurve` domain parameter type is currently supported, and the
      `ECParameters` explicit curve parameter type is not supported.

  JDK-8225051: New String Constants for Canonical XML 1.1 URIs

      New String constants named `INCLUSIVE_11` and `INCLUSIVE_11_WITH_COMMENTS` have been added to
      the `javax.xml.crypto.dsig.CanonicalizationMethod` API. These represent the URIs for the
      Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

  JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3

      The XML Signature implementation in the `java.xml.crypto` module has been updated to version
      2.1.3 of Apache Santuario. New features include:  * Added support for embedding elliptic curve
      public keys in the KeyValue element

  JDK-8264194: com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property

      An Apache Santuario library version upgrade, used by the javax.xml.crypto.* packages,
      introduces a behavioral change where a new Base64 encoder uses "\r\n" as end-of-line
      terminator. By default, XML signatures signed using API calls form the javax.xml.crypto.dsig
      package includes the escaped '\r' character, encoded as "&#xd;" or  "&#13;".  
      
      A new `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` system property may be set
      to a value of "true" if an application is unable to handle the encoded output data changes
      where "&#xd;" or "&#13;" get appended to new lines in encoding operations. The effect of this
      property is to not include the carriage return character in base64-encoded fields in XML
      signature generated by calls to the javax.xml.crypto.* packages.
      
      Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482. 

  JDK-8224943: [xmldsig] Added KeyValue::EC_TYPE

      The `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and
      Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue) is now supported. A new
      `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface.
      Please note that only the `NamedCurve` domain parameter type is currently supported, and the
      `ECParameters` explicit curve parameter type is not supported.

  JDK-8225051: New String Constants for Canonical XML 1.1 URIs

      New String constants named `INCLUSIVE_11` and `INCLUSIVE_11_WITH_COMMENTS` have been added to
      the `javax.xml.crypto.dsig.CanonicalizationMethod` API. These represent the URIs for the
      Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature.

  JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3

      The XML Signature implementation in the `java.xml.crypto` module has been updated to version
      2.1.3 of Apache Santuario. New features include:  * Added support for embedding elliptic curve
      public keys in the KeyValue element

  JDK-8264194: com.sun.org.apache.xml.internal.security.ignoreLineBreaks System Property

      An Apache Santuario library version upgrade, used by the javax.xml.crypto.* packages,
      introduces a behavioral change where a new Base64 encoder uses "\r\n" as end-of-line
      terminator. By default, XML signatures signed using API calls form the javax.xml.crypto.dsig
      package includes the escaped '\r' character, encoded as "&#xd;" or  "&#13;".  
      
      A new `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` system property may be set
      to a value of "true" if an application is unable to handle the encoded output data changes
      where "&#xd;" or "&#13;" get appended to new lines in encoding operations. The effect of this
      property is to not include the carriage return character in base64-encoded fields in XML
      signature generated by calls to the javax.xml.crypto.* packages.
      
      Additional information can be found at https://issues.apache.org/jira/browse/SANTUARIO-482. 

  JDK-8224943: [xmldsig] Added KeyValue::EC_TYPE

      The `ECKeyValue` type as described in the [W3C Recommendation for XML-Signature Syntax and
      Processing](https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue) is now supported. A new
      `EC_TYPE` constant has been added to the `javax.xml.crypto.dsig.keyinfo.KeyValue` interface.
      Please note that only the `NamedCurve` domain parameter type is currently supported, and the
      `ECParameters` explicit curve parameter type is not supported.

core-libs:

  JDK-8224253: Improved Handling of the "Class-Path" JAR Manifest Attribute

      The JAR file specification has been updated to clarify what constitutes a valid entry for the
      `Class-Path` JAR Manifest Attribute. See the JAR file specification for further details.
      
      Invalid entries are now ignored. Applications relying on invalid `Class-Path` entries may see
      a `ClassNotFoundException`. A system property has been added to aid in debugging the
      `Class-Path` attribute. When the `"jdk.net.URLClassPath.showIgnoredClassPathEntries"` property
      is set to `true`, invalid `Class-Path` entries will be printed to the console.  

xml/javax.xml.parsers:

  JDK-8217937: Change DOM Parser to Not Resolve EntityReference and Add Text Node with DocumentBuilderFactory.setExpandEntityReferences(false)

      The implementation of the `ExpandEntityReferences`  feature was changed to comply with the
      specification of the `DocumentBuilderFactory.setExpandEntityReferences` method. Specifically,
      now when the method is set to `false` and encounters an entity reference, a DOM parser created
      by the `DocumentBuilderFactory` adds the `EntityReference` node to the DOM tree without the
      expanded Text node. Before the change, the implementation incorrectly added both nodes.
      
      With the change, the DOM parser no longer reads and resolves entity references when the
      feature `ExpandEntityReferences`  is set to false. For applications that intend to avoid
      resolving entity references, it will work as expected.
      
      This change also affects the DOM Load and Save parser. The `entities` parameter is aligned
      with the `ExpandEntityReferences` feature, so that setting the `entities` parameter to `true`
      is equivalent to setting `ExpandEntityReferences` to `false`. In the following code snippet,
      the `document` will contain `EntityReference` nodes but not expanded `Text` nodes: ```        
      LSParser domParser = domImplementationLS.createLSParser(MODE_SYNCHRONOUS, null);        
      domParser.getDomConfig().setParameter("entities", true);         LSInput src =
      domImplementationLS.createLSInput();         src.setStringData(source);         Document
      document = domParser.parse(src); ``` Because the references are not resolved, the resulting
      string will contain entity references without the text when the `document` is serialized: ``` 
      LSSerializer lsSerializer = domImplementationLS.createLSSerializer();        
      lsSerializer.getDomConfig().setParameter("format-pretty-print", true);         String result =
      lsSerializer.writeToString(document); ``` 

core-libs/java.rmi:

  JDK-8225318: Deprecated rmic Tool for Removal

      The _rmic_ tool has been deprecated and may be removed from a future release. The _rmic_ tool
      was used to create static stubs that support the Java Remote Method Protocol (JRMP) used by
      the Java Remote Method Invocation (RMI) facility. Statically generated stubs are obsolete and
      were replaced by dynamically generated stubs in Java SE 5.0. Dynamically generated stubs no
      longer require pregeneration using a tool such as _rmic_, and they are functionally equivalent
      to statically generated stubs. RMI applications should be migrated to use dynamically
      generated RMI stubs by changing the way remote objects are exported. See the class
      documentation for `java.rmi.server.UnicastRemoteObject` for further details.

hotspot/compiler:

  JDK-8226473: More Registers Available When Running Without Compressed References on x86_64

      When running with compressed references on x86_64, one of the CPU registers holds the heap
      base pointer to be used for references encoding/decoding. This register is not available for
      register allocation.
      
      Simple implementations before this release made this register unavailable (and thus unused)
      even if compressed references were disabled. In this release, the implementation was revised
      to put this unused register back into the available registers pool. Configurations with large
      heaps and/or `-XX:-UseCompressedOops` benefit from this improvement.

security-libs/javax.net.ssl:

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

  JDK-8219478: Deprecated javax.security.cert APIs with forRemoval=true

      The `javax.security.cert` API has been deprecated and marked for removal. The classes in this
      package should no longer be used. The `java.security.cert` package contains suitable
      replacements. 

  JDK-8225764:  Support for X25519 and X448 in TLS

      The named elliptic curve groups `x25519` and `x448` are now available for JSSE key agreement
      in TLS versions 1.0 to 1.3, with `x25519` being the most preferred of the default enabled
      named groups.  The default ordered list is now: 
      
      ```     x25519, secp256r1, secp384r1, secp521r1, x448,     sect283k1, sect283r1, sect409k1,
      sect409r1, sect571k1, sect571r1,     secp256k1,     ffdhe2048, ffdhe3072, ffdhe4096,
      ffdhe6144, ffdhe8192 ```
      
      The default list can be overridden using the system property *`jdk.tls.namedGroups`*. 

  JDK-8227105:  Session Resumption without Server-Side State in JSSE

      The feature allows for the server-side of JSSE to operate stateless.  As described in RFC
      5077[1] for TLS 1.2 and below, and RFC 8446[2] for TLS 1.3, the TLS server sends internal
      session information in the form of an encrypted session ticket to a client that supports
      stateless.  That session ticket is presented to the server during the TLS handshake to resume
      the session.  This should improve the performance and memory usage of the TLS server under
      large workloads as the session cache will seldom be used.  With less session information
      cached, some session information may not be available. This feature is not enabled by default
      and can be turned on by setting two properties.
      
      Note that invalidated stateless TLS sessions could be resumed in the current implementation. 
      The behavior is not guaranteed to be the same in future releases and updates (see bugid
      JDK-8229148)
      
      Note that in the current implementation, the return value of `SSLSession.getID()` is not
      persistent across resumption for TLS 1.3 and stateless TLS 1.2 connections.  This could be an
      issue if applications rely on the session identifier values.  This may change to be consistent
      a future release (See bugid JDK-8229149)
      
      Two new System properties are added in support of this feature:
      `jdk.tls.client.enableSessionTicketExtension` is used on the client side to toggle the Session
      Ticket Extension on the ClientHello message for TLS 1.2. Property value: "`true`" sends the
      extension, "`false`" does not (default). 
      
      `jdk.tls.server.enableSessionTicketExtension` enables a server to use stateless session
      tickets if the client supports it. Clients that do not support stateless session tickets will
      use the cache. Property value: "`true`" enables stateless, "`false`" does not (default). 
      
      [1]: https://tools.ietf.org/html/rfc5077  [2]: https://tools.ietf.org/html/rfc8446  

  JDK-8219479: Removal of the Internal com.sun.net.ssl package which was only used for Compatibility with Legacy JSSE 1.0 Applications

      The internal package `com.sun.net.ssl` has been removed from the JDK. Prior to Java SE 1.4,
      when JSSE was shipped as a standalone product, the `com.sun.net.ssl` APIs were supported, but
      since Java SE 1.4, the package was deprecated and intended for internal use only. Standard
      replacement APIs such as `HostNameVerifier`, `KeyManager`, and `TrustManager` have been
      available in the `javax.net.ssl` package since Java SE 1.4. Although applications should have
      transitioned to the standard APIs, this note is a final warning that these non-standard APIs
      have been removed.

  JDK-8217911: Removal of Experimental FIPS 140 Compliant Mode from SunJSSE Provider

      The experimental FIPS 140 compliant mode has been removed from the SunJSSE provider.
      
      Legacy applications might have used the experimental mode with one of the following
      approaches:   1. Updating the `java.security` file and specifying a crypto provider for the
      SunJSSE provider (for example, `security.provider.4=com.sun.net.ssl.internal.ssl.Provider
      SunPKCS11-NSS`)   2. Using the JDK internal class and creating a provider with a specified
      crypto provider (for example, `new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider);`). 
      
      Because the SunJSSE provider uses JDK default cryptography providers, applications can
      configure the `security.provider` security properties to use the FIPS 140 compliant
      cryptography providers.

  JDK-8220615: Duplicated RSA Services No Longer Supported by SunJSSE Provider

      Support for `RSA KeyFactory`, `RSA KeyPairGenerator`, `MD2withRSA`, `MD5withRSA`, and
      `SHA1withRSA Signature` has been removed from SunJSSE provider.
      
      Since JDK 5, `SunRsaSign` provider was introduced to support these RSA-related algorithms. The
      only reason for SunJSSE provider to support these was for backward-compatibility with pre-JDK
      5 applications. Removal should only impact applications that explicitly request these RSA
      services from SunJSSE provider. Applications should remove the hardcoded "SunJSSE" provider
      name. 

  JDK-8219551: Updated the Default Enabled Cipher Suites Preference

      The preference of the default enabled cipher suites has been changed. The compatibility impact
      should be minimal. If needed, applications can customize the enabled cipher suites and the
      preference. For more details, refer to the SunJSSE provider documentation and the JSSE
      Reference Guide documentation.

  JDK-8219663: Use Server Cipher Suites Preference by Default

      For TLS connections, the cipher suite selection, by default, is updated  to use the server
      cipher suites preference. Applications can configure the behavior by using the
      `SSLParameters.setUseCipherSuitesOrder​()` method.

security-libs/javax.crypto:

  JDK-8220791: Use SunJCE Mac in SecretKeyFactory PBKDF2 Implementation

      The SunJCE implementation of the PBKDF2 SecretKeyFactory will now exclusively use the SunJCE
      Mac service for the underlying pseudorandom function (PRF).  This fixes an issue where 3rd
      party JCE providers in rare cases could cause the SunJCE PBKDF2 SecretKeyFactory's underlying
      pseudorandom function (PRF) to fail on `Mac.init()`.

core-libs/java.nio:

  JDK-8223197: Added FileSystems.newFileSystem(Path, Map&lt;String, ?>) Method

      Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file
      system providers that treat the contents of a file as a file system.
      
      - `newFileSystem(Path)` - `newFileSystem(Path, Map<String, ?>)` - `newFileSystem(Path,
      Map<String, ?>, ClassLoader)`
      
      The addition of `newFileSystem(Path, Map<String, ?>)` creates a source (but not binary)
      compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path,
      ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be
      compiled because the reference to `newFileSystem` is ambiguous:
      
      `FileSystem fs = FileSystems.newFileSystem(path, null);`
      
      To avoid the ambiguous reference, this code needs to be modified to cast the second parameter
      to `java.lang.ClassLoader`.

  JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

      On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can
      now be used to create symbolic links when the process is not elevated but the user is running
      in "Developer Mode". This may be useful for tools and other development time tasks that need
      to create symbolic links without requiring additional privileges.

  JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows

      On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the
      DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden`
      now returns `true` when invoked to test a directory that has this attribute set.

  JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

      `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get`
      and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the
      buffer position.

  JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

      The Java Native Interface (JNI) specification has been clarified in this release to specify
      that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian
      (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long
      standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

  JDK-8223197: Added FileSystems.newFileSystem(Path, Map&lt;String, ?>) Method

      Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file
      system providers that treat the contents of a file as a file system.
      
      - `newFileSystem(Path)` - `newFileSystem(Path, Map<String, ?>)` - `newFileSystem(Path,
      Map<String, ?>, ClassLoader)`
      
      The addition of `newFileSystem(Path, Map<String, ?>)` creates a source (but not binary)
      compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path,
      ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be
      compiled because the reference to `newFileSystem` is ambiguous:
      
      `FileSystem fs = FileSystems.newFileSystem(path, null);`
      
      To avoid the ambiguous reference, this code needs to be modified to cast the second parameter
      to `java.lang.ClassLoader`.

  JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

      On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can
      now be used to create symbolic links when the process is not elevated but the user is running
      in "Developer Mode". This may be useful for tools and other development time tasks that need
      to create symbolic links without requiring additional privileges.

  JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows

      On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the
      DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden`
      now returns `true` when invoked to test a directory that has this attribute set.

  JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

      `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get`
      and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the
      buffer position.

  JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

      The Java Native Interface (JNI) specification has been clarified in this release to specify
      that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian
      (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long
      standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

  JDK-8223197: Added FileSystems.newFileSystem(Path, Map&lt;String, ?>) Method

      Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file
      system providers that treat the contents of a file as a file system.
      
      - `newFileSystem(Path)` - `newFileSystem(Path, Map<String, ?>)` - `newFileSystem(Path,
      Map<String, ?>, ClassLoader)`
      
      The addition of `newFileSystem(Path, Map<String, ?>)` creates a source (but not binary)
      compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path,
      ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be
      compiled because the reference to `newFileSystem` is ambiguous:
      
      `FileSystem fs = FileSystems.newFileSystem(path, null);`
      
      To avoid the ambiguous reference, this code needs to be modified to cast the second parameter
      to `java.lang.ClassLoader`.

  JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

      On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can
      now be used to create symbolic links when the process is not elevated but the user is running
      in "Developer Mode". This may be useful for tools and other development time tasks that need
      to create symbolic links without requiring additional privileges.

  JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows

      On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the
      DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden`
      now returns `true` when invoked to test a directory that has this attribute set.

  JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

      `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get`
      and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the
      buffer position.

  JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

      The Java Native Interface (JNI) specification has been clarified in this release to specify
      that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian
      (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long
      standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

  JDK-8223197: Added FileSystems.newFileSystem(Path, Map&lt;String, ?>) Method

      Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file
      system providers that treat the contents of a file as a file system.
      
      - `newFileSystem(Path)` - `newFileSystem(Path, Map<String, ?>)` - `newFileSystem(Path,
      Map<String, ?>, ClassLoader)`
      
      The addition of `newFileSystem(Path, Map<String, ?>)` creates a source (but not binary)
      compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path,
      ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be
      compiled because the reference to `newFileSystem` is ambiguous:
      
      `FileSystem fs = FileSystems.newFileSystem(path, null);`
      
      To avoid the ambiguous reference, this code needs to be modified to cast the second parameter
      to `java.lang.ClassLoader`.

  JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

      On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can
      now be used to create symbolic links when the process is not elevated but the user is running
      in "Developer Mode". This may be useful for tools and other development time tasks that need
      to create symbolic links without requiring additional privileges.

  JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows

      On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the
      DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden`
      now returns `true` when invoked to test a directory that has this attribute set.

  JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

      `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get`
      and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the
      buffer position.

  JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

      The Java Native Interface (JNI) specification has been clarified in this release to specify
      that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian
      (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long
      standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

  JDK-8223197: Added FileSystems.newFileSystem(Path, Map&lt;String, ?>) Method

      Three new methods have been added to `java.nio.file.FileSystems` to make it easier to use file
      system providers that treat the contents of a file as a file system.
      
      - `newFileSystem(Path)` - `newFileSystem(Path, Map<String, ?>)` - `newFileSystem(Path,
      Map<String, ?>, ClassLoader)`
      
      The addition of `newFileSystem(Path, Map<String, ?>)` creates a source (but not binary)
      compatibility issue for code that has been using the existing 2-arg `newFileSystem(Path,
      ClassLoader)` and specifying the class loader as `null.` For example, the following cannot be
      compiled because the reference to `newFileSystem` is ambiguous:
      
      `FileSystem fs = FileSystems.newFileSystem(path, null);`
      
      To avoid the ambiguous reference, this code needs to be modified to cast the second parameter
      to `java.lang.ClassLoader`.

  JDK-8226801: Files.createSymbolicLink Can Be Used in "Developer Mode" Without Additional Privileges

      On Microsoft Windows, `java.nio.file.Files.createSymbolicLink` has been changed so that it can
      now be used to create symbolic links when the process is not elevated but the user is running
      in "Developer Mode". This may be useful for tools and other development time tasks that need
      to create symbolic links without requiring additional privileges.

  JDK-8225153: Files.isHidden Returns true for Hidden Directories on Windows

      On Microsoft Windows, the `java.nio.file.Files.isHidden` method has historically ignored the
      DOS "hidden" attribute on directories. This has been fixed in this release so that `isHidden`
      now returns `true` when invoked to test a directory that has this attribute set.

  JDK-8226802: New java.nio.ByteBuffer Bulk get/put Methods Transfer Bytes Without Regard to Buffer Position

      `java.nio.ByteBuffer` and the other buffer types in `java.nio` now define absolute bulk `get`
      and `put` methods to transfer contiguous sequences of bytes without regard to or effect on the
      buffer position.

  JDK-8225152: JNI NewDirectByteBuffer Creates Direct Buffer That Is java.nio.ByteOrder.BIG_ENDIAN

      The Java Native Interface (JNI) specification has been clarified in this release to specify
      that the `NewDirectByteBuffer` function creates a direct buffer that is always big-endian
      (high byte first; `java.nio.ByteOrder.BIG_ENDIAN`). This aligns the specification with long
      standing behavior (JDK 1.4, released in 2002) so it does not affect existing code.

client-libs/java.awt:

  JDK-8225358: Removal of awt.toolkit System Property

      Historically (up to JDK 1.8), documentation for the `java.awt.Toolkit` class referred to the
      "awt.toolkit" system property, which was set to the name of the platform implementation
      subclass. The documentation of this property was removed in JDK 9 because (1) it was an
      internal detail not intended to be a supported interface and (2) encapsulation by the module
      system meant that the class could not be directly manipulated. However, the system property
      was not removed until now. Applications that previously read this property can still, if
      necessary, obtain it by instantiating the AWT Toolkit and querying the class name via that
      instance.

  JDK-8218779: Deprecated and Unsupported Swing Motif Look and Feel on macOS

      Swing Motif Look and Feel is unsupported on macOS in JDK 13.
      
      In the source code, Swing Motif Look and Feel is deprecated with the intent to remove it in a
      future release. Use `javax.swing.plaf.metal.MetalLookAndFeel` instead.

  JDK-8225358: Removal of awt.toolkit System Property

      Historically (up to JDK 1.8), documentation for the `java.awt.Toolkit` class referred to the
      "awt.toolkit" system property, which was set to the name of the platform implementation
      subclass. The documentation of this property was removed in JDK 9 because (1) it was an
      internal detail not intended to be a supported interface and (2) encapsulation by the module
      system meant that the class could not be directly manipulated. However, the system property
      was not removed until now. Applications that previously read this property can still, if
      necessary, obtain it by instantiating the AWT Toolkit and querying the class name via that
      instance.

  JDK-8218779: Deprecated and Unsupported Swing Motif Look and Feel on macOS

      Swing Motif Look and Feel is unsupported on macOS in JDK 13.
      
      In the source code, Swing Motif Look and Feel is deprecated with the intent to remove it in a
      future release. Use `javax.swing.plaf.metal.MetalLookAndFeel` instead.

tools/javadoc(tool):

  JDK-8223253: Improved Javadoc Search

      The search feature in API documentation generated by Javadoc has been improved. You can now
      consistently search API documentation using partial terms and camel-case abbreviations. See
      https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/javadoc-search-spec.html for a
      full description of search features.

  JDK-8217842: Removal of Old Features from javadoc Tool

      The following four features have been removed from the _javadoc_ tool:
      
      _Support for generating API documentation using HTML 4:_ Support for HTML 5 was added in JDK 9
      and has been the default since JDK 11. To generate API documentation that is fully compliant
      with the HTML 5 specification, developers should ensure that any use of HTML tags in their
      documentation comments is also compliant with the HTML 5 specification.
      
      _Support for the "old" javadoc API:_ This includes the API (`com.sun.javadoc`), the old
      standard doclet (`com.sun.tools.doclets.standard`), and the old entry point
      (`com.sun.tools.javadoc.Start`), all in the `jdk.javadoc` module. A new API and a new standard
      doclet were introduced in JDK 9, leveraging other modern modeling API such as
      `javax.lang.model`. The _javadoc_ tool can be programmatically invoked using the
      `javax.tools.DocumentationTool` API, or (for simple use) `java.util.spi.ToolProvider`. Users
      that just use the _javadoc_ tool to generate standard API documentation are not affected.
      
      _Support for generating documentation using HTML frames:_ It has been replaced by the "Search"
      feature, added in JDK 9, and by improved index files and links within pages.
      
      _Support for the `--no-module-directories` option:_ This option provided limited support for
      the organization used for the generated documentation by the _javadoc_ tool in JDK 9 and 10,
      in which the files for different modules were not grouped into separate directories.  

  JDK-8223253: Improved Javadoc Search

      The search feature in API documentation generated by Javadoc has been improved. You can now
      consistently search API documentation using partial terms and camel-case abbreviations. See
      https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/javadoc-search-spec.html for a
      full description of search features.

  JDK-8217842: Removal of Old Features from javadoc Tool

      The following four features have been removed from the _javadoc_ tool:
      
      _Support for generating API documentation using HTML 4:_ Support for HTML 5 was added in JDK 9
      and has been the default since JDK 11. To generate API documentation that is fully compliant
      with the HTML 5 specification, developers should ensure that any use of HTML tags in their
      documentation comments is also compliant with the HTML 5 specification.
      
      _Support for the "old" javadoc API:_ This includes the API (`com.sun.javadoc`), the old
      standard doclet (`com.sun.tools.doclets.standard`), and the old entry point
      (`com.sun.tools.javadoc.Start`), all in the `jdk.javadoc` module. A new API and a new standard
      doclet were introduced in JDK 9, leveraging other modern modeling API such as
      `javax.lang.model`. The _javadoc_ tool can be programmatically invoked using the
      `javax.tools.DocumentationTool` API, or (for simple use) `java.util.spi.ToolProvider`. Users
      that just use the _javadoc_ tool to generate standard API documentation are not affected.
      
      _Support for generating documentation using HTML frames:_ It has been replaced by the "Search"
      feature, added in JDK 9, and by improved index files and links within pages.
      
      _Support for the `--no-module-directories` option:_ This option provided limited support for
      the organization used for the generated documentation by the _javadoc_ tool in JDK 9 and 10,
      in which the files for different modules were not grouped into separate directories.  

client-libs/javax.swing:

  JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead.

  JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release.

  JDK-8219071:  GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

  JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead.

  JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release.

  JDK-8219071:  GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

  JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead.

  JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release.

  JDK-8219071:  GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

  JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead.

  JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release.

  JDK-8219071:  GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

  JDK-8219012: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property `-Djdk.gtk.version=2.2` to request GTK2+ based rendering instead.

  JDK-8219072: GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release.

  JDK-8219071:  GTK+ 3.20 and Later Unsupported by Swing

      Due to incompatible changes in the GTK+ 3 library versions 3.20 and later, the Swing GTK Look
      and Feel does not render some UI components when using this library. Therefore Linux
      installations with versions of GTK+ 3.20 and above are not supported for use by the Swing GTK
      Look And Feel  in this release. Affected applications on such configurations should specify
      the system property -Djdk.gtk.version=2.2 to request GTK2+ based rendering instead.

hotspot/gc:

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

  JDK-8222920: ZGC: Maximum Heap Size Increased to 16TB

      The maximum supported heap size for ZGC was increased from 4TB to 16TB.

  JDK-8226482: Shenandoah Logs Report Proper Committed Heap Size

      In previous releases, Shenandoah reported the max heap size as the current heap size. This
      reporting error resulted from changing the heap sizing scheme to per-region commit/uncommit.
      In this release, Shenandoah reports the proper amount of committed memory that is taken by the
      current heap. The changes in this release also eliminate redundant logging lines that print
      reserved/committed/used memory sizes. This change makes Shenandoah GC logging more consistent
      with other GCs. Users are advised to check their GC log parsing scripts. See JDK-8222185.

  JDK-8225524: Shenandoah Changes -Xms to Mean "minimum heap size"

      Before the changes in this release, `-Xms` was treated as setting the "initial heap size."
      This enabled the Shenandoah heap sizing policy to uncommit unused heap that was below that
      setting. With this release, `-Xms` is treated as providing the "minimum heap size." This
      change prevents Shenandoah from uncommitting unused heap that is below the `-Xms` setting.
      `-Xms` can now be used to fine-tune footprint vs. allocation overhead tradeoffs.

  JDK-8222481: JEP 351: ZGC: Uncommit Unused Memory

      ZGC was enhanced to return unused heap memory to the operating system. This is useful for
      applications and environments where memory footprint is a concern.
      
      This feature is enabled by default, but can be explicitly disabled using `-XX:-ZUncommit`.
      Furthermore, memory will not be uncommitted so that the heap size shrinks below the minimum
      heap size (`-Xms`). This means this feature will be implicitly disabled if the minimum heap
      size (`-Xms`) is configured to be equal to the maximum heap size (`-Xmx`).
      
      An uncommit delay can be configured using `-XX:ZUncommitDelay=<seconds>` (defaults to 300
      seconds). This delay specifies for how long memory should have been unused before it's
      eligible for uncommit.
      
      For more details, see ([JEP 351](http://openjdk.java.net/jeps/351)).

  JDK-8226478: JFR events for Shenandoah

      This release implements two JFR events ShenandoahHeapRegionStateChange and
      ShenandoahHeapRegionInformation which provide internal GC diagnostic data that can be used to
      visualize the shenandoah heap regions.

  JDK-8222487: Added -XX:SoftMaxHeapSize Flag

      The manageable command-line flag `-XX:SoftMaxHeapSize=<bytes>` has been added. Currently, it
      only has an effect when the Z garbage collector is enabled (`-XX:+UseZGC`).
      
      When set, the GC will strive to not grow the heap beyond the specified size, unless the GC
      decides it's necessary to do so to avoid OutOfMemoryError. The soft max heap size is not
      allowed to be set to a value greater than the maximum heap size (`-Xmx`). When not set on the
      command line, it defaults to a value equal to the maximum heap size.
      
      Being `manageable`, its value can be adjusted at runtime. For example, its value can be
      adjusted by using `jcmd VM.set_flag SoftMaxHeapSize <bytes>` or through the HotSpot MXBean.
      
      Setting this flag can be useful in a number of situations, such as:
      
      * In environments where resource usage is a concern, you might want to keep the heap footprint
      down while also retaining the capability to deal with a temporary increase in heap space
      requirement.
      
      * When using a concurrent GC (such as ZGC), you might want to play it safe and increase the
      confidence level that you will not run into an allocation stall because of an unforeseen
      increase in allocation rate. Setting a soft max heap size encourages the GC to maintain a
      smaller heap, which means the GC will collect garbage more aggressively than it otherwise
      would, making it more resilient to a sudden increase in the application allocation rate.

  JDK-8225516: Load reference barriers for Shenandoah

      Shenandoah used to employ the weak to-space invariant: allow reads to be done from the
      collection set while it is being evacuated, and evacuate objects on writes to them. This
      forced the implementation to have simple read barriers before every read accesses (including
      primitive ones), and complicated write barriers before every write access (including primitive
      ones), plus handling the cases where both copies of the objects are exposed (for example, in
      acmp). With this change, Shenandoah rewires the barriers to employ stronger to-space
      invariant: never expose objects in the collection set, evacuating them eagerly on reference
      load. Implementation rewires that used to be the write barrier handling code to every
      reference load, and removes other barriers (read, acmp, storeval barriers).
      
      The change makes simpler barrier interface, provides more opportunities for performance
      optimizations, reduces the maintenance burden. Even though Shenandoah makes more complicated
      read barriers with this change, the incidence of those barriers is lower, because there are no
      barriers on writes anymore, and only reference loads need to be handled. This makes the change
      performance neutral or performance-positive on many workloads, even with simpler optimization
      code.

  JDK-8226483: Shenandoah Accepts Arbitrarily Low Initial Heap Size

      The Shenandoah implementation has been improved to allow arbitrarily low initial heap size.
      Before this change, Shenandoah needed at least 10 regions to cover `-Xms`. With large heaps
      and/or larger regions, those 10 regions could use a significant amount of space. This
      requirement is relaxed now, and Shenandoah can run with the lowest `-Xms` that the shared JVM
      code can accept.

  JDK-8225343: Improve Ergonomics for Sparse PRT Entry Size

      This enhancement changes the ergonomics for sizing the lowest level (most quickly to access,
      but taking most space per element) remembered set memory storage in G1 called Sparse PRTs.
      
      The number of entries now grow exponentially with region size instead of linearly. This means
      that G1 uses 4/8/16/32/62/128 entries per Sparse PRT if configured for 1/2/4/8/16/32 MB
      regions respectively instead of 4/8/12/16/20/24 entries.
      
      With this change, G1 uses significantly less memory for remembered sets for applications
      requiring a significant amount of remembered sets. This may also result in decreased garbage
      collection pause times in these cases.
      
      The ergonomically determined values may be overridden using the
      `-XX:G1RSetSparseRegionEntries` option as before.

  JDK-8225523: Shenandoah Support for Solaris x86_64

      Shenandoah is designed to be OS agnostic. However, minor differences in accepted language
      features in OS-specific tool chains can prevent it from being buildable on some operating
      systems. This release includes a change that enables Shenandoah builds with Solaris Studio,
      the default tool chain for the Solaris operating system. Testing shows that, after this change
      is applied, Shenandoah is fully operational on Solaris 11.

  JDK-8225531: Shenandoah x86_32 support

      Shenandoah now experimentally supports x86_32 in fully concurrent mode. This allows memory
      footprint improvements in VM-heavy workloads, when most of the memory taken by JVM are
      VM-native structures. This also serves as the proof Shenandoah is implementable on 32-bit
      platforms.

  JDK-8225530: Shenandoah eliminated separate forwarding pointer slot

      Shenandoah uses an extra word per object to store the forwarding pointer of an object in
      support of concurrent evacuation. With the arrival of load reference barriers, it is possible
      to store the forwarding pointer in the then-unused memory of old copy of an object instead,
      for example use the old copy mark-word and encode the forwarding pointer there. This allows to
      eliminate the extra forwarding pointer word, and thus reduces memory footprint to that of
      regular GC.

  JDK-8226475: Improvements in Serial GC Young pause time report

      With Serial GC, when Young GC fails and upgrades to Full GC, the logging messages may be
      confusing. In previous releases, the log would say both "Pause Full" and "Pause Young"
      finished at the same time, leading to double-counting the pause time. In this release, the
      logging is fixed to properly reflect times spent in "Young" and "Full" collections. See more
      at JDK-8215221.

  JDK-8226901: Improve the Behavior of MaxRAM Settings and UseCompressedOops

      The behavior of several GC Heap selection flags have been changed to better meet the
      expectation of users.  
      
      Prior to this change, if the heap size selection resulting from the use of these flags
      exceeded the maximum reachable address when `UseCompressedOops` is enabled, the heap size
      would be truncated to be within the `CompressedOops` range.  Also, the percentage or
      fractional calculation performed was based on the value of `MaxRAM` and not the amount of
      physical memory available in the system.  The following are the options impacted by this
      change:
      
      - `-XX:MaxRAMPercentage` - `-XX:MaxRAMFraction` - `-XX:MinRAMPercentage` -
      `-XX:MinRAMFraction` - `-XX:InitialRAMPercentage` - `-XX:InitialRAMFraction` - `-XX:MaxRAM`
      
      The new behavior calculates the percentage or fraction based on the host's available memory
      unless the user also specifies `-XX:MaxRAM`.  In addition, `UseCompressedOops` is
      automatically disabled if the heap size resulting from the use of any of these options,
      including `-XX:MaxRAM`, is greater than can be addressed in `CompressedOops` mode, unless the
      `-XX:+UseCompressedOops` option is specified to override this behavior.
      
      Note:  This change only impacts 64-bit platforms. 

  JDK-8226476: Shenandoah reduces the default number of GC threads

      In previous releases, Shenandoah GC defaulted to the large number of concurrent and parallel
      GC threads to do the work. In many cases, this lead to taking a significant CPU toll when GC
      was running. In worst case, the system can be saturated with the GC work alone.
      
      In this release, the default number of concurrent and parallel Shenandoah GC threads is
      trimmed down to 1/4 and 1/2 of CPU threads, respectively. Users are advised to check if their
      installations benefit from these new defaults, or adjust `-XX:ConcGCThreads=#` or
      `-XX:ParallelGCThreads=#` if needed.

  JDK-8226477: Epsilon GC Caused Excess Metaspace Resizing Safepoints

      In this release, Epsilon has been changed to accept GC requests and resize the metaspace to
      reduce the number of safepoints that are taken.
      
      Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not
      doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload
      (for example, a workload having lots of classes) needed to resize the metaspace, it relied on
      the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to
      call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be
      generated, but it would not resize the metaspace. This would cause another safepoint to be
      generated soon afterwards without ever resizing the metaspace.

tools/jlink:

  JDK-8226948: A jrt URI Can Only Encode Paths to Files in /modules Tree 

      A `jrt` URL is a hierarchical URI with the syntax `jrt:/[$MODULE[/$PATH]]`. When using the
      `jrt` file system, a `java.net.URI` object can be created with the `java.nio.file.Path::toUri`
      method to encode a normalized path to a file in the `/modules` tree. A `jrt` URL cannot encode
      a path to a file in the `/packages` tree. The `jrt` file system provider has been changed in
      this release so that `toUri` fails with `IOError` when it is not possible to encode the file
      path as a `jrt` URI. This change might impact tools that assume a URI can be created to locate
      files in the `/packages` tree. Tools with paths to files in `/packages` can use the
      `toRealPath()` method to obtain the real path (in `/modules`) before attempting to convert the
      file path to a URI. 


ALL FIXED ISSUES, BY COMPONENT AND PRIORITY:

client-libs:
  (P2) JDK-8214579: JFrame does not paint content in XVFB / X11vnc environment
  (P2) JDK-8210782: Upgrade HarfBuzz to the latest 2.3.1
  (P2) JDK-8217676: Upgrade libpng to 1.6.37
  (P3) JDK-8225368: broken links in java.desktop files
  (P3) JDK-8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3
  (P4) JDK-8221731: Fix doclint handling of accessibility heading in java.desktop
  (P4) JDK-8224876: javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java fails on linux-x64
  (P4) JDK-8220320: Remove unused old code in GraphicsEnvironment on unix

client-libs/2d:
  (P2) JDK-8222362: Upgrade to Freetype 2.10.0
  (P3) JDK-8212202: [Windows] Exception if no printers are installed.
  (P3) JDK-8130266: Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class
  (P3) JDK-8208179: Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK
  (P3) JDK-8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11
  (P3) JDK-8223045: GraphicsEnvironment does not detect resolution changes in multiscreen systems
  (P3) JDK-8224825: java/awt/Color/AlphaColorTest.java fails in linux-x64 system
  (P3) JDK-8217707: JNICALL declaration breaks Splash screen functions
  (P3) JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers
  (P3) JDK-8221411: NullPointerException in RasterPrinterJob without PrinterResolution
  (P3) JDK-8205159: The Header of the print out displayed incomplete
  (P4) JDK-6933331: (d3d/ogl) java.lang.IllegalStateException: Buffers have not been created
  (P4) JDK-8220231: Cache HarfBuzz face object for same font's text layout calls
  (P4) JDK-8214076: Cleanup the code related to GraphicsEnvironment/Device/Configuration
  (P4) JDK-8219675: Disable harfbuzz warnings with gcc 8
  (P4) JDK-8215130: Fix errors in LittleCMS 2.9 reported by GCC 8
  (P4) JDK-8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth
  (P4) JDK-8222917: GraphicsEnvironment for Unix still have an unused dependency on Solaris
  (P4) JDK-8225007: java/awt/print/PrinterJob/LandscapeStackOverflow.java may hang
  (P4) JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
  (P4) JDK-8219676: Re-enable harfbuzz warnings
  (P4) JDK-8218914: Support fonts installed per-user on Windows 10
  (P4) JDK-8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar
  (P4) JDK-8214918: Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms

client-libs/java.awt:
  (P2) JDK-8227919: 8213232 causes crashes on solaris sparc64
  (P2) JDK-8214046: [macosx] Undecorated Frame does not Iconify when set to
  (P2) JDK-8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579
  (P2) JDK-8177960: Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS
  (P2) JDK-8226654: Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK libraries"
  (P2) JDK-8220495: Update GIFlib library to the 5.1.8
  (P3) JDK-8220528: [AIX] Fix basic Xinerama and Xrender functionality
  (P3) JDK-8061381: [macosx] Accelerators does not spelled for JMenuItems by Voice Over 
  (P3) JDK-8214765: All TrayIcon MessageType icons does not show up with gtk3 option set
  (P3) JDK-8207938: At step6,Click Add button,case failed automatically.
  (P3) JDK-8212676: AWT SystemColor setting on CDE
  (P3) JDK-8211885: Duplicate id declarations in java.awt.geom.Path2D
  (P3) JDK-8220250: fix headings in java.desktop
  (P3) JDK-8215200: IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow
  (P3) JDK-8225376: invalid HTML in AWT_Native_Interface.html
  (P3) JDK-8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color
  (P3) JDK-8215756: Memory leaks in the AWT on macOS
  (P3) JDK-8221246: NullPointerException within Win32ShellFolder2
  (P3) JDK-8222789: Replace the usage of "Sun's Xinerama API" by the "XFree86's Xinerama API" on Solaris
  (P3) JDK-8225118: Robot.createScreenCapture() returns black image on HiDPI linux with gtk3
  (P3) JDK-8223271: SplashScreen is still shown if defaulting to headless on MacOS
  (P3) JDK-8211826: StringIndexOutOfBoundsException happens via GetStringUTFRegion()
  (P3) JDK-8216318: The usage of Disposer in the java.awt.Robot can be deleted
  (P3) JDK-8213232: Unix/X11 setCompositionEnableNative issue
  (P3) JDK-8212678: Windows IME related patch
  (P3) JDK-8212677: X11 default visual support for IM status window on VNC
  (P3) JDK-8214109: XToolkit is not correctly displayed color on 16-bit high color setting
  (P4) JDK-8144125: [macos] java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically
  (P4) JDK-7141393: [macosx] CARemoteLayer code refactoring and unit test
  (P4) JDK-8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type
  (P4) JDK-8224771: backout RemoveDropTargetCrashTest.java fix to re-push with correct bugid
  (P4) JDK-8216155: C4819 warning at libfreetype sources on Windows
  (P4) JDK-8212700: Change the mechanism by which JDK loads the platform-specific AWT Toolkit
  (P4) JDK-8225032: Fix some C++ conformance issues in AWT Windows code
  (P4) JDK-8221405: Fix Windows 32bit awt build
  (P4) JDK-8225487: giflib legal file is missing attribution for openbsd-reallocarray.c.
  (P4) JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64
  (P4) JDK-8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10
  (P4) JDK-8214823: Javadoc cleanup of java.awt.desktop package
  (P4) JDK-8223766: Remains of ancient code in AWT initialization
  (P4) JDK-8216592: Removal of the class sun.awt.AWTSecurityManager
  (P4) JDK-8222819: Remove setting of headless property on MacOS from launcher code.
  (P4) JDK-8223237: Replace use of string.equals("") with isEmpty() in java.desktop
  (P4) JDK-8214461: Some unused classes may be removed
  (P4) JDK-8211267: StackOverflowError happened by TextField.setFont(...)
  (P4) JDK-8219504: Test for JDK-8211435 can be run on all platforms
  (P4) JDK-8224830: test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64
  (P4) JDK-8215910: Typo in AWT InvocationEvent Method Documentation

client-libs/java.awt:i18n:
  (P3) JDK-8225182: JNI exception pending in DestroyXIMCallback of awt_InputMethod.c:1327
  (P4) JDK-8213183: InputMethod cannot be used after its restarting

client-libs/java.beans:
  (P3) JDK-8221244: Unexpected behavior of PropertyDescription.getReadMethod for boolean properties
  (P4) JDK-8222799: java.beans.Introspector uses an obsolete methods cache
  (P4) JDK-8216046:  test/jdk/java/beans/PropertyEditor/Test6397609.java failing

client-libs/javax.accessibility:
  (P3) JDK-8216008: -Djavax.accessibility.assistive_technologies empty list leads to exception
  (P3) JDK-8219914: Change the environment variable for Java Access Bridge logging to have a directory
  (P3) JDK-8190361: Incorrect version info in jaccessinspector.exe and jaccesswalker.exe
  (P3) JDK-8196681: Java Access Bridge logging and debug flags dynamically controlled
  (P3) JDK-6714324: Removing a component from a JTabbedPane does not clear its accessibleParent
  (P4) JDK-7106851: Test should not use System.exit

client-libs/javax.sound:
  (P4) JDK-8222438: Drop of outdated logging in the com.sun.media.sound package
  (P4) JDK-8221445: FastSysexMessage constructor crashes MIDI receiption thread
  (P4) JDK-8224056: Fix some assignments of string literals to LPSTR (instead of LPCSTR)
  (P4) JDK-8221436: Incorrect check of package in Line.Info.toString()
  (P4) JDK-8222083: Support of "64-bit IEEE floating point" encoding for the AU file format

client-libs/javax.swing:
  (P1) JDK-8226964: [Yaru] GTK L&F: There is no difference between menu selected and de-selected
  (P2) JDK-8226783: GTK is not being returned as the System L&F on Gnome.
  (P2) JDK-8218473: JOptionPane display issue with GTKLookAndFeel
  (P2) JDK-8218472: JProgressBar display issue with GTKLookAndFeel
  (P2) JDK-8218470: JScrollBar display issue with GTKLookAndFeel
  (P2) JDK-8218469: JSlider display issue with slider for GTKLookAndFeel
  (P2) JDK-8218479: JTextPane display issue with GTKLookAndFeel
  (P2) JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys
  (P2) JDK-8203627: Swing applications with JRadioButton and JCheckbox fail to render correctly when using GTK3 and the GTK L&F
  (P3) JDK-8225144: [macos] In Aqua L&F backspace key does not delete when Shift is pressed
  (P3) JDK-8213071: [macos] The focus disappears after pressing return to close the "That was a pretty good movie!" dialog.
  (P3) JDK-8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK
  (P3) JDK-8225146: Accessibility issues in javax/swing/plaf/nimbus/doc-files/properties.html
  (P3) JDK-8218599: Add test group jdk_client_sanity under jdk_desktop group
  (P3) JDK-8222519: ButtonDemoScreenshotTest fails randomly with "still state to be reached"
  (P3) JDK-8217235: Create automated test for SwingSet ColorChooserDemoTest
  (P3) JDK-8214471: Enable different look and feel tests in SwingSet3 demo test ToolTipDemoTest
  (P3) JDK-8225423: GTK L&F: JSplitPane: There is no divider shown
  (P3) JDK-8218674: HTML Tooltip with "img src=" on component doesn't show
  (P3) JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame
  (P3) JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT
  (P3) JDK-8212904: JTextArea line wrapping incorrect when using UI scale
  (P3) JDK-8219156: RTFEditorKit writes background color but doesn't read
  (P3) JDK-8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour
  (P3) JDK-8214112: The whole text in target JPasswordField image are not selected.
  (P3) JDK-8214111: There is no icon in all JOptionPane target image
  (P3) JDK-8214253: Tooltip is transparent rather than having a black background 
  (P3) JDK-8213781: web page background renders blue in JEditorPane
  (P3) JDK-8214702: Wrong text position for whitespaced string in printing Swing text
  (P4) JDK-8219552: bump jtreg requiredVersion to b14 in test/jdk/sanity/client/
  (P4) JDK-8221661: javax.swing.text.View.getPreferredSpan​(int axis)
  (P4) JDK-8225511: javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java fails in linux-x64
  (P4) JDK-8212701: remove sun.desktop property from launcher code
  (P4) JDK-8215909: Typo in Swing ProcessMouseEvent method documentation
  (P4) JDK-8216353: Use utility APIs introduced in org/netbeans/jemmy/util/LookAndFeel class in client sanity test cases
  (P5) JDK-6684386: ElementIterator javadoc bug

core-libs:
  (P3) JDK-8216401: Allow "file:" URLs in Class-Path of local JARs
  (P3) JDK-8211941: Enable checking/ignoring of non-conforming Class-Path entries
  (P3) JDK-8220261: fix headings in java.base
  (P3) JDK-8205626: Start of release updates for JDK 13
  (P3) JDK-8213223: Umbrella: JDK 13 terminal deprecations
  (P3) JDK-8228450: unicode.md and icu.md text should be pre-formatted
  (P3) JDK-8215798: Use {@systemProperty} for org.openjdk.java.util.stream.tripwire system property
  (P3) JDK-8212528: Wrong cgroup subsystem being used for some CPU Container Metrics
  (P4) JDK-8214077: ARM32: test java/io/File/SetLastModified.java fails on ARM32
  (P4) JDK-8223553: Fix code constructs that do not compile with the Eclipse Java Compiler
  (P4) JDK-8220072: GCC 8.3 reports errors in java.base
  (P4) JDK-8220598: Malformed copyright year range in a few files in java.base
  (P4) JDK-8215217: OpenJDK source has too many swear words
  (P4) JDK-8223593: Refactor code for reallocating storage
  (P4) JDK-8225315: test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group
  (P5) JDK-8218022: Repeated words typos in java.base

core-libs/java.io:
  (P3) JDK-8214565: Use {@systemProperty} for definitions of system properties
  (P4) JDK-8221597: A typo in the Java API doc for File.getUsableSpace()
  (P4) JDK-8221262: Cleanups in UnixFileSystem/WinNTFileSystem implementation classes
  (P4) JDK-8219992: Correct the documentation of PrintWriter to refer to System.lineSeparator
  (P4) JDK-8219196: DataOutputStream.writeUTF may throw unexpected exceptions
  (P4) JDK-8216172: File.renameTo(File dest) should check for NPE at the very beginning
  (P4) JDK-8218280: LineNumberReader throws "Mark invalid" exception if CRLF straddles buffer.
  (P4) JDK-8215412: Optimize PrintStream.println methods
  (P4) JDK-6307456: UnixFileSystem_md.c use of chmod() and access() should handle EINTR signal appropriately (unix)
  (P5) JDK-8078860: (spec) InputStream.read(byte[] b, int off, int len) claims to not affect element b[off] 
  (P5) JDK-8216067: Unused local vars in windows/native/libjava/io_util_md.c

core-libs/java.io:serialization:
  (P3) JDK-8226605: Accessibility issues in specs/serialization/*.html
  (P3) JDK-6996807: FieldReflectorKey hash code computation can be improved
  (P4) JDK-8220166: Performance regression in deserialization (4-6% in SPECjbb)
  (P4) JDK-8202675: Replace process-wide terminology in serial filtering to be consistent
  (P4) JDK-8227541: Serial spec should be updated to reflect API generification
  (P5) JDK-6394787: Typos in javadoc of OIS.readObjectOverride and OOS.writeObjectOverride

core-libs/java.lang:
  (P2) JDK-8223777: In posix_spawn mode, failing to exec() jspawnhelper may not result in an error
  (P2) JDK-8226709: MethodTypeDesc::resolveConstantDesc needs access check per the specification
  (P3) JDK-8213192: (process) Change the Process launch mechanism default on Linux to be posix_spawn
  (P3) JDK-8216134: (process) ProcessBuilder startPipeline does not hide piped streams
  (P3) JDK-8223078: Add microbenchmark for array copying/clearing/resizing
  (P3) JDK-8197927: Allow the system property `java.vendor.version` to be undefined
  (P3) JDK-8225314: broken links in java.base
  (P3) JDK-8217339: ClassCircularityError loading NumberFormatProvider
  (P3) JDK-8218386: Correct the SE version in j.l.Character
  (P3) JDK-8220238: Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement
  (P3) JDK-8216205: Java API documentation formatting error in System.getEnv()
  (P3) JDK-8224181: On child process spawn, child may write to random file descriptor instead of the fail pipe
  (P3) JDK-8203444: String::formatted (Preview)
  (P3) JDK-8223775: String::stripIndent (Preview)
  (P3) JDK-8223780: String::translateEscapes  (Preview)
  (P3) JDK-8225448: String::translateEscapes javadoc has accessibility issues
  (P3) JDK-8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified
  (P3) JDK-8218228: The constructor StringBuffer(CharSequence) violates spec for negatively sized argument
  (P4) JDK-8224986: (str) optimize StringBuilder.append(CharSequence, int, int) for String arguments
  (P4) JDK-8225353: Add @jls links to java.lang.Enum
  (P4) JDK-8221836: Avoid recalculating String.hash when zero
  (P4) JDK-8221723: Avoid storing zero to String.hash
  (P4) JDK-8221267: Document the jdk.net.URLClassPath.showIgnoredClassPathEntries system property
  (P4) JDK-8224175: Fix inconsistencies in @jls and @jvms tags
  (P4) JDK-8215017: Improve String::equals warmup characteristics
  (P4) JDK-8224174: java.lang.Number has a default constructor
  (P4) JDK-8210788: Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero
  (P4) JDK-8224783: Javadoc of String strip methods uses link where linkplain would be better
  (P4) JDK-8218726: Minor Throwable.printStackTrace() typos
  (P4) JDK-8222029: Optimize Math.floorMod
  (P4) JDK-8222955: Optimize String.replace(CharSequence, CharSequence) for common cases
  (P4) JDK-8225675: Outdated citation of JLS in java.lang.ref.Reference
  (P4) JDK-8220684: Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout
  (P4) JDK-8220237: ProcessBuilder  API documentation typo
  (P4) JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull
  (P4) JDK-8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName
  (P4) JDK-8205131: remove Runtime trace methods
  (P4) JDK-8074817: Resolve disabled warnings for libverify
  (P4) JDK-8218227: StringBuilder/StringBuffer constructor throws confusing NegativeArraySizeException
  (P4) JDK-8221431: Support for Unicode 12.1
  (P4) JDK-8219197: ThreadGroup.enumerate() may return wrong value
  (P4) JDK-8223730: URLClassLoader.findClass() can throw IndexOutOfBoundsException
  (P5) JDK-8221921: Implement size() / isEmpty() in immutable collections
  (P5) JDK-8216413: Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long}

core-libs/java.lang.invoke:
  (P2) JDK-8222895: StackOverflowError in custom security manager that relies on ClassSpecializer
  (P3) JDK-8219480: j.l.c.ClassDesc::arrayType(int rank) throws IllegalArgumentException if rank = 0
  (P3) JDK-8219483: j.l.c.ClassDesc::nested(String, String...) doesn't throw NPE if any arg is null
  (P3) JDK-8223725: j.l.c.MethodHandleDesc::of throws undocumented exception IllegalArgumentException
  (P3) JDK-8223723: j.l.c.MethodTypeDesc.dropParameterTypes​ throws the undocumented exception: IllegalArgumentException
  (P3) JDK-8223803: j.l.c.MethodTypeDesc::insertParameterTypes​ doesn't control type of parameters
  (P3) JDK-8213234: Move LambdaForm.Hidden to jdk.internal.vm.annotation
  (P3) JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown
  (P4) JDK-8220282: Add MethodHandle tests on accessing final fields 
  (P4) JDK-8219487: j.l.c.ClassDesc spec should contain precise assertions for one parameter's methods
  (P4) JDK-8223726: j.l.c.MethodTypeDesc spec should contain precise assertions for one parameter's methods
  (P4) JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for static final field
  (P4) JDK-8222852: Reduce String concat combinator tree shapes by folding constants into prependers
  (P4) JDK-8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer
  (P4) JDK-8222484: Specialize generation of simple String concatenation expressions

core-libs/java.lang.module:
  (P4) JDK-8221473: Configuration::reads can use Set.copyOf

core-libs/java.lang:class_loading:
  (P4) JDK-8222144: BuiltinClassLoader should create the CodeSource for jrt URLs lazily
  (P4) JDK-8218419: Can't get annotations that are present on packages in -Xbootclasspath/a

core-libs/java.lang:reflect:
  (P1) JDK-8222082: Build of test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c still failing on Windows
  (P1) JDK-8222078: test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c build fails after 8221530
  (P2) JDK-8224012: AnnotatedType implementations of hashCode() lead to StackOverflowError
  (P2) JDK-8222111: exeCallerAccessTest.c fails to build: control reaches end of non-void function
  (P3) JDK-8221530: Field::get and reflective member access not handling caller = null when invoked by JNI code with no java frames on stack
  (P3) JDK-8198526: getAnnotatedOwnerType does not handle static nested classes correctly
  (P3) JDK-8222448: java/lang/reflect/PublicMethods/PublicMethodsTest.java times out
  (P4) JDK-7086604: (reflect) Clarifications to javadoc for getGeneric*Type methods in j.l.r
  (P4) JDK-8227252: [aix] Disable jdk/java/lang/reflect/exeCallerAccessTest
  (P4) JDK-8225465: Add @jls tags to receiver type methods
  (P4) JDK-8042748: Clarify exception thrown by ParameterizedTypeImpl.validateConstructorArguments()
  (P4) JDK-8181869: getAnnotatedParameterTypes​() specification should be clarified
  (P4) JDK-8219378: NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized
  (P4) JDK-8217000: Refactor Class::methodToString

core-libs/java.math:
  (P4) JDK-8215759: [test] java/math/BigInteger/ModPow.java can throw an ArithmeticException
  (P4) JDK-8183912: java.math.BigDecimal.movePointLeft() should return this if called with zero argument
  (P4) JDK-8225117: java/math/BigInteger/SymmetricRangeTests.java fails with ParseException

core-libs/java.net:
  (P1) JDK-8229018: Switching to an infinite socket timeout on Windows leads to high CPU load
  (P3) JDK-8220673: Add test library support for determining platform IP support
  (P3) JDK-8220719: Allow other named NetPermissions  to be used
  (P3) JDK-8220575: Correctly format test URI's that contain a retrieved IPv6 address
  (P3) JDK-8217364: Custom URLStreamHandler for jrt or file protocol can override default handler.
  (P3) JDK-8216978: Drop support for pre JDK 1.4 SocketImpl implementations
  (P3) JDK-8217237: HttpClient does not deal well with multi-valued WWW-Authenticate challenge headers
  (P3) JDK-8221395: HttpClient leaving connections in CLOSE_WAIT state until Java process ends
  (P3) JDK-8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available
  (P3) JDK-8217264: HttpClient: Blocking operations in mapper function do not work as documented
  (P3) JDK-8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior
  (P3) JDK-8216974: HttpConnection not returned to the pool after 204 response
  (P3) JDK-8218554: HttpServer: allow custom handlers to request that the connection be closed after the exchange.
  (P3) JDK-8220663: Incorrect handling of IPv6 addresses in Socket(Proxy.HTTP)
  (P3) JDK-8223214: Inet6AddressImpl.loopbackAddress() should choose loopback address that is available
  (P3) JDK-8224477: java.net socket types new-style socket option methods - spec and impl mismatch
  (P3) JDK-8225060: java.net.DefaultInterface invokes NetworkInterface::getInetAddresses without doPriv 
  (P3) JDK-8225037: java.net.JarURLConnection::getJarEntry() throws NullPointerException
  (P3) JDK-8224730: java.net.ServerSocket::toString not invoking checkConnect
  (P3) JDK-8194231: java/net/DatagramSocket/ReuseAddressTest.java failed with java.net.BindException: Address already in use: Cannot bind
  (P3) JDK-8228434: jdk/net/Sockets/Test.java fails after JDK-8227642
  (P3) JDK-8218559: JEP 353: Reimplement the Legacy Socket API
  (P3) JDK-8170494: JNI exception pending in PlainDatagramSocketImpl.c
  (P3) JDK-8226730: Missing `@` in code tags
  (P3) JDK-8220493: Prepare Socket/ServerSocket for alternative platform SocketImpl
  (P3) JDK-8221481: Reimplement the Legacy Socket API
  (P3) JDK-8220083: Remove hard-coded 127.0.0.1 loopback address in JDK networking tests
  (P3) JDK-8225426: Replace plain with system-default in Socket and ServerSocket
  (P3) JDK-8223145: Replace wildcard address with loopback or local host in tests - part 1
  (P3) JDK-8224204: Replace wildcard address with loopback or local host in tests - part 10
  (P3) JDK-8224603: Replace wildcard address with loopback or local host in tests - part 11
  (P3) JDK-8224761: Replace wildcard address with loopback or local host in tests - part 12
  (P3) JDK-8224865: Replace wildcard address with loopback or local host in tests - part 13
  (P3) JDK-8225512: Replace wildcard address with loopback or local host in tests - part 15
  (P3) JDK-8223463: Replace wildcard address with loopback or local host in tests - part 2
  (P3) JDK-8223465: Replace wildcard address with loopback or local host in tests - part 3
  (P3) JDK-8223573: Replace wildcard address with loopback or local host in tests - part 4
  (P3) JDK-8223632: Replace wildcard address with loopback or local host in tests - part 5
  (P3) JDK-8223856: Replace wildcard address with loopback or local host in tests - part 8
  (P3) JDK-8213912: Semantic typo in HttpExchange.java
  (P3) JDK-8216988: ServerSocket.implAccept should include warnings about Socket type/state
  (P3) JDK-8225214: Socket.getOption(SocketOption) not returning the expected type for the StandardSocketOptions.SO_LINGER
  (P3) JDK-8227422: sun/net/www/protocol/file/DirPermissionDenied.java failed on Windows 2016 because DirPermissionDenied directory has no read permission
  (P3) JDK-8224973: URLStreamHandler.openConnection(URL,Proxy) - spec and implementation mismatch
  (P3) JDK-8217429: WebSocket over authenticating proxy fails to send Upgrade headers
  (P4) JDK-8225424: Add jdk.net.usePlainSocketImpl runs to a couple of tests
  (P4) JDK-8215990: Avoid using reflection to create common default URLStreamHandlers
  (P4) JDK-8216478: Cleanup HttpResponseImpl back reference to HttpConnection
  (P4) JDK-8216417: cleanup of IPv6 scope-id handling 
  (P4) JDK-8216498: Confusing and unneeded wrapping of SSLHandshakeException
  (P4) JDK-8153508: ContentHandler API contains link to private contentPathProp
  (P4) JDK-8224014: Don't run test/jdk/java/net/NetworkInterface/IPv4Only.java in IPv6 only environment
  (P4) JDK-8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported
  (P4) JDK-8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA
  (P4) JDK-8007606: Handle realloc() failure in unix/native/libnet/net_util_md.c correctly
  (P4) JDK-8223737: HostsFileNameService doesn't handle IPv6 literal addresses correctly
  (P4) JDK-8222527: HttpClient doesn't send HOST header when tunelling HTTP/1.1 through http proxy
  (P4) JDK-8216561: HttpClient: The logic of retry on connect exception is inverted
  (P4) JDK-8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix)
  (P4) JDK-8220585: Incorrect code in MulticastSocket sample code
  (P4) JDK-8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)
  (P4) JDK-8223457: java.net.ServerSocket protected constructor should throw NPE if impl null
  (P4) JDK-8225651: Missed the `@` in a couple of code tags of SocketImpl
  (P4) JDK-8216355: missing NULL checks in libnet  in interface iteration and potential resource leak in getMacAddress
  (P4) JDK-8218882: NET_Writev is declared, NET_WriteV is defined
  (P4) JDK-8216986: Remove unused code from SocksSocketImpl
  (P4) JDK-8223652: Rename IPSupport.skipIfCurrentConfigurationIsInvalid()
  (P4) JDK-8223638: Replace wildcard address with loopback or local host in tests - part 6
  (P4) JDK-8223798: Replace wildcard address with loopback or local host in tests - part 7
  (P4) JDK-8224035: Replace wildcard address with loopback or local host in tests - part 9
  (P4) JDK-8221098: Run java/net/URL/HandlerLoop.java in othervm mode
  (P4) JDK-8224081: SOCKS v4 tests require IPv4
  (P4) JDK-8217740: SocksIPv6Test.java compilation error
  (P4) JDK-8219446: Specify behaviour of timeout accepting methods of Socket and ServerSocket if timeout is negative
  (P4) JDK-8223716: sun/net/www/http/HttpClient/MultiThreadTest.java should be more resilient to unexpected traffic
  (P4) JDK-8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException"
  (P4) JDK-8170705: sun/net/www/protocol/http/StackTraceTest.java fails intermittently with Invalid Http response
  (P4) JDK-8224248: test/jdk/java/net/InetAddress/CheckJNI.java assumes 127.0.0.1 is available
  (P4) JDK-8224018: test/jdk/java/net/ipv6tests/{Tcp,Udp}Test.java assume IPv4 is available
  (P4) JDK-8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
  (P4) JDK-8182992: Typo in DatagramPacket constructor API doc
  (P4) JDK-8220480: Typo in java.net.http.HttpResponse.BodySubscriber documentation
  (P4) JDK-8179549: Typo in network properties documentation
  (P4) JDK-8223880: Update sun/net/ftp/FtpURL.java and sun/net/ftp/FtpURLConnectionLeak.java to work with IPv6 addresses
  (P4) JDK-8219202: Use Unsynchronized StringBuilder in sun.net.www.ParseUtil
  (P4) JDK-8215912: Various Typos in java.net Method Documentation
  (P4) JDK-8221406: Windows 32bit build error in NetworkInterface_winXP.c
  (P5) JDK-8184315: Typo in java.net.JarURLConnection.getCertificates() method documentation
  (P5) JDK-8223921: Update SocketReadWrite benchmark

core-libs/java.nio:
  (P2) JDK-8221824: Build failure with MSVS 2013 after JDK-8218418
  (P3) JDK-8065262: (bf spec) CharBuffer.chars() should make it clearer that the sequence starts from the buffer position
  (P3) JDK-5029431: (bf) Add absolute bulk put and get methods
  (P3) JDK-8011135: (bf) CharBuffer.put(String) is slow because of String.charAt() call for each char
  (P3) JDK-8226203: (bf) MappedByteBuffer.force method may have no effect on implementation specific map modes
  (P3) JDK-8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset
  (P3) JDK-8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present
  (P3) JDK-8223597: (zipfs) jdk/nio/zipfs/ZipFSTester.java RuntimeException: CHECK_FAILED! (getAttribute.crc <entries20> failed 6af4413c vs 0 ...)
  (P3) JDK-8222807: (zipfs) OutOfMemory on compiling with darcula.jar in classpath
  (P3) JDK-8222532: (zipfs) Performance regression when writing ZipFileSystem entries in parallel
  (P3) JDK-8211919: (zipfs) ZipDirectoryStream should provide a stream of paths that are relative to the directory
  (P3) JDK-8223442: java/nio/channels/SocketChannel/AdaptorStreams.java testConcurrentTimedReadWrite3(): failure
  (P3) JDK-8182117: jdk.zipfs should document the "create" and "encoding" properties
  (P3) JDK-8210469: missing doPrivileged and permission in jdk.zipfs
  (P3) JDK-8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException
  (P3) JDK-8214563: Use {@systemProperty} in specification of system properties in java.nio packages
  (P4) JDK-5071718: (bf) Add ByteBuffer.slice(int index, int length)
  (P4) JDK-8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize()
  (P4) JDK-8219597: (bf) Heap buffer state changes could provoke unexpected exceptions
  (P4) JDK-8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes
  (P4) JDK-8221696: (bf) MappedByteBuffer.force method to specify range
  (P4) JDK-8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer.
  (P4) JDK-8223353: (ch) Change channel close implementation to not wait for I/O threads
  (P4) JDK-8222774: (ch) Replace uses of stateLock and blockingLock with j.u.c. locks
  (P4) JDK-8221397: (fc) Support implementation-defined Map Modes
  (P4) JDK-8218875: (fs) Add FileSystems.newFileSystem(Path, Map<String, ?>) method
  (P4) JDK-8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win)
  (P4) JDK-8224617: (fs) java/nio/file/FileStore/Basic.java found filesystem twice
  (P4) JDK-8220793: (fs) No support for changing modification time of symlink
  (P4) JDK-8220738: (sc) Move ServerSocketChannelImpl remaining native method to Net
  (P4) JDK-8217500: (sc) Move SocketChannelImpl's remaining native methods to Net 
  (P4) JDK-8215472: (zipfs) Cleanups in implementation classes of jdk.zipfs and tests
  (P4) JDK-8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031
  (P4) JDK-8224042: Add private alignDown method to MappedByteBuffer
  (P4) JDK-8220477: Channels.newWriter() does not close if underlying channel throws an IOException
  (P4) JDK-8223015: Cleanups for zipfs tests
  (P4) JDK-8215467: Files.isHidden should return true for hidden directories on Windows
  (P4) JDK-8223178: Improve FileSystems.newFileSystem example with map factory methods
  (P4) JDK-8221852: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time
  (P4) JDK-8218460: Test generation scripts do not invoke stream preprocessor correctly
  (P4) JDK-8224019: test/jdk/java/nio/channels/DatagramChannel/BasicMulticastTests.java assumes IPv4 is always available
  (P4) JDK-8215372: test/jdk/java/nio/file/DirectoryStream/Basic.java not correct when using a glob
  (P5) JDK-5043362: (bf) NewDirectByteBuffer always has order ByteOrder.BIG_ENDIAN
  (P5) JDK-8048192: (bf) Out of direct buffer memory message should include the limits

core-libs/java.nio.charsets:
  (P3) JDK-8217880: AIX build issue after JDK-8214533
  (P3) JDK-8216140: Correct UnicodeDecoder U+FFFE handling
  (P3) JDK-8214533: IBM-29626C is required for AIX default charset
  (P3) JDK-8220281: IBM-858 alias name is missing on IBM00858 charset 
  (P4) JDK-7061590: Javadoc issues in Charset and StandardCharsets

core-libs/java.rmi:
  (P3) JDK-8217412: deprecate rmic for removal
  (P3) JDK-8217405: rmic should reject class files with preview features enabled
  (P4) JDK-4887513: Typo in RMIFailureHandler interface doc page

core-libs/java.sql:
  (P3) JDK-8225306: bad headings in java.sql.rowset SyncProvider.java
  (P3) JDK-8225322: Broken links in java.sql
  (P4) JDK-8215911: Various Typos in SQL Method Documentation

core-libs/java.text:
  (P2) JDK-8227127: Era designator not displayed correctly using the COMPAT provider
  (P3) JDK-8208487: Australian locale month names contain spurious dot at the end
  (P3) JDK-8217254: CompactNumberFormat:: CompactNumberFormat​() constructor does not comply with spec.
  (P3) JDK-8217721: CompactNumberFormat:: format​() method spec for IAEx is not complaint
  (P3) JDK-8218948: SimpleDateFormat :: format - Zone Names are not reflected correctly during run time
  (P4) JDK-8216969: ParseException thrown for certain months with russian locale 

core-libs/java.time:
  (P3) JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a
  (P3) JDK-8222668: Add @since tag to JapaneseEra.REIWA
  (P3) JDK-8225580: tzdata2018i integration causes test failures on jdk-13
  (P4) JDK-8223773: DateTimeFormatter Fails to throw an Exception on Invalid HOUR_OF_AMPM

core-libs/java.util:
  (P3) JDK-8225094: Fix minor HTML issues in jdk.zipfs
  (P3) JDK-8220005: java/util/Arrays/TimSortStackSize2.java times out
  (P3) JDK-8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build
  (P4) JDK-8217969: Base64.Decoder.decode methods do not need to throw OOME due to integer overflow
  (P4) JDK-8210583: Base64.Encoder incorrectly throws NegativeArraySizeException
  (P4) JDK-8223112: Clarify operational semantics of java.util.Objects.equals()
  (P4) JDK-8219548: Improve src/java.base/share/classes/java/util/spi/ToolProvider.java null parameter checking
  (P4) JDK-8225397: Integer value miscalculation in toString() method of BitSet
  (P4) JDK-8224240: Properties.load fails to throw IAE on malformed unicode in certain circumstances
  (P4) JDK-8221980: Simplify Optional implementation
  (P4) JDK-8224202: Speed up Properties.load
  (P4) JDK-8217777: TEST_BUG: jdk/java/util/prefs/ExportSubtree.java passes even when test should fail

core-libs/java.util.concurrent:
  (P2) JDK-8220478: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out intermittently
  (P3) JDK-8222930: ConcurrentSkipListMap.clone() shares size variable between original and clone
  (P3) JDK-8224698: ConcurrentSkipListMap.java does not compile with the Eclipse Java Compiler
  (P3) JDK-8220248: fix headings in java.util.concurrent
  (P3) JDK-8215249: Miscellaneous changes imported from jsr166 CVS 2019-02
  (P3) JDK-8219138: Miscellaneous changes imported from jsr166 CVS 2019-05
  (P3) JDK-8223245: Miscellaneous changes imported from jsr166 CVS 2019-06
  (P3) JDK-8221892: ThreadPoolExecutor: Thread.isAlive() is not equivalent to not being startable
  (P4) JDK-8223379: Clarify ForkJoinPool.getStealCount() javadoc
  (P4) JDK-8221120: CopyOnWriteArrayList.set should always have volatile write semantics
  (P4) JDK-8224176: Fix inconsistencies in @jls tags in java.util.concurrent
  (P4) JDK-8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly throws
  (P4) JDK-8215363: needless signals in ForkJoinPool

core-libs/java.util.jar:
  (P2) JDK-8225189: assert(!JavaThread::current()->in_critical()) failed: Would deadlock
  (P2) JDK-8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null
  (P3) JDK-8215192: bad table headers in pack-spec.md
  (P3) JDK-8216362: Better error message handling when there is an invalid Manifest
  (P3) JDK-8226592: Fix HTML in table for jdk.zipfs module-info
  (P4) JDK-8214712: Archive Attributes$Name.KNOWN_NAMES
  (P4) JDK-8066619: Fix deprecation warnings in java.util.jar
  (P4) JDK-8215922: jar spec is not precise when describing jar file re-signing
  (P4) JDK-8217393: java.util.jar.Attributes:equals() javadoc is not accurate

core-libs/java.util.logging:
  (P3) JDK-8195716: BootstrapLoggerTest : Executor still alive
  (P3) JDK-8220262: fix headings in java.logging
  (P4) JDK-8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference
  (P4) JDK-8216363: NullPointerException in java.util.logging.Handler#isLoggable

core-libs/java.util.regex:
  (P2) JDK-8225061: Performance regression in Regex
  (P3) JDK-8223174: Pattern.compile() can throw confusing NegativeArraySizeException
  (P3) JDK-8222978: Upgrade the extended grapheme cluster support to the latest Unicode level.
  (P4) JDK-8225179: (regex) Minor Pattern cleanup
  (P4) JDK-8225198: Optimize regex tree for greedy quantifiers of type {N,}
  (P4) JDK-8224789: Parsing repetition count in regex does not detect numeric overflow

core-libs/java.util:collections:
  (P3) JDK-8227368: EnumSet.class serialization broken in JDK 9+
  (P3) JDK-8221924: get(null) on single-entry unmodifiable Map returns null instead of throwing NPE
  (P4) JDK-8215995: Add specialized toArray methods to immutable collections
  (P4) JDK-8214687: Optimize Collections.nCopies().hashCode() and equals()
  (P4) JDK-8221981: Simplify Map/List/Set.of() implementation
  (P5) JDK-8210280: Unnecessary reallocation when invoking HashMap.putAll()

core-libs/java.util:i18n:
  (P2) JDK-8174268: Declare a public field in JapaneseEra for the era starting May 2019
  (P3) JDK-8226876: Assertion in sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
  (P3) JDK-8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales
  (P3) JDK-8218960: CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO
  (P3) JDK-8209175: Handle 'B' character introduced in CLDR 33 JDK update for Burmese (my) locale
  (P3) JDK-8220037: Inconsistencies of generated timezone files between Windows and Linux
  (P3) JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider
  (P3) JDK-8217609: New era placeholder not recognized by java.text.SimpleDateFormat
  (P3) JDK-8205432: Replace the placeholder Japanese era name
  (P3) JDK-8226869: Test java/util/Locale/LocaleProvidersRun.java should enable assertions
  (P3) JDK-8222980: Upgrade IANA Language Subtag Registry to Version 2019-04-03
  (P3) JDK-8220224: With CLDR provider, NumberFormat.format could not handle locale with number extension correctly.
  (P3) JDK-8217366: ZoneStrings are not populated for all the Locales 
  (P4) JDK-8221701: Archive constant BaseLocales
  (P4) JDK-8224105: Cannot parse JapaneseDate string on some specified locales
  (P4) JDK-8220227: Host Locale Provider getDisplayCountry returns error message under non-English Win10
  (P4) JDK-8228971: Locale API doc has redundant hyphens for some parameters
  (P4) JDK-8221432: Upgrade CLDR to Version 35.1

core-libs/javax.annotation.processing:
  (P3) JDK-8225077: fix references to broken link in java.compiler module
  (P4) JDK-8146726: Improve AbstractProcessor to issue warnings for repeated information
  (P4) JDK-8216335: Minor cleanups to javax.annotation.processing and javax.lang.model javadoc
  (P4) JDK-8222378: Provide mechanism to query preview feature status for annotation processors
  (P4) JDK-8222817: Refactor printing processor to use streams

core-libs/javax.lang.model:
  (P3) JDK-8208371: Provided supported mechanims to create a ModuleElement for an unnamed module
  (P4) JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces
  (P4) JDK-8205393: Add SourceVersion.RELEASE_13
  (P4) JDK-8222430: Add tests for ElementKind predicates
  (P4) JDK-8219805: Cross-link javax.lang.model.{type, element} packges to utility interfaces
  (P4) JDK-8216404: Elements.getPackageOf should handle modules
  (P4) JDK-8224628: Note that type parameters are not visited by ElementScanners

core-libs/javax.naming:
  (P3) JDK-8220252: fix headings in java.naming
  (P3) JDK-8225129: Fix minor HTML issues in java.naming
  (P3) JDK-8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize
  (P3) JDK-8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"

core-libs/javax.sql:
  (P3) JDK-8220253: fix headings in java.sql.rowset

core-libs/jdk.nashorn:
  (P3) JDK-8227391: Update double-conversion to version 3.1.5
  (P4) JDK-8222528: Fix javadoc headers in Nashorn sources

core-svc:
  (P2) JDK-8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied
  (P3) JDK-8215411: some GetByteArrayElements calls miss corresponding Release
  (P4) JDK-8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp

core-svc/debugger:
  (P1) JDK-8224028: loop initial declarations introduced by JDK-8184770
  (P2) JDK-8226608: Hide the onjcmd option from the help output
  (P2) JDK-8218754: JDK-8068225 regression in JDIBreakpointTest
  (P3) JDK-8226596: Accessibility errors in jdwp-protocol.html
  (P3) JDK-8224673: Adjust permission for delayed starting of debugging
  (P3) JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from ''
  (P3) JDK-8225493: broken links in specs/jpda/architecture.html and specs/jpda/jpda.html
  (P3) JDK-8222821: com/sun/jdi/ExceptionEvents.java failed
  (P3) JDK-8218166: com/sun/jdi/SimulResumerTest.java failure
  (P3) JDK-8163127: Debugger classExclusionFilter does not work correctly with method references
  (P3) JDK-8215550: Debugger does not work after reattach
  (P3) JDK-8226593: Fix HTML in com/sun/jdi/doc-files/signature.html
  (P3) JDK-8225309: HTML issues in jdk.jdi module
  (P3) JDK-8215571: jdb does not include jdk.* in the default class filter
  (P3) JDK-8146986: JDI: Signature lookups for unprepared classes can take a long time
  (P3) JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry
  (P3) JDK-8184770: JDWP support for IPv6
  (P3) JDK-8221707: JDWP support for IPv6 - spec update
  (P3) JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
  (P3) JDK-8225682: Reference to JNI spec on java.sun.com
  (P3) JDK-8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed
  (P3) JDK-8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null
  (P3) JDK-8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3  :: 2"
  (P3) JDK-8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint"
  (P3) JDK-8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed
  (P4) JDK-6504660: HPI panic callback is dead code
  (P4) JDK-8219143: jdb should support breakpoint thread filters
  (P4) JDK-8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream"
  (P4) JDK-8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive"
  (P4) JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException
  (P4) JDK-8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event"
  (P4) JDK-8214854: JDWP: Unforseen output truncation in logging
  (P4) JDK-8219388: Misleading log message "issuspended002a debuggee launched"
  (P4) JDK-8219002: Some comments and error messages refer to VMDisconnectException
  (P4) JDK-8222529: sun.jdwp.listenerAddress agent property uses wrong encoding
  (P4) JDK-8201252: unquarantine nsk/jdi/ThreadReference/resume/resume001
  (P5) JDK-8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option
  (P5) JDK-8218947: jdb threads command should print threadID in decimal, not hex

core-svc/java.lang.instrument:
  (P3) JDK-8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module
  (P3) JDK-8220257: fix headings in java.instrument
  (P3) JDK-8225207: redundant <p> in Instrumentation.java
  (P4) JDK-8220355: Improve assertion texts and exception messages in eventHandlerVMInit
  (P4) JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java 

core-svc/java.lang.management:
  (P3) JDK-8220251: fix headings in java.management
  (P4) JDK-8209455: [error-prone] JdkObsolete in jdk.management.agent
  (P4) JDK-8215966: GeneratePropertyPassword.sh uses bash syntax

core-svc/javax.management:
  (P3) JDK-8225679: reference to http://java.sun.com/products/JavaManagement/download.html
  (P4) JDK-8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use

core-svc/tools:
  (P3) JDK-8225324: Bad HTML in jdk.jfr module-info.java
  (P3) JDK-8225543: Jcmd fails to attach to the Java process on Linux using the main class name if whitespace options were used to launch the process 
  (P3) JDK-8221730: jcmd process name matching broken
  (P3) JDK-8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout
  (P3) JDK-8220295: sun/tools/jps/TestJps.java still timing out 
  (P4) JDK-8215622: Add dump to file support for jmap –histo
  (P4) JDK-8203026: java.rmi.NoSuchObjectException: no such object in table
  (P4) JDK-8222491: jcmd can fail converting UTF8 output to strings
  (P4) JDK-8221164: jstatLineCounts tests need to be more resilent for NaN outputs
  (P4) JDK-8221694: jstatLineCounts1 needs to be NaN resilient
  (P4) JDK-8222533: jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java  fails on SLES12.3 linux ppc64le machine

docs:
  (P3) JDK-8221204: Link "Java SE Documentation" on the Complete Dialog redirected to 404 error page 
  (P4) JDK-8222301: Incorporate JDK 12 comments in JDK 13 java man page

docs/guides:
  (P4) JDK-8230786: "Serialization Filtering" guide typos
  (P4) JDK-8229042: Add ECDSA algorithms to the SunMSCAPI provider doc
  (P4) JDK-8134981: Document JDK supported permissions in security permissions guide 
  (P4) JDK-8223649: Document the com.sun.security.crl.readtimeout system property
  (P4) JDK-8017092: Update the PKCS#11 Reference Guide to document all the supported configuration flags.

globalization:
  (P4) JDK-8222969: Migrate RuleBasedCollatorTest to JDK Repo

globalization/locale-data:
  (P3) JDK-8206879: Currency decimal marker incorrect for Peru

globalization/translation:
  (P3) JDK-8228778: JDK 13 L10n resource files update - msg drop 20
  (P3) JDK-8227009: JDK 13 L10n resource files update - msgdrop 10
  (P3) JDK-8228397: Missing license copyright header in some properties files
  (P4) JDK-8228623: Update copyright year to 2019 for several java properties file

hotspot:
  (P2) JDK-8226515: AArch64: float point register corruption in ZBarrierSetAssembler::load_at
  (P2) JDK-8219583: Windows build failure after JDK-8214777 (Avoid some GCC 8.X strncpy() errors in HotSpot)
  (P4) JDK-8221479: [s390] Fix JFR profiling
  (P4) JDK-8219814: Help-info for pns(...) on Linux/mips lost

hotspot/compiler:
  (P1) JDK-8224652: 32-bit build failures after JDK-8213084 (Rework and enhance Print[Opto]Assembly output)
  (P1) JDK-8223645: AArch64 build broken by fix for 8223136
  (P1) JDK-8225202: Add missing include after JDK-8223320
  (P1) JDK-8219951: Build failure on Mac and Windows after JDK-8219922
  (P1) JDK-8229219: C2 compilation fails with assert: Bad graph detected in build_loop_late
  (P1) JDK-8216595: Fix broken builds after JDK-8216424
  (P1) JDK-8224742: JLONG_FORMAT_W incompatible with type jlong
  (P1) JDK-8217782: Spill detection broken after JDK-8217716
  (P2) JDK-8218601: [AOT] Crash in AOTCodeHeap::mark_evol_dependent_methods
  (P2) JDK-8223262: [AOT] jaotc crashes with assert(!(((ThreadShadow*)__the_thread__)->has_pending_exception())) failed: Should not allocate with exception pending
  (P2) JDK-8218169: [AOT] Segmentation fault when running java with AOTed Graal in -Xcomp mode on windows
  (P2) JDK-8217466: [BACKOUT] Optimize CodeHeap Analytics
  (P2) JDK-8223531: [Graal] assert(type() == T_INT) failed: type check
  (P2) JDK-8221514: [Graal] java/lang/String/CompactString/ tests fail with "GraalError: failed guarantee: no FrameState at DeoptimizingNode" in Graal -Xcomp mode
  (P2) JDK-8215687: [Graal] unit test CheckGraalIntrinsics failed after 8212043
  (P2) JDK-8221083: [ppc64] Wrong oop compare in C1-generated code
  (P2) JDK-8224671: AArch64: mauve System.arraycopy test failure
  (P2) JDK-8215792: AArch64: String.indexOf generates incorrect result
  (P2) JDK-8224648: assert(!exceeding_node_budget()) failed: Too many NODES required! failure with ctw
  (P2) JDK-8223363: Bad node estimate assertion failure
  (P2) JDK-8218721: C1's CEE optimization produces safepoint poll with invalid debug information
  (P2) JDK-8218406: C1: Redundant nmethod dependency for private method is added
  (P2) JDK-8221592: C2 compilation failed with assert(!q->is_MergeMem())
  (P2) JDK-8224539: C2 compilation fails during ArrayCopyNode optimizations with assert(i < _max) failed: oob: i=1, _max=1
  (P2) JDK-8217990: C2 UseOptoBiasInlining: load of markword optimized to 0 if running with -XX:-EliminateLocks
  (P2) JDK-8087128: C2: Disallow definition split on MachCopySpill nodes
  (P2) JDK-8219902: C2: MemNode::can_see_stored_value() ignores casts which carry control dependency
  (P2) JDK-8217760: C2: Missing symbolic info on a call from intrinsics when invoked through MethodHandle
  (P2) JDK-8202952: C2: Unexpected dead nodes after matching
  (P2) JDK-8220341: Class redefinition fails with assert(!is_unloaded()) failed: unloaded method on the stack
  (P2) JDK-8224234: compiler/codegen/TestCharVect2.java fails in test_mulc
  (P2) JDK-8223539: compiler/graalunit/HotspotTest.java hotspot.test.CheckGraalIntrinsics AssertionError: found plugins for intrinsics characterized as toBeInvestigated
  (P2) JDK-8228710: Disable AggressiveUnboxing until JDK-8224957 is fixed
  (P2) JDK-8223911: Disable bad node budget verification until the fix
  (P2) JDK-8224931: disable JAOTC invokedynamic support until 8223533 is fixed
  (P2) JDK-8224558: Fix replicateB encoding
  (P2) JDK-8219687: G1 asserts nmethod should not be unloaded during parallel code cache unloading
  (P2) JDK-8227034: Graal crash with gcbasher
  (P2) JDK-8211100: hotspot C1 issue with comparing long numbers on x86 32-bit
  (P2) JDK-8227260: JNI upcalls should bypass class initialization barrier in c2i adapter
  (P2) JDK-8224568: minimal and zero build fails after JDK-8213084
  (P2) JDK-8219486: Missing reg_mask_init() breaks x86_32 build
  (P2) JDK-8225475: Node budget asserts on x86_32/64
  (P2) JDK-8228618: s390: c1/c2 fail to add a metadata relocation in the static call stub.
  (P2) JDK-8223389: Shenandoah optimizations fail with assert(!phase->exceeding_node_budget())
  (P2) JDK-8217874: Shenandoah: AArch64: Clobbered register in ShenandoahBarrierSetAssembler::cmpxchg_oop()
  (P2) JDK-8219448: split-if update_uses accesses stale idom data
  (P2) JDK-8223537: testlibrary_tests/ctw/ClassesListTest.java fails with Agent timeout frequently 
  (P2) JDK-8227222: vmTestbase/jit/FloatingPoint/gen_math/Loops04/Loops04.java hits assert(((!attributes->uses_vl()) || (attributes->get_vector_len() == AVX_512bit) || (!_legacy_mode_vl) || (attributes->is_legacy_mode()))) failed: XMM register should be 0-15
  (P2) JDK-8221343: x86_32 crashes on startup with "_hwm out of range"
  (P2) JDK-8218031: Zero broken after JDK-8217922 (Compiler dead code removal)
  (P2) JDK-8227407: ZGC: C2 loads and load barriers can get separated by safepoints
  (P3) JDK-8219335: "failed: unexpected type" assert failure in ConnectionGraph::split_unique_types() with unsafe accesses
  (P3) JDK-8224672: (lib)hsdis-<arch>.so search incorrect after JDK-8213084
  (P3) JDK-8225064: [Graal] Application SEGV in G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markOopDesc*)+0x48
  (P3) JDK-8223422: [Graal] assert(!m->can_be_statically_bound(InstanceKlass::cast(ctxk))) failed: redundant
  (P3) JDK-8221577: [Graal] Implement basic type consistency checks for Low level MH intrinsics
  (P3) JDK-8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services
  (P3) JDK-8226778: [JVMCI] Handle unpacking properly in Deoptimiziation::get_cached_box()
  (P3) JDK-8226566: [JVMCI] java.* classes are no longer necessarily resolved by the boot class loader
  (P3) JDK-8220623: [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library
  (P3) JDK-8217465: [REDO] - Optimize CodeHeap Analytics
  (P3) JDK-8216350:  AArch64: monitor unlock fast path not called
  (P3) JDK-8218966: AArch64: String.compareTo() can read memory after string
  (P3) JDK-8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?"
  (P3) JDK-8222825: ARM32 SIGILL issue on single core CPU (not supported PLDW instruction)
  (P3) JDK-8219520: assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit
  (P3) JDK-8219517: assert(false) failed: infinite loop in PhaseIterGVN::optimize
  (P3) JDK-8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached
  (P3) JDK-8226627: assert(t->singleton()) failed: must be a constant
  (P3) JDK-8225141: Better handling of classes in error state by fast class initialization checks
  (P3) JDK-8220714: C2 Compilation failure when accessing off-heap memory using Unsafe
  (P3) JDK-8219807: C2 crash in IfNode::up_one_dom(Node*, bool)
  (P3) JDK-8217918: C2: -XX:+AggressiveUnboxing is broken
  (P3) JDK-8161334: C2: Cast nodes hinder memory alias analysis
  (P3) JDK-8218163: C2: Continuous deoptimization w/ Reason_speculate_class_check and Action_none 
  (P3) JDK-8217919: C2: Enable -XX:+AggressiveUnboxing by default
  (P3) JDK-8192001: C2: inlining through dispatching MH linkers ignores speculative type of the receiver
  (P3) JDK-8191998: C2: inlining through MH linkers drops speculative part of argument types 
  (P3) JDK-8220374: C2: LoopStripMining doesn't strip as expected
  (P3) JDK-8188133: C2: Static field accesses in clinit can trigger deoptimizations 
  (P3) JDK-8223216: C2: Unify class initialization checks between new, getstatic, and putstatic
  (P3) JDK-6986483: CHA: optimize calls through interfaces
  (P3) JDK-8225106: Class initialization checks assert when holder klass is in error state
  (P3) JDK-8225509: clean_catch_blocks must add preds first
  (P3) JDK-8223617: code_size2 needs adjustments
  (P3) JDK-8223770: code_size2 still too small in some compressed oops configurations
  (P3) JDK-8224254: compiler/graalunit/HotspotJdk9Test.java is timing out intermittently
  (P3) JDK-8218201: Failures when vmIntrinsics::_getClass is not inlined
  (P3) JDK-8216580: Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic
  (P3) JDK-8223885: hs_err and replay file may contain garbage when overwriting existing file
  (P3) JDK-8217564: idempotent protection missing in crc32c.h
  (P3) JDK-8224826: Implement fast class initialization checks on PPC64
  (P3) JDK-8224827: Implement fast class initialization checks on s390
  (P3) JDK-8223213: Implement fast class initialization checks on x86-64
  (P3) JDK-8217371: Incorrect LP64 guard in x86.ad after JDK-8210764 (Update avx512 implementation)
  (P3) JDK-8218700: infinite loop in HotSpotJVMCIMetaAccessContext.fromClass after OutOfMemoryError
  (P3) JDK-8228340: JVMCI deleteGlobalHandle doesn't delete the handle
  (P3) JDK-8226533: JVMCI: findUniqueConcreteMethod should handle statically bindable methods directly
  (P3) JDK-8223050: JVMCI: findUniqueConcreteMethod() should not use Dependencies::find_unique_concrete_method() for non-virtual methods
  (P3) JDK-8223796: JVMCIEnv::get_jvmci_type does not keep klasses alive
  (P3) JDK-8219403: JVMCIRuntime::adjust_comp_level should be replaced
  (P3) JDK-8218468: Load barrier slow path node should be MachTypeNode
  (P3) JDK-8224538: LoadBarrierNode::common_barrier must check address
  (P3) JDK-8220198: Lots of com/sun/crypto/provider/Cipher tests fail on x86_32 due to missing SHA512 stubs
  (P3) JDK-8226287: Make process_users_of_allocation handle gc barriers
  (P3) JDK-8224580: Matcher can cause oop field/array element to be reloaded
  (P3) JDK-8217639: Minimal and Zero builds fail after JDK-8217519 (Improve RegMask population count calculation)
  (P3) JDK-8224674: NMethod state machine is not monotonic
  (P3) JDK-8218776: no man page for jaotc
  (P3) JDK-8223502: Node estimate for loop unswitching is not correct: assert(delta <= 2 * required) failed: Bad node estimate
  (P3) JDK-8215483: Off heap memory accesses should be vectorized
  (P3) JDK-8217250: Optimize CodeHeap Analytics
  (P3) JDK-8222670: pathological case of JIT recompilation and code cache bloat
  (P3) JDK-8219582: PPC: Crash after C1 checkcast patched and GC
  (P3) JDK-8209951: Problematic sparc intrinsic: com.sun.crypto.provider.CipherBlockChaining
  (P3) JDK-8223171: Redundant nmethod dependencies for effectively final methods
  (P3) JDK-8076988: reevaluate trivial method policy
  (P3) JDK-8225564: Remove wrong assert in clean_catch_blocks
  (P3) JDK-8213416: Replace some enums with static const members in hotspot/compiler
  (P3) JDK-8220515: Revert removal of for_each_lock_value
  (P3) JDK-8224496: Shenandoah compilation fails with assert(is_CountedLoopEnd()) failed: invalid node class
  (P3) JDK-8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks
  (P3) JDK-8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL
  (P3) JDK-8202414: Unsafe write after primitive array creation may result in array length change
  (P3) JDK-8222665: Update Graal
  (P3) JDK-8226198: use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state
  (P3) JDK-8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine
  (P4) JDK-8225199: [Graal] compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java fails with -XX:CompileThresholdScaling=0.1
  (P4) JDK-8220627: [Graal] Enable java/util/Base64$Encoder.encodeBlock([BII[BIZ)V stub
  (P4) JDK-8217758: [Graal] Graal should retain local variables if jvmti can_pop_frame/can_access_local_variables capability is set
  (P4) JDK-8217848: [Graal] vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java fails
  (P4) JDK-8217445: [JVMCI] incorrect management of JVMCI compilation failure reason string
  (P4) JDK-8223639: [JVMCI] jvmciCompiler.cpp needs to include "oops/objArrayOop.inline.hpp""
  (P4) JDK-8209626: [JVMCI] Use implicit exception table for dispatch and printing
  (P4) JDK-8217459: [PPC64] Cleanup non-vector version of CRC32
  (P4) JDK-8224090: [PPC64] Fix SLP patterns for filling an array with double float literals
  (P4) JDK-8216060: [PPC64] Vector CRC implementation should be used by interpreter and be faster for short arrays
  (P4) JDK-8173196: [REDO] C2 does not optimize redundant memory operations with G1
  (P4) JDK-8222271: [s390] optimize register usage in C2 instruction forms for clearing arrays
  (P4) JDK-8212043: AArch64: Add floating-point Math.min/max intrinsics
  (P4) JDK-8222785: aarch64: add necessary masking for immediate shift counts
  (P4) JDK-8221658: aarch64: add necessary predicate for ubfx patterns
  (P4) JDK-8214922: AArch64: Add vectorization support for fmin/fmax
  (P4) JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered
  (P4) JDK-8219993: AArch64: Compiled CI stubs are unsafely modified
  (P4) JDK-8223020: aarch64: expand minI_rReg and maxI_rReg patterns into separate instructions
  (P4) JDK-8224880: AArch64: java/javac error with AllocatePrefetchDistance
  (P4) JDK-8222412: AARCH64: multiple instructions encoding issues
  (P4) JDK-8221995: AARCH64: problems with CAS instructions encoding
  (P4) JDK-8219006: AArch64: Register corruption in slow subtype check
  (P4) JDK-8216259: AArch64: Vectorize Adler32 intrinsics
  (P4) JDK-8217869: Add count_leading_zeros utility
  (P4) JDK-8218550: Add test omitted from JDK-8212043
  (P4) JDK-8220656: ARM32: -XX:MaxVectorSize=16 makes SIGILL
  (P4) JDK-8075052: Autobox elimination hinders loop unrolling
  (P4) JDK-8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI
  (P4) JDK-8059241: C2: Excessive RemoveUseless passes during incremental inlining
  (P4) JDK-8157372: C2: Node::cmp() should return bool
  (P4) JDK-8218881: C2: StaticFinalFieldPrinter doesn't handle T_ARRAY values in T_OBJECT fields
  (P4) JDK-8218874: C2: Unsafe to access PhaseIdealLoop outside of constructors 
  (P4) JDK-8216154: C4819 warnings at HotSpot sources on Windows
  (P4) JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64
  (P4) JDK-8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy
  (P4) JDK-8219642: ciReplay loads wrong data when MethodData size changes
  (P4) JDK-8221541: clean up functions in CompilerOracle
  (P4) JDK-8220420: Cleanup c1_LinearScan
  (P4) JDK-8217922: Compiler dead code removal
  (P4) JDK-8226646: CTW of SPECjvm2008 hangs on windows-x64-debug
  (P4) JDK-8216360: Deprecate -XX:CompilationPolicyChoice
  (P4) JDK-8217447: Develop flag TraceICs is broken
  (P4) JDK-8223450: Disable Shenandoah C2 barriers verification for x86_32
  (P4) JDK-8222074: Enhance auto vectorization for x86
  (P4) JDK-8227112: exclude compiler/intrinsics/sha/sanity tests from AOT runs
  (P4) JDK-8217291: Failure of ::realloc() should be handled correctly in adlc/forms.cpp
  (P4) JDK-8218544: Fix build on windows: missing include
  (P4) JDK-8225110: IGV build definition uses non-secure transport
  (P4) JDK-8219011: Implement MacroAssembler::warn method on AArch64
  (P4) JDK-8220501: Improve c1_ValueStack locks handling
  (P4) JDK-8223444: Improve CodeHeap Free Space Management
  (P4) JDK-8223504: improve performance of forall loops by better inlining of "iterator()" methods.
  (P4) JDK-8217519: Improve RegMask population count calculation
  (P4) JDK-8220502: Inefficient pre-sizing of PhiResolverState arrays in c1_LIRGenerator
  (P4) JDK-8221482: Initialize VMRegImpl::regName[] earlier to prevent assert during PrintStubCode
  (P4) JDK-8218879: Keep track of memory accesses originated from Unsafe
  (P4) JDK-8224675: Late GC barrier insertion for ZGC
  (P4) JDK-8216199: Local variable arg defined but never used in BCEscapeAnalyzer::compute_escape_for_intrinsic()
  (P4) JDK-8219664: LogCompilation:  java.lang.Error: Unexpected method mismatch during late inlining
  (P4) JDK-8196347: LogCompilation: generate log file on the fly for input to junits
  (P4) JDK-8218937: Make mlvmJvmtiUtils strncpy uses GCC 8.x friendly
  (P4) JDK-8217909: Make unused r12 register (without compressed oops) available to regalloc in C2
  (P4) JDK-8215551: Missing case label in nmethod::reloc_string_for()
  (P4) JDK-8223621: Move Universe usage out of oopRecorder.hpp
  (P4) JDK-8221456: nmethod::make_unloaded() clears _method member too early
  (P4) JDK-8216608: Obsolete stale compiler flags
  (P4) JDK-8217383: Obsolete UseImplicitStableValues
  (P4) JDK-8220159: Optimize various RegMask operations by introducing watermarks
  (P4) JDK-8217629: RegMask::find_lowest_bit can reuse count_trailing_zeros utility
  (P4) JDK-8225429: Regression in disassembly quality
  (P4) JDK-8217716: Remove dead code in PhaseChaitin
  (P4) JDK-8218625: Remove dead code in relocInfo
  (P4) JDK-8217387: Remove dead develop flag CIFireOOMAt
  (P4) JDK-8217266: Remove dead LIR_List::compare_to and LIR_Code::lir_compare_to
  (P4) JDK-8216262: Remove develop flag DelayCompilationDuringStartup
  (P4) JDK-8217388: Remove develop flag ProfilerPCTickThreshold
  (P4) JDK-8216359: Remove develop flags TraceCompilationPolicy and TimeCompilationPolicy
  (P4) JDK-8216423: Remove FillDelaySlots
  (P4) JDK-8220411: Remove ScavengeRootsInCode=0 code
  (P4) JDK-8216424: Remove TimeLivenessAnalysis
  (P4) JDK-8216375: Revert JDK-8145579 after JDK-8076988 is resolved
  (P4) JDK-8213084: Rework and enhance Print[Opto]Assembly output
  (P4) JDK-8219919: RuntimeStub's name lost with PrintFrameConverterAssembly
  (P4) JDK-8218991: s390: Add intrinsic for GHASH algorithm
  (P4) JDK-8219922: Simplify IndexSetIterator::next using count_trailing_zeros
  (P4) JDK-8220211: Small update to Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic (JDK-8216580)
  (P4) JDK-8217407: StackValue::print_on() crashes on NULL handle
  (P4) JDK-8216556: Unnecessary liveness computation with JVMTI
  (P4) JDK-8226905: unproblem list applications/ctw/modules/* tests on windows
  (P4) JDK-8223332: Update JVMCI
  (P4) JDK-8225450: use @file in CtwRunner
  (P4) JDK-8222371: Use UL for TraceNMethodInstalls code
  (P4) JDK-8225567: Wrong file headers with 8202414 fix changeset
  (P4) JDK-8217561: x86: Add floating-point Math.min/max intrinsics
  (P4) JDK-8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled registers
  (P4) JDK-8216372: ZGC: Put C2 load barrier stub routines in separate codeblobs
  (P4) JDK-8221542: ~15% performance degradation due to less optimized inline decision
  (P5) JDK-8216200: BCEscapeAnalyzer::ArgumentMap::set_intersect() is incorrect
  (P5) JDK-8223141: Change (count) suffix _ct into _cnt. 
  (P5) JDK-8223140: Clean-up in 'ok_to_convert()'
  (P5) JDK-8223142: Clean-up WS and CB. 
  (P5) JDK-8221853: Data race in compile broker (set_last_compile)
  (P5) JDK-8219214: Infinite Loop in CodeSection::dump()
  (P5) JDK-8219519: Remove linux_sparc.ad and linux_aarch64.ad
  (P5) JDK-8223139: Rename mandatory policy-do routines. 
  (P5) JDK-8223137: Rename predicate 'do_unroll_only()' to 'is_unroll_only()'.
  (P5) JDK-8223143: Restructure/clean-up for 'loopexit_or_null()'.
  (P5) JDK-8223138: Small clean-up in loop-tree support.

hotspot/gc:
  (P1) JDK-8225104: 32-bit build failures after JDK-8222252
  (P1) JDK-8221363: Build failure after JDK-8220240 (Refactor shared dirty card queue)
  (P1) JDK-8223583: Build failure after JDK-8223567 (Rename ShenandoahBrooksPointer to ShenandoahForwarding)
  (P1) JDK-8223637: Fix build breakage after 8223136
  (P1) JDK-8218680: G1 crashes during calculation of old collection set candidates
  (P1) JDK-8218060: JDK-8217786 breaks build due to remaining unused function
  (P1) JDK-8218063: JDK-8218060 breaks build for S390
  (P1) JDK-8217522: Missing barriers in some java_lang_String assertion code after JDK-8217442
  (P1) JDK-8217419: Shenandoah fails to build after JDK-8212826 (Make PtrQueue free list lock-free)
  (P1) JDK-8223767: Shenandoah fails to build on Solaris x86_64
  (P1) JDK-8223570: Shenandoah needs to acquire lock before CLDG::clear_claimed_marks
  (P1) JDK-8224875: Shenandoah: ParallelCleaning code unloading should take lock to protect shared code roots array
  (P1) JDK-8217423: Windows gtest build fails after JDK-8212826 (Make PtrQueue free list lock-free)
  (P2) JDK-8224247: AllocateOldGenAt fires assertion failure
  (P2) JDK-8221102: Allow GC threads to participate in threads claiming protocol
  (P2) JDK-8223675: arm32 build failure after 8223136 (Move compressed oops functions to CompressedOops class)
  (P2) JDK-8224836: Backout: JDK-8224626: Shenandoah: Elide barriers on uncommon traps
  (P2) JDK-8218975: Bug in macOSX kernel's pthread support
  (P2) JDK-8223651: Build fails with --with-jvm-features=-jfr and --disable-precompiled-headers
  (P2) JDK-8219557: Change task definitions to not include RunThese for ZGC
  (P2) JDK-8222333: fastdebug build broken after JDK-8221393 (phase_mapping[] doesn't match enum Phase in WeakProcessorPhases)
  (P2) JDK-8224573: Fix windows build after JDK-8221507
  (P2) JDK-8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding
  (P2) JDK-8222492: G1 unnecessarily scans remembered set cards for regions that already have been evacuated
  (P2) JDK-8225418: G1: region attribute remembered set state disagrees with actual remembered set state
  (P2) JDK-8222841: Incorrect static call stub interactions with class unloading
  (P2) JDK-8220671: Initialization race for non-JavaThread PtrQueues
  (P2) JDK-8223676: Minimal VM build failure after 8223136 (Move compressed oops functions to CompressedOops class)
  (P2) JDK-8217794: Missing termination check results violation of termination invariant
  (P2) JDK-8222664: runtime/appcds/sharedStrings/SharedStringsStress.java assert GC active during NoGCVerifier
  (P2) JDK-8224531: SEGV while collecting Klass statistics
  (P2) JDK-8222926: Shenandoah build fails with --with-jvm-features=-compiler1
  (P2) JDK-8224522: Shenandoah should apply barriers on deoptimization
  (P2) JDK-8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr
  (P2) JDK-8224881: Shenandoah: trashing "Collection Set, Pinned" region during Degenerated GC
  (P2) JDK-8227083: ZGC: C2: Generates on_weak barrier for WeakCompareAndSwap
  (P2) JDK-8225770: ZGC: C2: Generates on_weak instead of on_strong barriers
  (P2) JDK-8225642: ZGC: Crash due to bad oops being spilled to stack in load barriers
  (P2) JDK-8227175: ZGC: ZHeapIterator visits potentially dead objects
  (P3) JDK-8188066: (ref) Examine the reachability of JNI WeakGlobalRef and interaction with phantom refs
  (P3) JDK-8214527: AArch64: ZGC for Aarch64
  (P3) JDK-8217399: Backout 8217358
  (P3) JDK-8221763: Build fails when using --with-jvm-features=-g1gc,-jfr,-shenandoahgc
  (P3) JDK-8220344: Build failures when using --with-jvm-features=-g1gc,-jfr
  (P3) JDK-8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior
  (P3) JDK-8226366: Excessive ServiceThread wakeups for OopStorage cleanup
  (P3) JDK-8218880: G1 crashes when issuing a periodic GC while the GCLocker is held
  (P3) JDK-8214363: HeapWord should not be a fake class
  (P3) JDK-8222480: Implementation: JEP 351: ZGC: Uncommit Unused Memory
  (P3) JDK-8222252: Java ergonomics limits heap to 128GB with disabled compressed oops
  (P3) JDK-8220347: JEP 351: ZGC: Uncommit Unused Memory (Experimental)
  (P3) JDK-8212630: jtreg/gc/logging/TestMetaSpaceLog.java failed with Agent timed out
  (P3) JDK-8225014: Separate ShenandoahRootScanner method for object_iterate
  (P3) JDK-8223446: Shenandoah breaks alignment with some HumongousThreshold values
  (P3) JDK-8223448: Shenandoah disabled barriers blocks omit LRB
  (P3) JDK-8220161: Shenandoah does not need to initialize PLABs for safepoint workers 
  (P3) JDK-8220153: Shenandoah does not work with TransparentHugePages properly
  (P3) JDK-8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers
  (P3) JDK-8219524: Shenandoah misreports "committed" size in MemoryMXBean
  (P3) JDK-8220162: Shenandoah should not commit HugeTLBFS memory
  (P3) JDK-8221435: Shenandoah should not mark through weak roots
  (P3) JDK-8222186: Shenandoah should not uncommit below minimum heap size
  (P3) JDK-8225048: Shenandoah x86_32 support
  (P3) JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1
  (P3) JDK-8224179: Shenandoah: CTW test failures with traversal GC
  (P3) JDK-8224584: Shenandoah: Eliminate forwarding pointer word
  (P3) JDK-8223980: Shenandoah: Refactor and fix ObjArrayChunkedTask verification
  (P3) JDK-8225229: Shenandoah: trim down default number of GC threads
  (P3) JDK-8160539: Stack frame scanning acquires DerivedPointerTableGC_lock mutex
  (P3) JDK-8217778: StringTable cleanup miscalculates amount of dead objects
  (P3) JDK-8226302: Test failures on IBM platforms (power and s/390) after JDK-8223837
  (P4) JDK-8222105: Add "use_" prefix to G1Policy::adaptive_young_list_length
  (P4) JDK-8222145: Add -XX:SoftMaxHeapSize flag
  (P4) JDK-8219748: Add and use getter for the timing object in G1
  (P4) JDK-8223822: Add gc IDs in the log of gc verification
  (P4) JDK-8221913: Add GC.selected() jtreg-ext function 
  (P4) JDK-8219816: Add IsArray/RemoveExtent type traits utilities
  (P4) JDK-8223392: Add missing BitMap comments for JDK-8222986
  (P4) JDK-8219369: Add named constants for iterating ExtRootScan phases
  (P4) JDK-8219573: Add NMethodClosure
  (P4) JDK-8214799: Add package declaration to each JTREG test case in the gc folder 
  (P4) JDK-8222986: Add parameter to skip clearing CHeapBitMaps when resizing
  (P4) JDK-8218672: AOT code root scanning shows in the wrong position in the logs
  (P4) JDK-8217342: Build failed with excluding JFR
  (P4) JDK-8217576: C1 atomic access handlers use incorrect decorators
  (P4) JDK-8221394: Clean up ConcurrentGCThread
  (P4) JDK-8218668: Clean up evacuation of optional collection set
  (P4) JDK-8223624: Cleanup includes of universe.hpp
  (P4) JDK-8217319: Cleanup Shenandoah includes
  (P4) JDK-8225441: Cleanup ShenandoahHeap::atomic_compare_exchange_oop
  (P4) JDK-8220609: Cleanups in ScavengableNMethods
  (P4) JDK-8217417: Decorator name typo: C2_TIGHLY_COUPLED_ALLOC
  (P4) JDK-8221359: Eliminate filter_thread_buffers
  (P4) JDK-8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate
  (P4) JDK-8217014: Epsilon should not ignore Metadata GC causes
  (P4) JDK-8223267: Fix incorrect usage of GCTraceTime in g1FullCollector and g1CollectedHeap
  (P4) JDK-8215114: Fix indent and dead code in GCPolicyCounters
  (P4) JDK-8224038: Fix remaining InCSetState mentions
  (P4) JDK-8223244: Fix usage of ARRAYCOPY_DISJOINT decorator
  (P4) JDK-8218974: Free GC native structures in nmethod::flush
  (P4) JDK-8214946: G1: Initialize all class members on construction
  (P4) JDK-8221517: G1: Reserved page size for heap can be wrong
  (P4) JDK-8219976: GarbageCollectionNotificationInfo always says "No GC" when running Shenandoah
  (P4) JDK-8223397: gc+promotion log lines are missing the GC id
  (P4) JDK-8220290: gc_epilogue(full = false) is called on Full GC path after JDK-8215221
  (P4) JDK-8221507: Implement JFR events for Shenandoah
  (P4) JDK-8219100: Improve do_collection_pause_at_safepoint
  (P4) JDK-8223162: Improve ergonomics for Sparse PRT entry sizing
  (P4) JDK-8200545: Improve filter for enqueued deferred cards
  (P4) JDK-8220228: Improve Shenandoah pacing histogram message
  (P4) JDK-8220388: Increase -inlinehint-threshold for Clang to avoid G1 pause time regression
  (P4) JDK-8221260: Initialize more class members on construction, remove some unused ones
  (P4) JDK-8221732: Introduce CollectedHeap::hash_oop()
  (P4) JDK-8222462: Introduce CollectedHeap::unused()
  (P4) JDK-8213229: Investigate treating StringTable as weak in young collections
  (P4) JDK-8217385: JTREG: Clean up, make sure to close resources
  (P4) JDK-8217329: JTREG: Clean up, remove unused imports in gc folder
  (P4) JDK-8217389: JTREG: Clean up, remove unused variable warnings
  (P4) JDK-8217332: JTREG: Clean up, use generics instead of raw types
  (P4) JDK-8221766: Load-reference barriers for Shenandoah
  (P4) JDK-8220610: Make CollectedHeap nmethod functions pure virtual
  (P4) JDK-8216258: Make FreeIdSet semaphore-based
  (P4) JDK-8225478: Make G1CMRootRegions independent of HeapRegions
  (P4) JDK-8219098: Make output of region strings more regular in error messages
  (P4) JDK-8212826: Make PtrQueue free list lock-free
  (P4) JDK-8214201: Make PtrQueueSet completed buffer list private
  (P4) JDK-8219096: Merge print_termination_stats code with current logging
  (P4) JDK-8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize
  (P4) JDK-8223136: Move compressed oops functions to CompressedOops class
  (P4) JDK-8224160: Move G1RemSetScanClosure into g1RemSet.cpp file
  (P4) JDK-8223620: Move IsGCActiveMark implementation out of header
  (P4) JDK-8223623: Move oopFactory function definitions out of oopFactory.hpp
  (P4) JDK-8220606: Move ScavengableNMethods unlinking to unregister_nmethod
  (P4) JDK-8220343: Move scavenge_root_nmethods from shared code
  (P4) JDK-8223622: Move Universe usage out of memAllocator.hpp
  (P4) JDK-8223619: Move VerifyOption out of Universe
  (P4) JDK-8213827: NUMA heap allocation does not respect process membind/interleave settings
  (P4) JDK-8217358: Optimized build is broken by Shenandoah changes
  (P4) JDK-8217785: Padding ParallelTaskTerminator::_offered_termination variable
  (P4) JDK-8222843: Print Shenandoah cset map addresses in hs_err
  (P4) JDK-8221688: Quarantine Shenandoah string dedup tests
  (P4) JDK-8221392: Reduce ConcurrentGCThreads spinning during start up
  (P4) JDK-8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead
  (P4) JDK-8224187: Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy
  (P4) JDK-8221509: Refactor assert( G1CollectedHeap::used() == recalculate_used() ) with better message
  (P4) JDK-8224167: Refactor PtrQueue completed buffer processing
  (P4) JDK-8220240: Refactor shared dirty card queue
  (P4) JDK-8220350: Refactor ShenandoahHeap::initialize
  (P4) JDK-8221648: Remove CollectedHeap::is_in_closed_subset()
  (P4) JDK-8198505: Remove CollectorPolicy and its subclasses
  (P4) JDK-8218192: Remove copy constructor for MemRegion
  (P4) JDK-8219747: Remove g1_ prefix to g1_remset and g1_policy members in G1CollectedHeap
  (P4) JDK-8215299: Remove G1CMTask::should_exit_termination()'s undesirable side-effect
  (P4) JDK-8220301: Remove jbyte use in CardTable
  (P4) JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp
  (P4) JDK-8221558: Remove obsolete uses of OopStorage::ParState<false, false> _par_state
  (P4) JDK-8216072: Remove TaskTerminator's assignment operator
  (P4) JDK-8219817: Remove unused CollectedHeap::block_size()
  (P4) JDK-8221748: Remove unused oopDesc::is_unlocked_oop()
  (P4) JDK-8217474: Remove WhiteBox.getConcurrentGCPhases()
  (P4) JDK-8217328: Rename CollectionSetChooser to G1CollectionSetChooser
  (P4) JDK-8218089: Rename DirtyCardQueue et al to follow usual G1 naming conventions
  (P4) JDK-8223018: Rename G1RemSet::*oops_into_collection_set_do methods
  (P4) JDK-8215492: Rename INTERNAL_EMPTY to something less "internal"
  (P4) JDK-8223567: Rename ShenandoahBrooksPointer to ShenandoahForwarding
  (P4) JDK-8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers
  (P4) JDK-8225357: Rewire ShenandoahHeap::maybe_update_with_forwarded for contending fixups
  (P4) JDK-8218920: Scan HCC should be on the same level as Update RS etc. in the log
  (P4) JDK-8215221: Serial GC misreports young GC time
  (P4) JDK-8217578: Shenandoah cleanup unused timings after concurrent string table change
  (P4) JDK-8217343: Shenandoah control thread should be able to run at critical priority
  (P4) JDK-8215549: Shenandoah deduplication cleans up table/queue twice
  (P4) JDK-8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal
  (P4) JDK-8219857: Shenandoah GC may initialize thread's gclab twice
  (P4) JDK-8225046: Shenandoah metrics logs refactoring
  (P4) JDK-8220546: Shenandoah Reports timing details for weak root processing
  (P4) JDK-8223759: Shenandoah should allow arbitrarily low initial heap size
  (P4) JDK-8221278: Shenandoah should not enqueue string dedup candidates during root scan
  (P4) JDK-8222185: Shenandoah should report "committed" as capacity
  (P4) JDK-8220444: Shenandoah should use parallel version of WeakProcessor in root processor for weak roots
  (P4) JDK-8222130: Shenandoah should verify roots after pre-evacuation
  (P4) JDK-8222188: Shenandoah: Adjust Shenandoah work gang types
  (P4) JDK-8224978: Shenandoah: Allows root verifier to verify some roots outside safepoints with proper locks
  (P4) JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements
  (P4) JDK-8221629: Shenandoah: Cleanup class unloading logic
  (P4) JDK-8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers
  (P4) JDK-8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC
  (P4) JDK-8224626: Shenandoah: Elide barriers on uncommon traps
  (P4) JDK-8224115: Shenandoah: Eliminate RWLock that protects recorded nmethod data array
  (P4) JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects
  (P4) JDK-8221750: Shenandoah: Enable ThreadLocalHandshake by default
  (P4) JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause
  (P4) JDK-8221751: Shenandoah: Improve SATB enqueueing
  (P4) JDK-8216973: Shenandoah: Kick up cleanup phases in the right places
  (P4) JDK-8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable
  (P4) JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength()
  (P4) JDK-8223184: Shenandoah: Missing roots in SRP::process_all_roots_slow
  (P4) JDK-8222425: Shenandoah: Move commonly used closures to separate files
  (P4) JDK-8225572: Shenandoah: Move JNIHandles root out of serial roots
  (P4) JDK-8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle
  (P4) JDK-8223951: Shenandoah: Only need to update thread roots during final update refs
  (P4) JDK-8223762: Shenandoah: overflows in calculations involving heap capacity
  (P4) JDK-8224667: Shenandoah: Post-LRB cleanup
  (P4) JDK-8222992: Shenandoah: Pre-evacuate all roots
  (P4) JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC
  (P4) JDK-8223774: Shenandoah: Refactor ShenandoahRootProcessor and family
  (P4) JDK-8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots
  (P4) JDK-8224043: Shenandoah: Remove clear_claimed_marks() from start of concurrent_traversal()
  (P4) JDK-8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead
  (P4) JDK-8222490: Shenandoah: Remove unused _par_state_string in ShenandoahRootEvacuator
  (P4) JDK-8222419: Shenandoah: Remove unused _par_state_string in ShenandoahRootProcessor
  (P4) JDK-8224932: Shenandoah: Rename ShenandoahHeapLock, make it general purpose lock
  (P4) JDK-8203232: Shenandoah: Resolve oops in SATB filter
  (P4) JDK-8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle
  (P4) JDK-8225514: Shenandoah: ShenandoahCodeRoots should inherit from AllStatic
  (P4) JDK-8223258: Shenandoah: SRP::process_all_roots_slow processes JvmtiExport weak oops twice
  (P4) JDK-8217016: Shenandoah: Streamline generation of CAS barriers
  (P4) JDK-8223215: Shenandoah: Support verifying subset of roots
  (P4) JDK-8225342: Shenandoah: use COMPILER2_OR_JVMCI macro consistently
  (P4) JDK-8220780: ShenandoahBS::AccessBarrier::oop_store_in_heap ignores AS_NO_KEEPALIVE
  (P4) JDK-8224970: ShenandoahRootScanner::roots_do assert is too strong
  (P4) JDK-8217213: shenandoahTaskQueue.hpp includes .inline.hpp file
  (P4) JDK-8220664: Simplify ShenandoahUpdateHeapRefsClosure
  (P4) JDK-8217203: Some more includes to .inline.hpp files in gc header files
  (P4) JDK-8219856: Spell out G1CollectorPolicy::is_hetero_heap
  (P4) JDK-8217330: Split G1CollectionSetChooser into collection set candidate container and the chooser algorithm
  (P4) JDK-8214236: sun.gc.collector.2.name should be changed
  (P4) JDK-8218049: Survivor MemoryMXBean used() size granularity is region based
  (P4) JDK-8215047: Task terminators do not complete termination in consistent state
  (P4) JDK-8219232: Unit of concurrent active time logging is wrong
  (P4) JDK-8223449: Unprotected UseCompressedOops block in gc/shenandoah/shenandoahBarrierSetC1_x86.cpp
  (P4) JDK-8221875: Unquarantine Shenandoah string dedup tests
  (P4) JDK-8220345: Use appropriate type for G1RemSetScanState::IsDirtyRegionState
  (P4) JDK-8219613: Use NonJavaThread PtrQueues
  (P4) JDK-8220294: ZGC fails to build on GCC 4.4.7: Type parameter issue
  (P4) JDK-8225340: ZGC: Add logging of High Usage rule
  (P4) JDK-8225227: ZGC: Be exact in what load barrier to use in ZHeapIterator
  (P4) JDK-8217856: ZGC: Break out C2 matching rules into separate AD file
  (P4) JDK-8220587: ZGC: Break out forwarding information from ZPage
  (P4) JDK-8217858: ZGC: Clean up ZDriver
  (P4) JDK-8221984: ZGC: Clean up ZOop
  (P4) JDK-8217855: ZGC: Clean up ZReferenceProcessor
  (P4) JDK-8221212: ZGC: Command-line flags should be marked experimental
  (P4) JDK-8220597: ZGC: Convert ZForwarding to use ZAttachedArray
  (P4) JDK-8220596: ZGC: Convert ZNMethodData to use ZAttachedArray
  (P4) JDK-8220588: ZGC: Convert ZRelocationSet to hold ZForwardings instead of ZPages
  (P4) JDK-8220601: ZGC: Delete ZNMethodTableEntry arrays using ZSafeDelete
  (P4) JDK-8220600: ZGC: Delete ZPages using ZSafeDelete
  (P4) JDK-8218767: ZGC: Do not assume that r12 is a special register in C2
  (P4) JDK-8220591: ZGC: Don't delay reclaimation of ZVirtualMemory
  (P4) JDK-8224966: ZGC: Don't skip oop verification in OopMapSet::all_do()
  (P4) JDK-8219466: ZGC: Extract allocation functionality into a new ZNMethodAllocator class
  (P4) JDK-8219469: ZGC: Extract functions out from ZNMethodTable into new ZNMethod class
  (P4) JDK-8219468: ZGC: Extract iteration functionality into a new ZNMethodTableIteration class
  (P4) JDK-8217503: ZGC: Fix fall through bug in ZBarrierSetC2::escape_add_final_edges()
  (P4) JDK-8221537: ZGC: Fix incorrect comment in zNMethod table entry layout
  (P4) JDK-8223016: ZGC: Fix misaligned statistics printout
  (P4) JDK-8219638: ZGC: Free ZNMethodDataOops under a lock
  (P4) JDK-8220704: ZGC: gc tests complain Java heap too small
  (P4) JDK-8222469: ZGC: Generalize ZPageCache::flush()
  (P4) JDK-8221153: ZGC: Heap iteration and verification pollutes GC statistics
  (P4) JDK-8219332: ZGC: Improve ZRootsIteratorClosure abstraction
  (P4) JDK-8221786: ZGC: Increase max heap size to 16TB
  (P4) JDK-8224185: ZGC: Introduce "High Usage" rule
  (P4) JDK-8220595: ZGC: Introduce ZAttachedArray
  (P4) JDK-8220599: ZGC: Introduce ZSafeDelete
  (P4) JDK-8222467: ZGC: Log min/max/softmax capacity
  (P4) JDK-8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops
  (P4) JDK-8217258: ZGC: Minor cleanup of ZBarrierSetAssembler
  (P4) JDK-8217257: ZGC: Minor cleanup of ZBarrierSetC2
  (P4) JDK-8217747: ZGC: Minor optimization of ZLoadBarrierStubC1
  (P4) JDK-8220741: ZGC: Move CPU agnostic files from linux_x86 to linux
  (P4) JDK-8220592: ZGC: Move destruction of detached ZPages into ZPageAllocator
  (P4) JDK-8219464: ZGC: Move nmethod oop properties from ZNMethodTableEntry to ZNMethodData
  (P4) JDK-8220586: ZGC: Move relocation logic from ZPage to ZRelocate
  (P4) JDK-8217857: ZGC: Move SvcGCMarker to ZServiceabilityTracer
  (P4) JDK-8219467: ZGC: Move ZNMethodData to its own file
  (P4) JDK-8221540: ZGC: Reduce width of zForwardingEntry::from_index field
  (P4) JDK-8219463: ZGC: Remove redundant ZNMethodTable::_iter_lock
  (P4) JDK-8220594: ZGC: Remove superfluous ZPage::is_active()
  (P4) JDK-8220593: ZGC: Remove superfluous ZPage::is_detached()
  (P4) JDK-8220589: ZGC: Remove superfluous ZPageTableEntry
  (P4) JDK-8223308: ZGC: Remove ZGranuleMap::size()
  (P4) JDK-8220590: ZGC: Remove ZPages from ZPageTable when freed
  (P4) JDK-8221219: ZGC: Remove ZStallOnOutOfMemory option
  (P4) JDK-8220569: ZGC: Rename and rework ZUnmapBadViews to ZVerifyViews
  (P4) JDK-8219634: ZGC: Rename ZAddressRangeMap to ZGranuleMap
  (P4) JDK-8219633: ZGC: Rename ZPageSizeMin to ZGranuleSize
  (P4) JDK-8221146: ZGC: Reports too much relocated
  (P4) JDK-8215985: ZGC: Simplify reference processing in light of JDK-8175797
  (P4) JDK-8217745: ZGC: Simplify ZLoadBarrierStubC1
  (P4) JDK-8224965: ZGC: Strengthen ZHeap::is_in()
  (P4) JDK-8224962: ZGC: Strengthen ZHeap::is_oop()
  (P4) JDK-8223961: ZGC: Unexpected behaviour due to ZMetronome::wait_for_tick() oversleeping
  (P4) JDK-8219331: ZGC: Unify TLAB retire/remap handling
  (P4) JDK-8222182: ZGC: Use SoftMaxHeapSize to guide GC heuristics
  (P4) JDK-8219462: ZGC: Use wait/notify in ZNMethodTable
  (P4) JDK-8222180: ZGC: ZForwarding::verify() failing when checking for duplicates
  (P5) JDK-8223693: Memory wastage in size of per-region type buffers in GC
  (P5) JDK-8219097: Move comment about using weak code blobs closure for code root scanning to correct place
  (P5) JDK-8217374: Rename G1 EvacuationInfo class to G1EvacuationInfo

hotspot/jfr:
  (P2) JDK-8220293: Deadlock in JFR string pool
  (P2) JDK-8225310: JFR crashed in JfrPeriodicEventSet::requestProtectionDomainCacheTableStatistics()
  (P2) JDK-8225706: JFR RootResolver resets CLD claims with no restore
  (P2) JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant"
  (P2) JDK-8223599: minimal build fails after JDK-8185525
  (P2) JDK-8228834: Regression caused by JDK-8214542 not installing complete checkpoint data to candidates
  (P2) JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory
  (P3) JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly
  (P3) JDK-8185525: Add JFR event for DictionarySizes
  (P3) JDK-8216283: Allow shorter method sampling interval than 10 ms
  (P3) JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified
  (P3) JDK-8220657: JFR.dump does not work when filename is set
  (P3) JDK-8217089: JFR: Lazy install os interface components for improved startup
  (P3) JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds
  (P3) JDK-8217647: JFR: recordings on 32-bit systems unreadable
  (P3) JDK-8224217: RecordingInfo should use textual representation of path
  (P3) JDK-8225004: Remove invalid assertion in jfr_conditional_flush()
  (P3) JDK-8215727: Restore JFR thread sampler loop to old / previous behavior 
  (P3) JDK-8221632: Several corrections to java FlightRecorderOptions section
  (P3) JDK-8215771: The jfr tool should pretty print reference chains
  (P4) JDK-8223438: add VirtualizationInformation JFR event
  (P4) JDK-8216995: Clean up JFR command line processing
  (P4) JDK-8224139: Deprecate -XX:FlightRecorder option
  (P4) JDK-8217362: Emergency dump does not work when disk=false is set
  (P4) JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero
  (P4) JDK-8219205: JFR file without license header
  (P4) JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file
  (P4) JDK-8216436: last JFR recording  might be empty
  (P4) JDK-8218935: Make jfr strncpy uses GCC 8.x friendly
  (P4) JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run()
  (P4) JDK-8214803: Provide SQE and Infra support for 8203359 - container aware JFR events
  (P4) JDK-8216578: Remove unused/obsolete method in JFR code

hotspot/jvmti:
  (P2) JDK-8215951: AArch64:  jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults
  (P2) JDK-8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition
  (P3) JDK-8223026: [BACKOUT] Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures
  (P3) JDK-8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing
  (P3) JDK-8217348: assert(thread->is_Java_thread()) failed: just checking
  (P3) JDK-8227277: HeapInspection::find_instances_at_safepoint walks dead objects
  (P3) JDK-8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism
  (P3) JDK-8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent
  (P3) JDK-8078725: method adjustments can be done just once for all classes involved into redefinition
  (P3) JDK-8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails
  (P3) JDK-8215716: PopFrame() was unexpectedly done
  (P3) JDK-8215113: Sampling interval not always correct
  (P3) JDK-8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event
  (P3) JDK-8222952: Typo in test/hotspot/jtreg/TEST.groups is causing test harness failures
  (P3) JDK-8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed
  (P3) JDK-8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed
  (P3) JDK-8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library
  (P3) JDK-8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails
  (P3) JDK-8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash
  (P4) JDK-8223044: Add back exception checking in tests
  (P4) JDK-8201655: Add thread-enabled support for the Heap Sampling
  (P4) JDK-8221183: Avoid code cache walk in MetadataOnStackMark
  (P4) JDK-8223718: Checks in check_slot_type_no_lvt() should be always executed
  (P4) JDK-8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking
  (P4) JDK-8181171: Deleting method for RedefineClasses breaks ResolvedMethodName
  (P4) JDK-8220512: Deoptimize redefinition functions that have dirty ICs
  (P4) JDK-8213501: Deploy ExceptionJniWrapper for a few tests
  (P4) JDK-8222935: Fix ExceptionCheckingJniEnv system
  (P4) JDK-8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv
  (P4) JDK-8205126: JVMTI spec incorrectly states that PopFrame cannot be called on the current thread
  (P4) JDK-8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events
  (P4) JDK-8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events
  (P4) JDK-8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated
  (P4) JDK-8215329: Modify ZGC requirement for HeapMonitorThreadTest.java 
  (P4) JDK-8220628: Move the HeapMonitor library to C++
  (P4) JDK-8212960: Normalize spaces around comparisons and ternary
  (P4) JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions
  (P4) JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator
  (P4) JDK-8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots
  (P4) JDK-8212824: Remove unnecessary spaces before/after comparison in vmTestbase
  (P4) JDK-8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase
  (P4) JDK-8139551: Scalability problem with redefinition - multiple code cache walks
  (P4) JDK-8215425: vmTestbase/nsk/jvmti/PopFrame should provide more detailed output
  (P4) JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails
  (P4) JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out

hotspot/runtime:
  (P1) JDK-8220660: [s390]: debug build broken after JDK-8220301
  (P1) JDK-8224170: Build failures after JDK-8207812 (Implement Dynamic CDS Archive)
  (P1) JDK-8216560: gtest build broken on PPC64 and aarch64
  (P1) JDK-8224033: os::snprintf should be used in virtualizationSupport.cpp
  (P1) JDK-8216589: s390x build failures after JDK-8216167 (Update include guards to reflect correct directories)
  (P1) JDK-8223412: tier1 build failure after 8222893
  (P2) JDK-8219233: 3x performance drop for some Clojure applications
  (P2) JDK-8216269: [s390] Debug build broken because CodeBlob has not been declared
  (P2) JDK-8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
  (P2) JDK-8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry
  (P2) JDK-8218276: AIX build fails in tieredThresholdPolicy.cpp
  (P2) JDK-8220095: Assertion failure when symlink (with different name) is used for lib/modules file
  (P2) JDK-8221208: Backout JDK-8218446 
  (P2) JDK-8219969: Backout JDK-8219492
  (P2) JDK-8223437: Backout JDK-8219974 Restore static callsite resolution for the current class
  (P2) JDK-8218140: Build failures after JDK-8218041 (Assorted wrong/missing includes)
  (P2) JDK-8223589: Build failures after JDK-8223534 (add back fixed test_markOop.cpp)
  (P2) JDK-8225789: Empty method parameter type should generate ClassFormatError
  (P2) JDK-8221472: Fix HandshakeSuspendExitTest
  (P2) JDK-8218266: G1 crash in AccessInternal::PostRuntimeDispatch
  (P2) JDK-8223481: gtest/GTestWrapper.java failed due to "assert(ret == 0) failed: sem_post failed; error='Invalid argument' (errno=EINVAL)"
  (P2) JDK-8224010: Incorrect string interning
  (P2) JDK-8217765: Internal Error (javaCalls.cpp:61) guarantee(thread->can_call_java()) failed
  (P2) JDK-8222379: JFR TestClassLoadEvent.java failed due to EXCEPTION_ACCESS_VIOLATION
  (P2) JDK-8228407: JVM crashes with shared archive file mismatch
  (P2) JDK-8221726: Multiple build failures after JDK-8221698 (Remove redundant includes from popular header files)
  (P2) JDK-8228764: New library dependencies due to JDK-8222720
  (P2) JDK-8227117: normal interpreter table is not restored after single stepping with TLH
  (P2) JDK-8219974: REDO JDK-8219492: Restore static callsite resolution for the current class
  (P2) JDK-8219492: Restore static callsite resolution for the current class
  (P2) JDK-8220795: Rework naked_short_nanosleep on Windows to improve time-to-safepoint
  (P2) JDK-8224952: RI deviates from JVMS - non-zero minor_version for class files throws UnsupportedClassVersionError.
  (P2) JDK-8224795: some runtime/SelectionResolution tests are timing out
  (P2) JDK-8223190: Test gc/arguments/TestShrinkHeapInSteps.java breaks with change for JDK-8074355
  (P2) JDK-8224151: Test vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java might hang with release binaries
  (P2) JDK-8213231: ThreadSnapshot::_threadObj can become stale
  (P2) JDK-8222300: Zero build broken after JDK-8222231
  (P3) JDK-8215699: -Xlog::file cannot be used with named pipe
  (P3) JDK-8226699: [BACKOUT] JDK-8221734 Deoptimize with handshakes
  (P3) JDK-8217846: [Graal] vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java crash
  (P3) JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps
  (P3) JDK-8220441: [PPC64] Clobber memory effect missing for memory barriers in atomics
  (P3) JDK-8213481: [REDO] Fix incorrect copy constructors in hotspot
  (P3) JDK-8206107: [x86_32] jck tests for ldc2_w bytecode fail
  (P3) JDK-8222090: Add Hygon Dhyana processor support
  (P3) JDK-8224221: add memprotect calls to event log
  (P3) JDK-8221535: add steal tick related information to hs_error file [linux]
  (P3) JDK-8220173: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark
  (P3) JDK-8221437: assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method()) == m()) failed: Should not change after link resolution
  (P3) JDK-8225217: Backout: JDK-8224814:  Remove dead JNIHandleBlock freelist code
  (P3) JDK-8217658: baseline_cleanups from Async Monitor Deflation project
  (P3) JDK-8220394: bufferedStream does not honor size limit
  (P3) JDK-8059357: ClassVerifier redundantly checks constant pool entries multiple times
  (P3) JDK-8218004: Clean up terminology for shared methods within the JVM for indy and condy support
  (P3) JDK-8189208: Cleanup ancient argument processing code
  (P3) JDK-8219712: code_size2 (defined in stub_routines_x86.hpp) is too small on new Skylake CPUs
  (P3) JDK-8216970: condy causes JVM crash
  (P3) JDK-8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure
  (P3) JDK-8218483: Crash in "assert(_daemon_threads_count->get_value() > daemon_count) failed: thread count mismatch 5 : 5"
  (P3) JDK-8218751: Do not store original classfiles inside the CDS archive
  (P3) JDK-8153413: Exceptions::_throw always logs exceptions, penalizing performance
  (P3) JDK-8222977: Fix shenandoah broken with JDK-8222811
  (P3) JDK-8226525: HotSpot compile-time error for x86-32
  (P3) JDK-8207812: Implement Dynamic CDS Archive
  (P3) JDK-8221967: InternTest.java timed out
  (P3) JDK-8215311: JEP 350: Dynamic CDS Archives
  (P3) JDK-8218851: JVM crash in custom classloader stress test, JDK 12 & 13
  (P3) JDK-8210457: JVM crash in ResolvedMethodTable::add_method(Handle)
  (P3) JDK-8226406: JVM fails to detect mismatched or corrupt CDS archive
  (P3) JDK-8074355: make MutexLocker smarter about non-JavaThreads
  (P3) JDK-8218147: make_walkable asserts on multiple calls
  (P3) JDK-8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX
  (P3) JDK-8222936: mlvm/anonloader/stress/randomBytecodes/Test.java fails due to "ERROR: There were 1 hangups during parsing."
  (P3) JDK-8217659: monitor_logging updates from Async Monitor Deflation project
  (P3) JDK-8221350: more monitor logging updates from Async Monitor Deflation project
  (P3) JDK-8214162: Need to add new flag ExtensiveErrorReports to the command-line flags section in the java command reference
  (P3) JDK-8200109: NMT: diff_malloc_site  assert(early->flags() == current->flags(), "Must be the same memory type")
  (P3) JDK-8214975: No hs-err file if fatal error is raised during dynamic initialization.
  (P3) JDK-8219459: oopDesc::is_valid() is broken
  (P3) JDK-8214816: os::read() should not transition to _thread_blocked with safepoint check on Solaris
  (P3) JDK-8222387: Out-of-bounds access to CPU _family_id_xxx array
  (P3) JDK-8217843: Performance regression related to os::supports_monotonic_clock() on linux
  (P3) JDK-8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64
  (P3) JDK-8222720: Provide extended VMWare/vSphere virtualization related info in the hs_error file on linux/windows x86_64
  (P3) JDK-8222280: Provide virtualization related info in the hs_error file on AIX
  (P3) JDK-8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le
  (P3) JDK-8217786: Provide virtualization related info in the hs_error file on linux s390x
  (P3) JDK-8221207: Redo JDK-8218446 - SuspendAtExit hangs
  (P3) JDK-8224023: Redo the fix for ErrorFile option does not handle pre-existing error files of the same name
  (P3) JDK-8224497: Remove FIXME in metaspaceClosure.cpp
  (P3) JDK-8217998: Remove method_type field associated with the appendix field of  an indy or method handle call
  (P3) JDK-8221393: ResolvedMethodTable too small for StackWalking applications
  (P3) JDK-8224692: runtime/appcds tests crash in "HotSpotJVMCI::compute_offset" when running in Graal as JIT mode
  (P3) JDK-8218399: runtime/RedefineObject/TestRedefineObject.java timeout
  (P3) JDK-8225702: Safepoint counter can't be used for safepoint detection
  (P3) JDK-8220151: SafepointTracing::end_of_last_safepoint_ms should return ms since epoch.
  (P3) JDK-8224193: stringStream should not use Resource Area
  (P3) JDK-8216049: stringTable::intern creates redundant String when looking up existing one
  (P3) JDK-8215962: Support ThreadPriorityPolicy mode 1 for non-root users on linux/bsd
  (P3) JDK-8218446: SuspendAtExit hangs
  (P3) JDK-8216136: Take Compile_lock for SystemDictionary::_modification_counter with safepoint check
  (P3) JDK-8223287: Update java manpage for Application Class Data Sharing
  (P3) JDK-8227496: Update NUM_CDS_REGIONS and CURRENT_CDS_ARCHIVE_VERSION in cds.h
  (P3) JDK-8218939: vm/mlvm/anonloader/stress/byteMutation crashed on windows
  (P3) JDK-8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0
  (P3) JDK-8223472: volatile long field corruption on x86_32
  (P3) JDK-8223572: ~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()
  (P4) JDK-8218156: "jcmd VM.metaspace basic" misreports free chunk space
  (P4) JDK-8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
  (P4) JDK-8221685: -XX:BytecodeVerificationRemote and -XX:BytecodeVerificationLocal should be diagnostic options
  (P4) JDK-8223248: [AIX] Remove old xlC 10 workaround for load acquire
  (P4) JDK-8217338: [Containers] Improve systemd slice memory limit support
  (P4) JDK-8219565: [deadcode] remove share/utilities/intHisto.*
  (P4) JDK-8219798: [deadcode] remove src/hotspot/share/prims/evmCompat.cpp 
  (P4) JDK-8221639: [i386] expand_exec_shield_cs_limit workaround is undefined code after JDK-8199717
  (P4) JDK-8170639: [Linux]  jsig is limited to a maximum of 64 signals
  (P4) JDK-8215707: [macosx] fix pthread_getschedparam and pthread_setschedparam calls
  (P4) JDK-8221539: [metaspace] Improve MetaspaceObj::is_metaspace_obj() and friends
  (P4) JDK-8223249: [s390] Cleanup TemplateInterpreterGenerator::generate_fixed_frame
  (P4) JDK-8225347: [s390] Unexpected exit from stack overflow test
  (P4) JDK-8225178: [Solaris] os::signal() should call sigaction() with SA_SIGINFO
  (P4) JDK-8219888: aarch64 : add CPU detection code for HiSilicon TSV110
  (P4) JDK-8222753: AArch64: Add CPU implementer code for Ampere 
  (P4) JDK-8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable 
  (P4) JDK-8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield
  (P4) JDK-8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static
  (P4) JDK-8224828: aarch64: rflags is not correct after safepoint poll
  (P4) JDK-8220566: AArch64: Set default vm features for Ampere eMAG CPUs
  (P4) JDK-8219698: aarch64: SIGILL triggered when specifying unsupported hardware features
  (P4) JDK-8223534: add back fixed test_markOop.cpp
  (P4) JDK-8220774: Add HandshakeALot diag option
  (P4) JDK-8221325: Add information about swap space to print_memory_info() on MacOS
  (P4) JDK-8223574: add more thread-related system settings info to hs_error file on AIX
  (P4) JDK-8224958: add os::dll_load calls to event log
  (P4) JDK-8222713: Add OutputAnalyzer(Path) constructor
  (P4) JDK-8217450: Add PackageEntry::locked_lookup_only
  (P4) JDK-8216366: Add rationale to PER_CPU_SHARES define
  (P4) JDK-8212988: add recent class unloading events to the hs_err log
  (P4) JDK-8220570: Additional trace when native thread creation fails
  (P4) JDK-8214235: arm32: assertion in collectedHeap.cpp: attempt to clean empty array
  (P4) JDK-8223336: Assert in  VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with  -XX:NativeMemoryTracking=detail
  (P4) JDK-8216982: Assertion poison page established too early
  (P4) JDK-8218041: Assorted wrong/missing includes
  (P4) JDK-8224020: AsyncGetCallTrace test should not run on PPC64 or IA64
  (P4) JDK-8220690: ATTRIBUTE_ALIGNED requires GNU extensions enabled
  (P4) JDK-8214777: Avoid some GCC 8.X strncpy() errors in HotSpot
  (P4) JDK-8218145: block_if_requested is not proper inlined due to size
  (P4) JDK-8205645: Bump maximum recognized class file version to 57 for JDK 13
  (P4) JDK-8224853: CDS address sanitizer errors
  (P4) JDK-8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file
  (P4) JDK-8216010: Change callers of build_u2_from() to call Bytes::get_Java_u2() instead
  (P4) JDK-8213153: Clean up GCC 8 errors
  (P4) JDK-8215644: Clean up globalDefinitions_<compiler>.hpp
  (P4) JDK-8222231: Clean up interfaceSupport.inline.hpp duplicated code
  (P4) JDK-8219860: Cleanup ClassFileParser::parse_linenumber_table
  (P4) JDK-8219630: cleanup hotspot ostream.cpp
  (P4) JDK-8194860: Cleanup Semaphore timed-wait time calculations
  (P4) JDK-8222811: Consolidate MutexLockerEx and MutexLocker
  (P4) JDK-8217766: Container Support doesn't work for some Join Controllers combinations
  (P4) JDK-8221351: Crash in KlassFactory::check_shared_class_file_load_hook
  (P4) JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr
  (P4) JDK-8220351: Cross-modifying code
  (P4) JDK-8225016: Dead code due to VMOperationQueue::add() always returning true
  (P4) JDK-8213399: DecoderLocker is unused
  (P4) JDK-8221734: Deoptimize with handshakes
  (P4) JDK-8214719: Deprecate -Xverify:none option
  (P4) JDK-8220050: Deprecate -XX:-ThreadLocalHandshakes
  (P4) JDK-8221180: Deprecate AllowJNIEnvProxy
  (P4) JDK-8218995: Deprecate the -XX:FailOverToOldVerifier option
  (P4) JDK-8221096: Description of -XX:+PrintFlagsRanges is incorrect
  (P4) JDK-8221478: Disable VerifySharedSpaces by default
  (P4) JDK-8224750: Display thread once in Internal exceptions event log lines
  (P4) JDK-8221724: Enable archiving of Strings with hash 0 
  (P4) JDK-8216157: Enable inlining of java_lang_Class::is_primitive
  (P4) JDK-8217325: Enable inlining of java_lang_Class::oop_size_raw
  (P4) JDK-8219247: Enable inlining of newly introduced PlatformMonitor methods
  (P4) JDK-8221738: ErrorFile option does not handle pre-existing error files of the same name
  (P4) JDK-8204551: Event descriptions are truncated in logs
  (P4) JDK-8225402: events logging in deoptimization.cpp  should go to deopt-log
  (P4) JDK-8214271: Fast primitive to wake many threads
  (P4) JDK-8203469: Faster safepoints
  (P4) JDK-8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian
  (P4) JDK-8221992: Fix old method replacement in ResolvedMethodTable
  (P4) JDK-8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings
  (P4) JDK-8218565: HandleMark cleanup
  (P4) JDK-8223186: HotSpot compile warnings from GCC 9
  (P4) JDK-8223810: HotSpot compile warnings from VS2017
  (P4) JDK-8217879: hs_err should print more instructions in hex dump
  (P4) JDK-8215977: hsdis installation documentation update
  (P4) JDK-8218164: Improve local control of compiler warnings
  (P4) JDK-8218988: Improve metaspace verifications
  (P4) JDK-8214442: Improve stack walk API by adding handle marks
  (P4) JDK-8220658: Improve the readability of container information in the error log
  (P4) JDK-8218581: Incorrect exception message generation
  (P4) JDK-8222226: increase default timeout for runtime/7158800/InternTest.java
  (P4) JDK-8221477: Inject os/cpu-specific constants into Unsafe from JVM
  (P4) JDK-8222297: IRT_ENTRY/IRT_LEAF etc are the same as JRT
  (P4) JDK-8225453: is_busy diagnostics and other baseline cleanups from Async Monitor Deflation project
  (P4) JDK-8222327: java_lang_Thread _thread_status_offset, remove pre 1.5 code paths
  (P4) JDK-8221480: jcmd VM.metaspace shall print limits in basic mode
  (P4) JDK-8228585: jdk/internal/platform/cgroup/TestCgroupMetrics.java - NumberFormatException because of large long values (memory limit_in_bytes)
  (P4) JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64
  (P4) JDK-8217618: JVM TI SuspendThread doesn't suspend the current thread before returning
  (P4) JDK-8219562: Line of code in osContainer_linux.cpp#L102 appears unreachable
  (P4) JDK-8220781: linux-s390 : os::get_summary_cpu_info gives bad output
  (P4) JDK-8219229: Make ConstantPool::tag_at and release_tag_at_put inlineable
  (P4) JDK-8223956: Make SymbolTable and StringTable AllStatic
  (P4) JDK-8222893: markOopDesc::print_on() is a bit confused
  (P4) JDK-8217512: Message of LinkageError: use 'class' etc. instead of 'type'
  (P4) JDK-8219574: Minimal VM build failure after JDK-8219414
  (P4) JDK-8223064: Minor cleanups in ResolvedMethodTable
  (P4) JDK-8222295: more baseline cleanups from Async Monitor Deflation project
  (P4) JDK-8215731: Move forward class definitions out of globalDefinitions.hpp
  (P4) JDK-8223626: move print() functions to cpp files
  (P4) JDK-8219112: name_and_sig_as_C_string usages in  frame_s390  miss ResourceMark
  (P4) JDK-8214180: Need better granularity for sleeping
  (P4) JDK-8218558: NMT stack traces in output should show mt component for virtual memory allocations
  (P4) JDK-8199746: NMT: Breakup overused mtInternal into more fine grained categories. 
  (P4) JDK-8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread
  (P4) JDK-8218566: NMT: missing memory tag for assert poison page
  (P4) JDK-8219370: NMT: Move synchronization primitives from mtInternal to mtSynchronizer
  (P4) JDK-8204552: NMT: Separate thread stack tracking from virtual memory tracking
  (P4) JDK-8222637: Obsolete NeedsDeoptSuspend
  (P4) JDK-8218753: Obsolete nonproduct flag ProfilerCheckIntervals
  (P4) JDK-8217442: Optimize native accesses to String.value
  (P4) JDK-8220366: Optimize Symbol handling in ClassVerifier and SignatureStream
  (P4) JDK-8224871: os::attempt_reserve_memory_at() tries too hard
  (P4) JDK-8224793: os::die() does not honor CreateCoredumpOnCrash option
  (P4) JDK-8221149: os::malloc checks MallocCatchPtr outside of ifdef ASSERT block
  (P4) JDK-8217994: os::print_hex_dump should be more resilient against unreadable memory
  (P4) JDK-8224487: outputStream should not be copyable
  (P4) JDK-8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address
  (P4) JDK-8223395: PPC64: Improve comments in the JVM signal handler to match ISA text
  (P4) JDK-8219460: ppc: adjust NativeGeneralJump::insert_unconditional  to stack allocated MacroAssembler
  (P4) JDK-8214707: Prevent GCC 8 from reporting error in ClassLoader::file_name_for_class_name()
  (P4) JDK-8221470: Print methods in exception messages in java-like Syntax.
  (P4) JDK-8217315: Proper units should print more significant digits
  (P4) JDK-8224816: Provide os::processor_id() implementation for Mac OS
  (P4) JDK-8219368: Quarantine runtime/NMT/CheckForProperDetailStackTrace.java test
  (P4) JDK-8220496: Race in java_lang_String::length() when deduplicating
  (P4) JDK-8221833: Readability check in Symbol::is_valid not performed for some addresses
  (P4) JDK-8218675: Reduce verification overhead in ClassFileParser
  (P4) JDK-8219713: Reduce work in DefaultMethods::generate_default_methods
  (P4) JDK-8219554: Redundant lookup_common in SymbolTable::add
  (P4) JDK-8217660: Refactor module related locked_create_entry_or_null() functions
  (P4) JDK-8218755: Refix Symbol leak in prepend_host_package_name
  (P4) JDK-8183004: Remove code related to gtest death tests from assert macro
  (P4) JDK-8214821: Remove ConcurrentHashTable::get_copy
  (P4) JDK-8212949: Remove ConstantPoolCache::is_constantPoolCache
  (P4) JDK-8218738: Remove dead code in Symbol and friends
  (P4) JDK-8224814: Remove dead JNIHandleBlock freelist code
  (P4) JDK-8216188: Remove expired flags in JDK 13
  (P4) JDK-8216191: Remove FastSuperclassLimit
  (P4) JDK-8215155: Remove get_insert() from concurrent hashtable and gtests
  (P4) JDK-8216428: Remove IgnoreLibthreadGPFault
  (P4) JDK-8224203: Remove need to specify type when using FLAG_SET macros
  (P4) JDK-8221698: Remove redundant includes from popular header files
  (P4) JDK-8219579: Remove redundant signature parsing from the verifier
  (P4) JDK-8210832: Remove sneaky locking in class Monitor 
  (P4) JDK-8219611: Remove superfluous sigfillset code
  (P4) JDK-8217424: Remove the idempotent parameter to Method::sort_methods
  (P4) JDK-8223306: Remove threads linked list (use ThreadsList's array in SA)
  (P4) JDK-8222518: Remove unnecessary caching of Parker object in java.lang.Thread
  (P4) JDK-8217841: Remove unused class TraceCPUTime
  (P4) JDK-8216197: Remove unused new_hash methods
  (P4) JDK-8223657: Remove unused THREAD argument from SymbolTable functions
  (P4) JDK-8219619: Remove UseFakeTimers and related code
  (P4) JDK-8221872: Remove uses of ClassLoaderWeakHandle typedef in protection domain table
  (P4) JDK-8224790: Remove Xusage.txt file
  (P4) JDK-8222502: Replace 19,20 case alternatives with JVM_CONSTANT_Module/Package names
  (P4) JDK-8218811: replace open by os::open in hotspot coding
  (P4) JDK-8222558: Rework ResolvedMethodTable verification
  (P4) JDK-8214097: Rework thread initialization and teardown logic
  (P4) JDK-8217921: Runtime dead code removal
  (P4) JDK-8222500: runtime/8176717/TestInheritFD.java failed with java.nio.file.NoSuchFileException: /tmp/communication7071713601211876892.txt
  (P4) JDK-8220085: runtime/CompressedOops/UseCompressedOops.java times out on Windows intermittently  
  (P4) JDK-8188872: runtime/ErrorHandling/TimeoutInErrorHandlingTest.java fails intermittently
  (P4) JDK-8222292: runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ArrayIndexOutOfBoundsExceptionTest.java timeout but test passed
  (P4) JDK-8222550: runtime/MemberName/MemberNameLeak.java times out
  (P4) JDK-8227041: runtime/memory/RunUnitTestsConcurrently.java has a memory leak
  (P4) JDK-8228650: runtime/SharedArchiveFile/CheckDefaultArchiveFile.java test fails on AIX
  (P4) JDK-8223194: runtime/Shutdown/ShutdownTest.java due to "OutOfMemoryError: Java heap too small"
  (P4) JDK-8224119: Safepoint cleanup logging logs times for things it doesn't do
  (P4) JDK-8219436: Safepoint logs correction and misc
  (P4) JDK-8215495: Set isCopy to JNI_FALSE if len == 0
  (P4) JDK-8218151: Simplify JavaThread::thread_state definition
  (P4) JDK-8224201: Simplify JVM flag macro expansions
  (P4) JDK-8222015: Small VM.metaspace improvements
  (P4) JDK-8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor
  (P4) JDK-8216302: StackTraceElement::fill_in can use cached Class.name
  (P4) JDK-8216308: StackTraceElement::fill_in can use injected Class source-file
  (P4) JDK-8219685: Startup failure: assert(!Universe::is_module_initialized()) failed: Incorrect java.lang.Module pre module system initialization
  (P4) JDK-8225225: stringStream internal buffer should always be zero terminated
  (P4) JDK-8218593: Symbol leak in prepend_host_package_name
  (P4) JDK-8213753: SymbolTable is double walked during class unloading and clean up table timing in do_unloading
  (P4) JDK-8219441: test_logMessageTest missing static storage
  (P4) JDK-8220724: TestBiasedLockRevocationEvents fails while matching revoke events to VMOperation events
  (P4) JDK-8222034: Thread-SMR functions should be updated to remove work around
  (P4) JDK-8221643: Tighten up assert(_keep_alive >= 0) in CLD::inc_keep_alive
  (P4) JDK-8215791: Tiny bug in VM monitoring/management
  (P4) JDK-8219584: Try to dump error file by thread which causes safepoint timeout
  (P4) JDK-8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info
  (P4) JDK-8223391: Unsynchronized iteration of ClassLoaderDataGraph
  (P4) JDK-8216167: Update include guards to reflect correct directories
  (P4) JDK-8224763: Update man pages to show deprecation of -Xverify:none
  (P4) JDK-8223231: Update manpage with new semantics of ErrorFile option
  (P4) JDK-8216426: Usage of array placement new may lead to memory corruption
  (P4) JDK-8215228: Use a constant hash table size in order to enable compiler optimization
  (P4) JDK-8223313: Use handshakes for CountStackFrames.
  (P4) JDK-8222988: Use MonitorLocker rather than MutexLocker when wait/notify used
  (P4) JDK-8217378: UseCriticalCMSThreadPriority is broken
  (P4) JDK-8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI calls.
  (P4) JDK-8222534: VerifyBeforeExit is not honored when System.exit is called
  (P4) JDK-8193234: When using -Xcheck:jni an internally allocated buffer can leak
  (P4) JDK-8221408: Windows 32bit build build errors/warnings in hotspot
  (P4) JDK-8220283: ZGC fails to build on GCC 4.4.7: ATTRIBUTE_ALIGNED compatibility issue
  (P5) JDK-8216189: Remove Klass::compute_is_subtype_of
  (P5) JDK-8219577: Returning NULL in a function which returns bools

hotspot/svc:
  (P1) JDK-8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test)
  (P3) JDK-8224796: C code is not compiled correctly due to undefined "i386"
  (P3) JDK-8219023: Sync JVMTI, JDI, and JDWP spec versions with JDK version
  (P4) JDK-8224230: [PPC64, s390] Support AsyncGetCallTrace
  (P4) JDK-8221915: cleanup ticks related coding in os_perf_aix.cpp [aix]
  (P4) JDK-8181383: com/sun/jdi/OptionTest.java fails intermittently with bind failed: Address already in use 
  (P4) JDK-8221532: Incorrect copyright header in FileSystemSupport_md.c 
  (P4) JDK-8224600: Provide VM.events command
  (P4) JDK-8225388: Running jcmd Compiler.CodeHeap_Analytics all 0 cause crash.
  (P4) JDK-8205654: serviceability/dcmd/framework/HelpTest.java timed out
  (P4) JDK-8225348: serviceability/dcmd/vm/EventsTest.java failed
  (P4) JDK-8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms

hotspot/svc-agent:
  (P2) JDK-8225801: Shenandoah: Adjust SA to reflect recent forwarding pointer changes
  (P3) JDK-8220682: Heap dumping and inspection fails with JDK-8214712
  (P3) JDK-8214756: SA should ignore archived java heap objects that are not in use
  (P3) JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5
  (P3) JDK-8181313: SA: Remove libthread_db dependency on Linux
  (P3) JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers
  (P4) JDK-8217612: (CL)HSDB cannot show some JVM flags
  (P4) JDK-8209413: AArch64: NPE in clhsdb jstack command
  (P4) JDK-8221396: Clean up serviceability/sa/TestUniverse.java
  (P4) JDK-8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612
  (P4) JDK-8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out
  (P4) JDK-8217845: SA should refer const values for JVMFlag from HotSpot
  (P4) JDK-8218743: SA: Add support for large bitmaps
  (P4) JDK-8218733: SA: CollectedHeap provides broken implementation for used() and capacity() 
  (P4) JDK-8223665: SA: debugd options should follow jhsdb style
  (P4) JDK-8218922: SA: Enable best-effort implementation of live regions iteration for ZGC
  (P4) JDK-8218970: SA: Enable HeapHprofBinWriter for ZGC
  (P4) JDK-8218978: SA: Enable more ZGC testing
  (P4) JDK-8218746: SA: Implement discontiguous bitmap for ZGC
  (P4) JDK-8218734: SA: Incorrect and raw loads of OopHandles
  (P4) JDK-8223814: SA: jhsdb common help needs to be more detailed
  (P4) JDK-8219414: SA: jhsdb jsnap throws UnmappedAddressException with core generated by gcore
  (P4) JDK-8219003: SA: Refactor live regions iteration in preparation for JDK-8218922
  (P4) JDK-8218732: SA: Resolves ZPageAllocator::_physical incorrectly
  (P4) JDK-8218731: SA: Use concrete class as the return type of VMObjectFactory.newObject 
  (P4) JDK-8213457: serviceability/sa/ClhsdbInspect.java time out
  (P4) JDK-8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
  (P4) JDK-8220602: Shenandoah-SA: Enable best-effort implementation of heap walk
  (P4) JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 

hotspot/test:
  (P3) JDK-8218017: Application with a lot of threads stuck during exit related to java.util.logging.LogManager$Cleaner shutdown hook
  (P3) JDK-8158048: Fix failure message from jtreg gtest wrapper
  (P3) JDK-8224945: googlemock update breaks the build of arm32 and ppc
  (P3) JDK-8189400: testlibrary_tests are not tested in hotspot tiers
  (P4) JDK-8222414: bring googlemock v1.8.1
  (P4) JDK-8209917: fix TODO in GatherDiagnosticInfoObserver
  (P4) JDK-8209807: improve handling exception in requires.VMProps
  (P4) JDK-8219395: integrate gcov w/ run-test 
  (P4) JDK-8219139: move hotspot tests from test/jdk/vm
  (P4) JDK-8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses
  (P4) JDK-8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java
  (P4) JDK-8222154: upgrade gtest to 1.8.1
  (P4) JDK-8219158: use 'test.root' property instead of traversing test-src path

infrastructure:
  (P3) JDK-8221857: Collect code coverage for a subset of code
  (P3) JDK-8225134: Update man-page files
  (P4) JDK-8215729: Enhance makefiles to allow collecting code coverage with JCov
  (P4) JDK-8227247: tools/sjavac/IdleShutdown.java fails with AssertionError: Error too big on windows
  (P4) JDK-8219906: Update test documentation with default test jobs settings

infrastructure/build:
  (P1) JDK-8220155: JDK-8219971 broke hotspot build
  (P1) JDK-8220529: JDK-8220383 broke test image build
  (P1) JDK-8218084: Revert JDK-8218057
  (P2) JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac
  (P2) JDK-8222913: Add Jib support for VERSION_EXTRA*
  (P2) JDK-8225066: Add missing file 
  (P2) JDK-8221996: Bootcycle build broken
  (P2) JDK-8218177: Bump jib format_version to support new devkit archive layout
  (P2) JDK-8221414: Bump required boot jdk version to 12
  (P2) JDK-8219988: Change to Visual Studio 2017 15.9.6 for building on Windows at Oracle
  (P2) JDK-8219986: Change to Xcode 10.1 for building on Macosx at Oracle
  (P2) JDK-8220383: Incremental build is broken and inefficient
  (P2) JDK-8218198: Revert devkit change in JDK-8217910 for linux-x64
  (P2) JDK-8222264: Windows incremental build is broken with JDK-8217728
  (P3) JDK-8225489: accessibility issues in pandoc-generated tables
  (P3) JDK-8218057: Add ppc64le and s390x profiles to jib-profiles.js
  (P3) JDK-8217626: Add setup/teardown functionality to RunTest
  (P3) JDK-8226404: bootcycle build uses wrong CDS archive
  (P3) JDK-8225140: Build fails if directory contains 'unix'
  (P3) JDK-8218736: Build warning in lib/JvmFlags.gmk: extraneous text after 'ifeq' directive
  (P3) JDK-8217032: Check pandoc capabilities in configure
  (P3) JDK-8218186: Clean up CLDR generation in build
  (P3) JDK-8223335: Compare baseline builds on linux are failing
  (P3) JDK-8225392: Comparison builds are failing due to cacerts file
  (P3) JDK-8219788: Configure recommends JDK 8
  (P3) JDK-8225346: Convert file to HTML5
  (P3) JDK-8224166: Create a taglet to better handle @jls and @jvms tags
  (P3) JDK-8209381: Default CDS classlist generation should run with an explicit locale setting
  (P3) JDK-8205934: Define jdk -source/-target version in version-numbers file
  (P3) JDK-8224677: Dtrace .d files clash with make dependency .d files
  (P3) JDK-8223307: enable the Stack Execution Disable flag for JDK binaries on AIX
  (P3) JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov
  (P3) JDK-8226538: find-files.gmk gets corrupted if tab completion is used before running make first
  (P3) JDK-8220164: Fix build instructions for AIX
  (P3) JDK-8224257: fix issues in files generated by pandoc
  (P3) JDK-8227636: Fix output dir for jlink_jre target in Images.gmk
  (P3) JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation
  (P3) JDK-8217357: Implement JCov jib profiles
  (P3) JDK-8218431: Improved platform checking in makefiles
  (P3) JDK-8219971: Introduce SetupExecute in build system
  (P3) JDK-8223627: jdk-13+20 bundle name contains null instead of ea
  (P3) JDK-8211016: make images does not update jdk/lib/src.zip with latest changes
  (P3) JDK-8218413: make reconfigure ignores configure-time AUTOCONF environment variable
  (P3) JDK-8226269: Race in SetupProcessMarkdown
  (P3) JDK-8217638: Remove old way of running tests (test/Makefile)
  (P3) JDK-8217634: RunTest documentation and usability update
  (P3) JDK-8217730: Split up MakeBase.gmk
  (P3) JDK-8218692: Switch to JCov build which supports byte code version 57
  (P3) JDK-8226628: The copyright footer should be enclosed in <footer>
  (P3) JDK-8225496: typo in fix for JDK-8224257
  (P3) JDK-8217233: Update build settings for AIX/xlc
  (P3) JDK-8223663: Update links for tool guides
  (P3) JDK-8228494: Update nroff version of man pages
  (P3) JDK-8218046: use bundled freetype in the AIX build by default
  (P3) JDK-8227578: Wrong JRE targets in Images.gmk after JDK-8219971
  (P4) JDK-8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled
  (P4) JDK-8222444: Add a suggestion for non-US locale in the test doc
  (P4) JDK-8222522: Add configure options for Mac Bundle creation
  (P4) JDK-8223319: Add copyright footer to specs and man pages
  (P4) JDK-8219393: Add native library support for microbenchmarks
  (P4) JDK-8221894: Add notes for docker tests in the test doc
  (P4) JDK-8221988: add possibility to build with Visual Studio 2019 
  (P4) JDK-8223678: Add Visual Studio Code workspace generation support (for native code)
  (P4) JDK-8218965: aix:  support xlclang++ in the compiler detection
  (P4) JDK-8219129: Allow overriding of license files in legal dir
  (P4) JDK-8223667: ASAN build broken
  (P4) JDK-8221880: Better customization for Windows RC properties FileDescription and ProductName
  (P4) JDK-8220530: Build compare script does not compare the contents of the test image
  (P4) JDK-8224145: Build compare script fails intermittently on test image native libraries
  (P4) JDK-8217916: Build compare script is not comparing jmods
  (P4) JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling
  (P4) JDK-8220093: Change to GCC 8.2 for building on Linux at Oracle
  (P4) JDK-8217448: Check for pandoc availability using ENABLE_PANDOC and not PANDOC
  (P4) JDK-8221979: Cleanups for building Windows resources
  (P4) JDK-8218807: Compilation database (compile_commands.json) may contain obsolete items
  (P4) JDK-8224087: Compile C code for at least C99 Standard compliance
  (P4) JDK-8210834: Cross compilation triggers rebuild even without changes
  (P4) JDK-8219920: dependency help output in configure-step : support zypper tool
  (P4) JDK-8216275: Disable annotation processing lint warnings when building microbenchmarks
  (P4) JDK-8215445: Enable building for Windows in WSL
  (P4) JDK-8219391: extend gcov support to llvm/clang
  (P4) JDK-8224011: Failure handling in ExecuteWithLog fails in run-test-prebuilt
  (P4) JDK-8221621: FindTests.gmk cannot handle "=" in TEST.groups comments
  (P4) JDK-8216278: Fix devkit and basic Jib support on WSL
  (P4) JDK-8216048: Fix devkit creation in WSL
  (P4) JDK-8216267: Fix hotspot-ide-project target on WSL
  (P4) JDK-8221434: Fix typo in lib-x11 autoconf error message about missing headers
  (P4) JDK-8223944: fix zlib related building docu and comments
  (P4) JDK-8220363: hotspot-ide project fails
  (P4) JDK-8220784: hsdis cannot be built with MinGW64
  (P4) JDK-8221762: Improve Main.gmk/FindTests.gmk bootstrap time
  (P4) JDK-8223464: Improve version string for Oracle CI builds
  (P4) JDK-8216489: Issues with ModulePackages attribute generation on incremental build
  (P4) JDK-8217979: lib-freetype related configure messages contain wrong configure flag names
  (P4) JDK-8217896: Make better use of LCPUs when building on AIX
  (P4) JDK-8226910: make it possible to use jtreg's -match via run-test framework
  (P4) JDK-8221907: make reconfigure breaks when configured with relative paths
  (P4) JDK-8217733: Minor RunTest fixes
  (P4) JDK-8219394: Missing FIXPATH in microbenchmark test runner
  (P4) JDK-8220504: Move definition of JAVA_VERSION_INFO_RESOURCE to Launcher-java.base.gmk
  (P4) JDK-8204564: Need better error output when GenerateLinkOptData fails
  (P4) JDK-6442874: Need to keep new errors from occuring in javadoc comments
  (P4) JDK-8218135: Redo: Add ppc64le and s390x profiles to jib-profiles.js
  (P4) JDK-8221764: Reduce make Init.gmk logging overhead
  (P4) JDK-8189861: Refactor CacheFind
  (P4) JDK-8222150: Refactor CheckReleaseDate.java test
  (P4) JDK-8222627: Remove sneaky token 'Name' in jdk-version.m4
  (P4) JDK-8221610: Resurrect (legacy) JRE bundle target
  (P4) JDK-8221703: Rmic build for java.management.api has bad incremental behavior
  (P4) JDK-8193255: Root Certificates should be stored in text format and assembled at build time
  (P4) JDK-8217910: Slow linking with devkit on Linux
  (P4) JDK-8222510: Small cleanup for JDK launcher's make file
  (P4) JDK-8217728: Speed up incremental rerun of "make hotspot"
  (P4) JDK-8215991: Stop hiding exception from ArtifactResolver failures in tests
  (P4) JDK-8220445: Support for side by side MSVC Toolset versions
  (P4) JDK-8223309: test failing due to self-assign-overloaded
  (P4) JDK-8222735: Update doc/building.md with current Oracle build platforms and compilers
  (P4) JDK-8215952: Update NetBeans project file
  (P4) JDK-8221357: Update test documentation by deleting "cd test && make"
  (P4) JDK-8130017: use _FORTIFY_SOURCE in gcc fastdebug builds
  (P4) JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC
  (P4) JDK-8223685: used bundled zlib on AIX  by default
  (P4) JDK-8221179: Zero builds fail when linking with gold and bundling libffi.so

install:
  (P3) JDK-8217018: Java Access Bridge is not enabled/disabled when the checkbox is checked/unchecked via the Control Panel

install/install:
  (P2) JDK-8215576: 8205556 push had corrupted l10n chars during handoff

other-libs/corba:
  (P3) JDK-8224682: Remove the com.sun.CORBA.ORBIorTypeCheckRegistryFilter security property

other-libs/other:
  (P4) JDK-8219417: bump jtreg requiredVersion to b14
  (P4) JDK-8219132: switch to jtreg4.2-b14

performance:
  (P4) JDK-8217518: Crypto benchmarks not warming up in time
  (P4) JDK-8221543: Indify-dependent microbenchmarks are broken
  (P4) JDK-8215643: Microbenchmarks for KeyAgreement and Cipher

performance/libraries:
  (P4) JDK-8215572: Add new Arrays micros
  (P4) JDK-8220368: Update String.indexOf to test all the C2 intrinsics

security-libs/java.security:
  (P2) JDK-8026953: Add support for MS Cryptography next generation (CNG)
  (P2) JDK-8228399: Remove mistaken open.iml
  (P2) JDK-8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test
  (P2) JDK-8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows
  (P2) JDK-8217690: Update public suffix version
  (P3) JDK-8159525: Add @FunctionalInterface annotation to PrivilegedAction and PrivilegedExceptionAction
  (P3) JDK-8219861: Add new keytool -showinfo -tls command for displaying TLS configuration information 
  (P3) JDK-8222133: Add temporary exceptions for root certs that are due to expire soon
  (P3) JDK-8224729: Cleanups in sun/security/provider/certpath/ldap/LDAPCertStoreImpl.java
  (P3) JDK-8221257: Improve serial number generation mechanism for keytool -gencert 
  (P3) JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support
  (P3) JDK-8218618: Program fails when using JDK addressed by UNC path and using Security Manager
  (P3) JDK-8222137: Remove T-Systems root CA certificate
  (P3) JDK-8222136: Remove two Comodo root CA certificates that are expiring
  (P3) JDK-8223499: Remove two DocuSign root certificates that are expiring
  (P3) JDK-8228403: SignTwice.java failed with java.io.FileNotFoundException: File name too long
  (P3) JDK-8225257: sun/security/tools/keytool/PSS.java timed out
  (P3) JDK-8202651: Test ComodoCA.java fails
  (P3) JDK-8157404: Unable to read certain PKCS12 keystores from SequenceInputStream
  (P4) JDK-8042904: apple.security.KeychainStore.getSalt() calling generateSeed()
  (P4) JDK-8215937: Check usages of security-related Resources files
  (P4) JDK-8191808: Configurable read timeout for CRLs
  (P4) JDK-8147502: Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size
  (P4) JDK-8218553: Enhance keystore load debug output
  (P4) JDK-8224589: Improve startup behavior of SecurityProperties
  (P4) JDK-8221719: Jarsigner fails to verify signed by alias if alias given in wrong case
  (P4) JDK-8215769: Java cannot probe pkcs12 files exported by Firefox
  (P4) JDK-8036608: Key.getAlgorithm link to standard algorithm names needs to be updated
  (P4) JDK-8218888: keytool -genkeypair should not have the -destalias option
  (P4) JDK-8215776: Keytool importkeystore may mix up certificate chain entries when DNs conflict
  (P4) JDK-8227595: keytool/fakegen/DefaultSignatureAlgorithm.java fails due to "exitValue = 6"
  (P4) JDK-8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings
  (P4) JDK-8222987: sun/security/tools/keytool/PSS.java times out on Solaris-SPARC
  (P4) JDK-8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false
  (P4) JDK-8221801: Update src/java.base/share/legal/public_suffix.md

security-libs/javax.crypto:
  (P2) JDK-8220165: Encryption using GCM results in RuntimeException: input length out of bound
  (P2) JDK-8218723: Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation
  (P3) JDK-8181386: CipherSpi ByteBuffer to byte array conversion fails for certain data overlap conditions
  (P3) JDK-8201633: Problems with AES-GCM native acceleration
  (P3) JDK-7107615: scalability bloker in javax.crypto.JceSecurity
  (P3) JDK-8223003: SunMSCAPI keys are not cleaned up
  (P4) JDK-8217344: Make comparison overflow-aware in ECDHKeyAgreement.engineGenerateSecret()
  (P4) JDK-8213009: Refactoring existing SunMSCAPI classes
  (P4) JDK-8221172: SunEC specific test is not limited to SunEC
  (P4) JDK-8223063: Support CNG RSA keys
  (P4) JDK-8213010: Supporting keys created with certmgr.exe
  (P4) JDK-8217820: Useless cast in ECUtil.java
  (P4) JDK-8221407: Windows 32bit build error in libsunmscapi/security.cpp

security-libs/javax.crypto:pkcs11:
  (P1) JDK-8225695: 32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)
  (P2) JDK-8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after  JDK-8216597 (SIGBUS error in getNativeKeyInfo)
  (P2) JDK-8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047
  (P3) JDK-8213008: Cipher with UNWRAP_MODE should support the generation of an AES key type
  (P3) JDK-6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space
  (P3) JDK-8183107: PKCS11 regression regarding checkKeySize
  (P3) JDK-8226651: Setting the mgfHash in CK_RSA_PKCS_PSS_PARAMS has no effect
  (P3) JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support
  (P4) JDK-8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider
  (P4) JDK-8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider

security-libs/javax.net.ssl:
  (P2) JDK-8219990: Backout JDK-8219658
  (P2) JDK-8219658: Deadlock in sun.security.ssl.SSLSocketImpl
  (P2) JDK-8227551: Session Resumption without Server-Side State off by default
  (P2) JDK-8216326: SSLSocket stream close() does not close the associated socket
  (P2) JDK-8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256
  (P2) JDK-8171279: Support X25519 and X448 in TLS
  (P2) JDK-8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange
  (P2) JDK-8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
  (P3) JDK-8224650: Add tests to support X25519 and X448 in TLS
  (P3) JDK-8224829: AsyncSSLSocketClose.java has timing issue
  (P3) JDK-8219994: CheckSecurityProvider.java fails with unexpected sun.security.ssl.SunJSSE
  (P3) JDK-8220016: Clean up redundant RSA services in the SunJSSE provider
  (P3) JDK-8225766: Curve in certificate should not affect signature scheme when using TLSv1.3
  (P3) JDK-8219389: Delegated task created by SSLEngine throws BufferUnderflowException
  (P3) JDK-8215790: Delegated task created by SSLEngine throws java.nio.BufferUnderflowException
  (P3) JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl
  (P3) JDK-8218580: endpoint identification algorithm should be case-insensitive
  (P3) JDK-8215524: Finished message validation failure should be decrypt_error alert
  (P3) JDK-8218889: Improperly use of the Optional API
  (P3) JDK-8219723: javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases
  (P3) JDK-8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible
  (P3) JDK-8160247: Mark deprecated javax.security.cert APIs with forRemoval=true
  (P3) JDK-8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl
  (P3) JDK-8180005: Provide specific links in KeyManagerFactory and TrustManagerFactory to the Standard Algorithm Names Specification
  (P3) JDK-8217835: Remove the experimental SunJSSE FIPS compliant mode
  (P3) JDK-8215430: Remove the internal package com.sun.net.ssl 
  (P3) JDK-8211018: Session Resumption without Server-Side State
  (P3) JDK-8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed
  (P3) JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11
  (P3) JDK-8221253: TLSv1.3 may generate TLSInnerPlainText longer than 2^14+1 bytes
  (P3) JDK-8163326: Update the default enabled cipher suites preference
  (P3) JDK-8226338: Updates to Stateless Resumption
  (P3) JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE
  (P3) JDK-8168261: Use server cipher suites preference by default
  (P3) JDK-8168069: X509TrustManagerImpl causes ClassLoader leaks with unparseable extensions
  (P4) JDK-4919790: Errors in alert ssl message does not reflect the actual certificate status
  (P4) JDK-8179943: Typo in javax.net.ssl.SSLSession.removeValue(String) method documentation
  (P4) JDK-8217795: Typo in SSLSocket
  (P4) JDK-8223482: Unsupported ciphersuites may be offered by a TLS client

security-libs/javax.security:
  (P3) JDK-8200400: Allow Sasl mechanisms to be restricted
  (P3) JDK-8220256: fix headings in java.security.sasl
  (P4) JDK-6682540: Incorrect SASL DIGEST-MD5 behavior

security-libs/javax.smartcardio:
  (P3) JDK-8220258: fix headings in java.smartcardio
  (P3) JDK-8226607: Inconsistent info between pcsclite.md and MUSCLE headers 
  (P3) JDK-8218780: Update MUSCLE PCSC-Lite header files

security-libs/javax.xml.crypto:
  (P2) JDK-8217878: ENVELOPING XML signature no longer works
  (P3) JDK-8223053: [xmldsig] Add KeyValue::EC_TYPE
  (P3) JDK-8219013: Update Apache Santuario (XML Signature) to version 2.1.3
  (P3) JDK-8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10
  (P4) JDK-8224767: Add String constants for Canonical XML 1.1 URIs

security-libs/jdk.security:
  (P3) JDK-8217375: jarsigner breaks old signature with long lines in manifest
  (P3) JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output
  (P4) JDK-8228341: SignTwice.java fails intermittently on Windows

security-libs/org.ietf.jgss:
  (P2) JDK-8226719: Kerberos login to Windows 2000 failed with "Inappropriate type of checksum in message"
  (P3) JDK-8227381: GSS login fails with PREAUTH_FAILED
  (P3) JDK-8225687: Newly added sspi.cpp in JDK-6722928 still contains some small errors
  (P3) JDK-6722928: Provide a default native GSS-API library on Windows
  (P3) JDK-8225304: tiny HTML error (bad heading) in org.ietf.jgss package-info.java
  (P4) JDK-8226963: More clarification on possible sequencing error in GSSContext::unwrap

security-libs/org.ietf.jgss:krb5:
  (P2) JDK-8227437: S4U2proxy cannot continue because server's TGT cannot be found
  (P3) JDK-8227061: KDC.java test behaves incorrectly when AS-REQ contains a PAData not PA-ENC-TS-ENC
  (P4) JDK-8227305: Krb5Util::getTicketFromSubjectAndTgs is useless
  (P4) JDK-8215032: Support Kerberos cross-realm referrals (RFC 6806)

specification/language:
  (P2) JDK-8223300: 15.28: Switch Expressions (Preview)
  (P2) JDK-8225674: 3.10.6: Text Blocks (Preview)
  (P2) JDK-8222184: JEP 354: Switch Expressions (Second Preview)
  (P3) JDK-8222530: JEP 355: Text Blocks (Preview)
  (P4) JDK-8225389: 8.9.3: Simplify implicit declaration of values() and valueOf(String)

specification/vm:
  (P4) JDK-8225747: 2.0: Update the JVM's dependence on Unicode to 12.1
  (P4) JDK-8214905: 4.1: Allow v57.0 class files for Java SE 13

tools:
  (P3) JDK-8219488: jdeps man page needs to be updated
  (P3) JDK-8224982: JDK-8222318 breaks tools/doclint/html/EntitiesTest.java
  (P4) JDK-8215976: OpenJDK fails to build with GCC 8.2 when the #include<time.h> inside zip.cpp comes from a non-sysroot path
  (P4) JDK-8219561: Update jdeprscan to avoid the need for start-of-release changes

tools/jar:
  (P3) JDK-8212807: tools/jar/multiRelease/Basic.java times out
  (P4) JDK-8216539: tools/jar/modularJar/Basic.java timed out

tools/javac:
  (P2) JDK-8216263: Add historical data for JDK 12
  (P2) JDK-8223303: Compiler support for Switch Expressions
  (P2) JDK-8222169: java.lang.AssertionError switch expression in ternary operator - ?
  (P2) JDK-8227640: javac crashes on text blocks with invalid escapes.
  (P2) JDK-8226522: No compilation error reported when yield is used in incorrect context
  (P2) JDK-8226510: No compilation error when switch expression has no result expressions
  (P2) JDK-8222251: preflow visitor is not visiting lambda expressions
  (P2) JDK-8225386: test for JDK-8216261 fails in Windows
  (P3) JDK-8218152: [javac] fails and exits with no error if a bad annotation processor provided
  (P3) JDK-8222949: add condy support to javac's pool API
  (P3) JDK-8222744: add support for generating method handles from a variable symbol
  (P3) JDK-8221118: Avoid eagerly creating JCDiagnostic for CompletionFailures
  (P3) JDK-8215470: Bad EnclosingMethod attribute on classes declared in lambdas
  (P3) JDK-8224031: Cannot parse switch expressions after type cast
  (P3) JDK-8215482: check for cycles in type variables can provoke NPE
  (P3) JDK-8223967: Compiler Support for JEP 355: Text Blocks (Preview)
  (P3) JDK-8217868: Crash for overlap between source path and patch module path
  (P3) JDK-8221759: Crash when completing "java.io.File.path"
  (P3) JDK-8226412: Fix command-line help text for javac -target
  (P3) JDK-8220379: Fix doclint handling of headings
  (P3) JDK-8220249: fix headings in java.compiler
  (P3) JDK-8216529: in case of a crash, javac should print out the parameters passed to it
  (P3) JDK-8217381: Inconvenient errors reported when annotation processor generates source file and errors in the same round
  (P3) JDK-8207224: Javac compiles source code despite illegal use of unchecked conversions
  (P3) JDK-8215625: javax/sql/testng/util/xxxxx.java tests compilation failed after JDK-8207224
  (P3) JDK-8215368: Make Check.checkOverride call diagnosticPositionFor lazily
  (P3) JDK-8222035: minimal inference context optimization is forcing resolution with incomplete constraints
  (P3) JDK-8220041: NullPointerException at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0
  (P3) JDK-8222289: Overhaul logic for reading/writing constant pool entries
  (P3) JDK-8221264: Refactor and update SourceVersion.latestSupported
  (P3) JDK-8226441: Update javac man page with info about compilation modes
  (P3) JDK-8217395: Update langtools shell tests to use ${EXE_SUFFIX}
  (P3) JDK-8214825: Update preview language features for start of JDK 13
  (P4) JDK-8217335: Add a script to generate --release data
  (P4) JDK-8205394: Add source 13 and target 13 to javac
  (P4) JDK-8220687: Add StandardJavaFileManager.getJavaFileObjectsFromPaths overload
  (P4) JDK-8220644: Align required/found pairs in diagnostics
  (P4) JDK-8216403: Allocate fewer EnumSets in JavacFileManager#list
  (P4) JDK-8224161: Check.checkOverrideClashes n^2 algorithm
  (P4) JDK-8223654: Clean up @jls references in com.sun.source
  (P4) JDK-8215366: Code quality improvements in com.sun.tools.javac.code.TypeAnnotations
  (P4) JDK-8218630: CreateSymbols includes class and module headers unnecessarily.
  (P4) JDK-8224177: Harden annotation processing framework to irregular behavior from processors
  (P4) JDK-8201544: Improve javac command line parsing and error reporting
  (P4) JDK-8214345: infinite recursion while checking super class
  (P4) JDK-8220018: javac crash when compiling try-catch-finally inside switch expression
  (P4) JDK-8221413: javac does not recognize variable assigned in switch expression as DA
  (P4) JDK-8215407: javac should reject class files with bad EnclosingMethod attributes
  (P4) JDK-8223942: Missing methods in ClientCodeWrapper$WrappedJavaFileManager
  (P4) JDK-8220633: Optimize CacheFSInfo
  (P4) JDK-8220792: Performance bottleneck in JavacFileManager.list()
  (P4) JDK-8217047: Provide a way to inject missing parameter names
  (P4) JDK-8193277: SimpleFileObject inconsistency between getName and getShortName
  (P4) JDK-8220632: Suggest recompiling with a larger value of -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed
  (P4) JDK-8220634: SymLinkArchiveTest should handle not being able to create symlinks
  (P4) JDK-8224629: Unnecessary cast in LambdaToMethod
  (P4) JDK-8220377: Unused field SourceFileObject.flatname
  (P4) JDK-8220378: Unused Names constants
  (P4) JDK-8219254: Update explicit uses of latest source/target in langtools tests to a property
  (P4) JDK-8219256: Update javac diags tests to use properties
  (P4) JDK-8225532: Update source enums to describe 12 and 13 language features

tools/javadoc(tool):
  (P2) JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH
  (P2) JDK-8218944: Fix failed for JDK-8218936
  (P2) JDK-8216170: java.lang.IllegalArgumentException: directories not supported
  (P2) JDK-8219558: jdk/javadoc tests fail with missing headings: h1
  (P2) JDK-8224082: NPE in javadoc Reporter
  (P2) JDK-8217214: Recent new javadoc test needs to be updated
  (P2) JDK-8222548: Upgrading JDK 13 with the latest available jQuery 3.4.1
  (P3) JDK-8223733: "Detail" in headings should be "Details"
  (P3) JDK-8219060: -linksource broken with modules
  (P3) JDK-8218998: Add metadata to generated API documentation files
  (P3) JDK-8219958: Automatically load taglets from a jar file
  (P3) JDK-8223364: Bad placement of anchor relative to header
  (P3) JDK-8225494: broken link in specs/javadoc/doc-comment-spec.html
  (P3) JDK-8222669: Create and use new html.Entity class
  (P3) JDK-8223805: DocCommentParser should allow for <main> and </main>
  (P3) JDK-8219998: Eliminate inherently singleton lists
  (P3) JDK-8221997: fix headings in jdk.javadoc
  (P3) JDK-8220497: Improve Javadoc search feature and add test coverage
  (P3) JDK-8221991: Improve the HTML for the inheritance tree for a type
  (P3) JDK-8222318: javadoc does not accept valid HTML5 entity names
  (P3) JDK-8222091: Javadoc does not handle package annotations correctly on package-info.java
  (P3) JDK-8202626: javadoc generates broken links to <Unnamed>
  (P3) JDK-8224083: javadoc Reporter generates warning for Kind.NOTE
  (P3) JDK-8178982: Javadoc search specification
  (P3) JDK-8219147: Javadoc should expose covariant return type overrides
  (P3) JDK-8214738: javadoc should honor styles in doc-files
  (P3) JDK-8221871: javadoc should not set role=region on <section> elements
  (P3) JDK-8217034: JavadocTester should check for missing files by default
  (P3) JDK-8219575: jdk/javadoc/tool/removeOldDoclet/RemoveOldDoclet test fails in mach5
  (P3) JDK-8221644: jquery directory should be renamed
  (P3) JDK-8214126: Method signatures not formatted correctly in browser
  (P3) JDK-8219691: method summary table head should be enclosed in <thead>
  (P3) JDK-8199892: Missing landmarks when generating docs using html sources
  (P3) JDK-8215516: Move JavadocTester to a named package
  (P3) JDK-8215307: Pages do not have <h1>
  (P3) JDK-8216319: Refactor JavadocTester to allow more on-by-default checkers; add A11YChecker
  (P3) JDK-8196720: Remove --no-module-directories option
  (P3) JDK-8215577: Remove javadoc support for HTML 4.
  (P3) JDK-8215608: Remove old javadoc features
  (P3) JDK-8219632: Remove reference to com.sun.javadoc API in RemoveOldDoclet test
  (P3) JDK-8220087: Remove remnants of HTML4 support
  (P3) JDK-8215580: Remove support for `--no-module-directories`
  (P3) JDK-8215599: Remove support for javadoc "frames" mode
  (P3) JDK-8215584: Remove support for the "old" doclet API in com/sun/javadoc
  (P3) JDK-8225321: Repeated use of {@systemProperty} in a file causes duplicate ids
  (P3) JDK-8221709: replace use of style blockListLast
  (P3) JDK-8221366: Search box tries to search for "Search"
  (P3) JDK-8219946: Set class on body elements
  (P3) JDK-8220202: Simplify/standardize method naming for HtmlTree
  (P3) JDK-8225671: Support HTML 5 character references in javadoc
  (P3) JDK-8219313: Support module specific stylesheets
  (P3) JDK-8213354: Support package-specific stylesheets
  (P3) JDK-8218936: Test fails in Internet environment
  (P3) JDK-8217773: Test langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java fails after JDK-8217034
  (P3) JDK-8219497: Unused parameter in HtmlDocletWriter::printHtmlDocument
  (P3) JDK-8222526: Use of no longer existing jquery directory in script.js
  (P4) JDK-8220382: Cleanup doclet instantiation
  (P4) JDK-8217871: Incorrect parameters in Javadoc documentation
  (P4) JDK-8171292: Javadoc Search does not support searching for more than one param in method or constructor
  (P4) JDK-8222395: Refactor the abstract classes of package and module index writer
  (P4) JDK-8219733: Restore javadoc header styles

tools/javap:
  (P3) JDK-8184226: Javap -help should provide information about --multi-release option
  (P3) JDK-8225748: Use SHA-256 for javap classfile checksum
  (P4) JDK-8216261: Javap ignores default modifier on interfaces

tools/jlink:
  (P3) JDK-8216553: JrtFIleSystemProvider getPath(URI) omits /modules element from file path
  (P3) JDK-8224946: jrtfs URI to Path and Path to URI conversions are wrong
  (P3) JDK-8224908: Revert: 8216553: JrtFileSystemProvider getPath(URI) omits /modules element from file path
  (P4) JDK-8214796: Create a jlink plugin for stripping debug info symbols from native libraries
  (P4) JDK-8217877: Dead code in jdk.jlink's TaskHelper
  (P4) JDK-8219142: Remove unused JIMAGE_ResourcePath
  (P4) JDK-8218913: Rename --strip-debug jlink plugin

tools/jpackage:
  (P3) JDK-8201202: JEP-JDK-8200758: Test Plan for JEP 343: Packaging Tool (Incubator)

tools/jshell:
  (P2) JDK-8200701: jdk/jshell/ExceptionsTest.java fails on Windows, after JDK-8198801
  (P3) JDK-8225151: JShell API: Fix position of @jls tag
  (P3) JDK-8224184: jshell got IOException at exiting with AIX
  (P3) JDK-8223782: jshell parser should handle Text Blocks
  (P3) JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows
  (P3) JDK-8199623: JShell: corralling not restored on drop
  (P3) JDK-8223688: JShell: crash on the instantiation of raw anonymous class
  (P4) JDK-8223595: Consider updating jdk.jshell module description
  (P4) JDK-8212167: JShell : Stack trace of exception has wrong line number
  (P4) JDK-8080353: JShell: Better error message on attempting to add default method
  (P5) JDK-8159740: JShell: corralled declarations do not have correct source to wrapper mapping

tools/launcher:
  (P3) JDK-8217044: [aix] Launcher still adds old path to jli library to LIBPATH
  (P3) JDK-8217340: Compilation failed: tools/launcher/Test7029048.java
  (P3) JDK-8221368: Error message when module main class cannot be loaded is missing exception details
  (P3) JDK-8222334: java -Xss0 triggers StackOverflowError
  (P3) JDK-8217093: Support extended-length paths in parse_manifest.c on Windows
  (P4) JDK-8223804: [macos] remove obsoleted reference to security framework in launcher code
  (P4) JDK-8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted
  (P4) JDK-8215156: Deprecate the -Xfuture option
  (P4) JDK-8215009: GCC 8 compilation error in libjli
  (P4) JDK-8227055: Minor edits to launcher help text
  (P4) JDK-8218547: Simplify JLI_Open on Windows in native code (libjli)
  (P4) JDK-8218997: Xusage text, man help, etc doesn't mention -Xlog option.
  (P5) JDK-8217216: Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris)

xml/javax.xml.parsers:
  (P3) JDK-8220254: fix headings in java.xml
  (P4) JDK-8206132: DOM parser does not honor DocumentBuilderFactory.setExpandEntityReferences(false)

xml/javax.xml.stream:
  (P3) JDK-8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

xml/javax.xml.transform:
  (P4) JDK-8180901: Transformer.reset() resets the state only once

xml/javax.xml.validation:
  (P3) JDK-8220818: Validator does not find missing match for keyref error

xml/jaxp:
  (P2) JDK-8219705: Wrong media-type for a given serialization method
  (P3) JDK-8219692: DOM and SAX parsers ignore namespace
  (P3) JDK-8215330: javax.xml.catalog.CatalogResolverImpl: GroupEntry.matchURI fails to match
  (P3) JDK-8223658: Performance regression of XML.validation in 13-b19
  (P4) JDK-8187697: Cleanup: irrelevant code in OutputPropertiesFactory
  (P4) JDK-8223052: Cleanup: NodeSortRecord
  (P4) JDK-8186321: Cleanup: SourceTreeManager not used
  (P4) JDK-8214064: Upgrade Xerces to Version 2.12.0
  (P4) JDK-8222743: Xerces 2.12.0: DOM Implementation
  (P4) JDK-8225005: Xerces 2.12.0: License file
  (P4) JDK-8222415: Xerces 2.12.0: Parsing Configuration
  (P4) JDK-8222991: Xerces 2.12.0: Validation