JEP 189 ["Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)"] is described as "a new garbage collection (GC) algorithm ... [that] reduces GC pause times by doing evacuation work concurrently with the running Java threads." The JEP text adds, "Shenandoah is an appropriate algorithm for applications which value responsiveness and predictable short pauses."
JEP 334 ["JVM Constants API"]'s "Summary" states that this JEP's goal is to "Introduce an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool." This JEP is also proposed for Java SE 12.
JEP 346 ["Promptly Return Unused Committed Memory from G1"] is another JEP related to the G1 garbage collector and it aims to "enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle."
The thread "Call For Discussion: New Project: Atlantis" on the OpenJDK discuss mailing list discusses JC Beyler's proposal of an OpenJDK project called "Project Atlantis" that "would provide a venue to explore and incubate monitoring and performance analysis features that could be integrated into the Hotspot JVM and the JVM Tool Interface." This proposed project would include "working, evaluating, and incubating a Thread-Sanitizer implementation for Java."
Beyler's proposal provides background for this proposed project based on work done at Google:
The Google platform team has historically worked on providing new features, including monitoring hooks due to certain monitoring features not being available in a low-overhead, turned on-by-default manner. Therefore, for Google Java users, the platform team augmented or added mechanisms to assess various metrics such as but not limited to:
Thread Sanitizer support for Java (see JDK-8208520) (though this one specifically is not a low-overhead one, sorry ;-))
Lock contention profiles to better understand where threads are spending time in locks
Heap dumping mechanisms to improve heap dump times for large heaps
Efficient thread tagging to help filter profiling
etc.
All of the above have added changes to the JDK in various forms and the Atlantis project proposes to investigate, in the open, how these changes
could be made general enough to be pushed into the mainline, or should be dropped due to being too specific or could be done using other existing
mechanisms.
That same proposal message is not much longer than the quotation above, but does add some details regarding "evaluation criteria" that would be used to determine which investigated features and improvements warranted a JEP for eventual integration into the JDK baseline.
The responses to the Project Atlantis proposal have generally been enthusiastic with a few key discussion points related to expressed concerns:
Fragmentation of tools related to performance monitoring and analysis.
... this project is an attempt to have a venue to create conversations about current internal systems or non-existent ones and that we can see what "sticks" and what doesn't; where it would "stick" potentially, what it would like and then how could be best push it forward with the support of the whole community.
There are several aspects of this proposal that intrigue me. Perhaps the most immediately relevant for me would be anything that could be done to make it easier to analyze large heap dumps. Jonathan Lu has interest in similar capability and writes, "I'm especially interested in the heap dumping part.
It costs a lot to create, transfer, and analyze huge heap dump files for my applications."
Based on the initial proposal and discussion, it seems to me that Project Atlantis could be of great benefit to users of OpenJDK (and likely the numerous JDKs that will be based on OpenJDK).
JDK-8202302 ["(fs) New Files.mismatch method for comparing files"] adds the Files.mismatch(Path,Path) method "to compare the contents of two files to determine whether there is a mismatch between them" and can be used to determine "whether two files are equal." There was talk at one time of adding a Files.isSameContent() method, but it was decided to use Files.mismatch(Path,Parh) because of its consistency "with the Arrays.mismatch and Buffer.mismatch methods."
The next code listing contains a simple Java class that demonstrates the new Files.mismatch(Path,Path) and contrasts it with Files.isSameFile(Path,Path). The full source code is available on GitHub.
package dustin.examples.jdk12.files;
import java.nio.file.Files;
import java.nio.file.Path;
import static java.lang.System.out;
/**
* Demonstrate {@code Files.mismatch(Path,Path)} introduced with JDK 12
* and useful for determining if two files have the same content even
* if they're not the same files.
*/
public class FilesDemo
{
public static void main(final String[] arguments) throws Exception
{
if (arguments.length < 2)
{
out.println("USAGE: FilesDemo <file1Name> <file2Name>");
return;
}
final String file1Name = arguments[0];
final Path file1Path = Path.of(file1Name);
final String file2Name = arguments[1];
final Path file2Path = Path.of(file2Name);
out.println("\nFiles '" + file1Name + "' and '" + file2Name + "' are "
+ (Files.isSameFile(file1Path, file2Path) ? "the" : "NOT the")
+ " same.\n\n");
out.println("\nFiles '" + file1Name + "' and '" + file2Name + "' are "
+ (Files.mismatch(file1Path, file2Path) == -1 ? "the" : "NOT the")
+ " same content.\n\n");
}
}
When the above code is executed against various combinations of files, it provides results that are captured in the next table. Note that the Files.mismatch method does not itself return a boolean, but the code shown above adapts its response to the appropriate boolean.
Results of Code Snippet Using Files.isSameFile() and Files.mismatch()
The addition of Files.mismatch(Path,Path) is another step in accomplishing JDK-6852033
["Inputs/Outputs methods to make common I/O tasks easy to do"] and makes it easier to determine when two files that are not the same file are still "equal" or have the same content.
The {@systemPropery} Javadoc tag displays its contents as normal text in its generated output and makes the contents available to the Javadoc search introduced with JDK 9. This tag is intended to be used for documenting an application's system properties.
The following simple class will be used to demonstrate the new JDK 12 Javadoc tag {@systemProperty}:
The above code example applies {@systemProperty} to the private attribute PROPERTY_NAME. Because the field if private, the Javadoc tool must be executed with the -private flag to have documentation generated for this field.
The next screen snapshot demonstrates the documentation generated for the simple class using the javadoc command-line tool included in JDK 12 Early Access Build 12 (which did not have support for {@systemProperty}).
The red ovals in the previous screen snapshot show that the {@systemProperty} tag is not handled properly in earlier versions of the JDK. The contents of that tag are NOT displayed and the "search" functionality does not match on the system property name.
The next screen snapshot demonstrates the documentation generated for this same class using the command-line javadoc that comes with JDK 12 Early Access Build 20.
The green ovals in the previous screen snapshot show that {@systemProperty} is better supported in Early Access Build 20 of OpenJDK JDK 12. The contents of that tag are correctly displayed in the Javadoc itself and the search capability now matches on the system property name. It is also worth noting that the text within {@systemProperty} is presented in the HTML with appearance similar to which {@code} is presented.
The addition of {@systemProperty} potentially makes it easier for developers to find relevant descriptions of system properties for an application among Javadoc-generated documentation. The aforementioned post "FYI: new javadoc tag to document system properties" discusses other Javadoc enhancements that could possibly be made to take advantage of this tag. The potential enhancements include "a 'summary page' that lists all the system properties", adding "information regarding the 'scope' of the definition", and allowing "a short description to be included in the {@systemProperty} tag" that "could be included in the search index, the A-Z index, and the summary page."
The Jonathan Gibbons FYI mailing list message that introduces {@systemProperty} also spells out its recommended usage:
Where should the tag be used? The tag should be used in the text of the defining instance of the property. This is where the characteristics of the system property are described, which may include information like: "what is the property for", "how and when is it set", "can it be modified", and so on.
The addition of {@systemProperty} to the Javadoc tool with JDK 12 Early Access Build 20 is a minor thing, but will allow developers to make documentation of important system properties more readily accessible for fellow developers.
Today's "What's New with AWS" post "Introducing Amazon Corretto (Preview)" announces Amazon Corretto as "a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK)." Amazon Corretto's main page describes what it has to offer: "Corretto comes with long-term support that will include performance enhancements and security fixes." This is significant because it advertises that Amazon will provide performance enhancements and security fixes to its JDK offerings past the 6 months for which Oracle has committed to making performance enhancements and security fixes to each new OpenJDK version.
The first version of Amazon Corretto is currently a preview version and is called Amazon Corretto 8 (which, of course, associates it with OpenJDK 8). The "List of Patches for Amazon Corretto 8 Preview" lists "the patches applied to OpenJDK for the Amazon Corretto 8 Preview." These currently include patches related to OpenJDK issues (including backports from OpenJDK 11) such as JDK-8187123 ["(reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue"] and JDK-8213198 ["Not triggering mixed GCs in G1 leaves string table cleanup deferred"].
The Amazon Corretto FAQs presents the question, "What is included in Corretto's long-term support?" The answers to this question communicate that Amazon plans to "provide security updates for Corretto 8 until at least June 2023" and to "support Corretto 11 with quarterly updates until at least August 2024." That same answer tells us that plans are to release Amazon Corretto 11 in the first half of 2019. Current updates for both Amazon Corretto 8 and for Amazon Corretto 11 are planned to be made quarterly until at least their advertised ending month of support (June 2023 for Corretto 8 and August 2024 for Corretto 11).
There has been a lot of miscommunication recently about the required cost of purchasing Java in the future. Amazon Corretto is another supporte JDK distribution that will be free of cost. The Amazon Corretto FAQs feature the question, "Is there any cost associated with using Corretto?" The answers associated with that question are:
Corretto is distributed by Amazon under an Open Source license at no cost to you. It is licensed under the terms of the GNU Public License version 2 with the Class Path Exception (GPLv2 with CPE). Amazon does not charge for its use or distribution.
I highly recommend the Amazon Corretto FAQs to anyone potentially interested in adopting Amazon Corretto. In addition to providing answers about likely questions related to long-term support, licenses, and costs, these FAQs also explain the types of patches Amazon intends to make to OpenJDK distributions, explain the degree of drop-in replaceability of other OpenJDK-based distributions by Amazon Corretto, list the operating systems supported for running Amazon Corretto, and explain how Amazon Corretto can be used with or without use of Amazon Web Services (AWS).
Conclusion
These has been continuing confusion surrounding whether Java is still free or not. Amazon Corretto is another example of an OpenJDK-based JDK binary available free of cost with long-term support advertised.
