RELEASE NOTES FOR: 13 ==================================================================================================== Notes generated: Thu Jul 01 06:28:53 CEST 2021 JIRA Query: project = JDK AND (status in (Closed, Resolved)) AND (resolution not in ("Won't Fix", Duplicate, "Cannot Reproduce", "Not an Issue", Withdrawn)) AND (labels not in (release-note, testbug, openjdk-na, testbug) OR labels is EMPTY) AND (summary !~ 'testbug') AND (summary !~ 'problemlist') AND (summary !~ 'problem list') AND (summary !~ 'release note') AND (issuetype != CSR) AND fixVersion = 13 Acquiring pages (2210 total): ............................................. done Loading issues (2210 total): ............................................. done Resolving issues (2210 total): ............................................ done Resolving parents (2210 total): ............................................ done Resolving backports (2210 total): ............................................ done JIRA Query: project = JDK AND issuetype = JEP AND fixVersion = 13 ORDER BY summary ASC Acquiring pages (5 total): . done Loading issues (5 total): . done Resolving issues (5 total): done Resolving parents (5 total): done Filtered 192 issues carried over, 2002 pushes left. 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: 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. 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. 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-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-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-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-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-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-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. 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. core-libs/java.lang: 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-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-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-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. 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. 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-8226643: Change to Default Implementation of SocketImpl Methods supportedOptions, getOption, and setOption The default implementation of the `supportedOptions()`, `getOption(SocketOption)` and `setOption(SocketOption, 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)` and `setOption(SocketOption, 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-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. core-libs/java.nio: 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<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)` - `newFileSystem(Path, Map, ClassLoader)` The addition of `newFileSystem(Path, Map)` 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. 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). 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. 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`. 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. 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. 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 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. hotspot/gc: JDK-8222487: Added -XX:SoftMaxHeapSize Flag The manageable command-line flag `-XX:SoftMaxHeapSize=` 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 ` 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-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-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-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-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-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=` (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-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-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-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-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-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-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-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-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-8222920: ZGC: Maximum Heap Size Increased to 16TB The maximum supported heap size for ZGC was increased from 4TB to 16TB. hotspot/runtime: 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-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=: ``` [CSR JDK-8221706](https://bugs.openjdk.java.net/browse/JDK-8221706) has more details on the command line option. 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. security-libs/java.security: 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-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-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-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-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 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()`. security-libs/javax.crypto:pkcs11: 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. security-libs/javax.net.ssl: 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-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-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-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-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-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-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.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. security-libs/javax.xml.crypto: 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-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 " " or " ". 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 " " or " " 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-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 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. 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. specification/language: 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 = "\n" + " \n" + "

Hello, world

\n" + " \n" + "\n"; ``` _Using a "two-dimensional" block of text_ ``` String html = """

Hello, world

"""; ``` ### 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 = """ .............. .............. ..............

Hello, world

.............. .............. .............."""; ``` 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 = """ ................. .............. ..............

Hello, world

.... .............. . ................. .............."""; ``` 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: ``` || | | |

Hello, world

| | | || ``` 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 `\` 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 = """

Hello, world

"""; ``` 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) ``` | | |

Hello, world

| | ``` 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 = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ ........ ........ ........

Hello, world

........ ........ ........"""; ``` 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: ``` | | |

Hello, world

| | ``` Finally, suppose the closing delimiter is moved slightly to the _right_ of the content: ``` String html = """

Hello, world

"""; ``` The spaces visualized with dots are considered to be incidental: ``` String html = """ .............. .............. ..............

Hello, world

.............. .............. .............. """; ``` 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: ``` | | |

Hello, world

| | ``` #### 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 = """ \r \r

Hello, world

\r \r \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: ``` |\u000D\u000A | \u000D\u000A |

Hello, world

\u000D\u000A | \u000D\u000A |\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 `\` 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 `\` 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 `\` 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. 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. 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. 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. 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. 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); ``` 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(); 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-8080569: java/lang/ProcessBuilder/DestroyTest.java fails with "RuntimeException: Process terminated prematurely" (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-8217882: java/net/httpclient/MaxStreams.java failed once (P4) JDK-8217903: java/net/httpclient/Response204.java fails with 404 (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 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) 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

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: (P3) JDK-8223311: Update use of "-Djava.security.debug=help" option (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-.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 _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_.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-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher (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