Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what are the new functions of JDK 16:Java 16". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Earlier versions of JDK 16 for Linux,Windows and MacOS can be found on jdk.java.net. Like JDK 15, JDK 16 will be a short version that will last for six months. JDK 17, which will be released in September 2021, will be a long-term support (LTS) version that will be supported for several years. The current LTS version, JDK 11, was released in September 2018.

JDK 16 will be implemented as a reference for the standard Java version and will arrive in March next year.

As of October 8th, eight proposals were officially targeted at JDK16. New features of Java16 include:

Migrate ZGC (Z garbage Collector) thread stack processing from the safe point safepoints to the concurrency phase. The goals of the plan include removing thread stack processing from the ZGC security point. Make stack processing lazy, collaborative, concurrent, and incremental; remove all other per-thread root processing from ZGC security points; and provide a mechanism for other HotSpot VM subsystems to delay stack processing. In this way, ZGC makes the GC pause and scalability issues in HotSpot a thing of the past. So far, GC operations that expand with heap size and metaspace size have been removed from safe point operations and entered the concurrency phase. These include markup, relocation, reference processing, class unloading, and most root processing. The only activity still taking place in the GC security point is a subset of root processing and time-bound tag termination operations. These roots include the Java thread stack and other thread roots, which are problematic because they expand as the number of threads grows. To go beyond the current situation, per-thread processing, including stack scanning, must be moved to the concurrency phase. With this plan, the throughput cost of the improved latency should be negligible and the time spent in the ZGC security point on a typical computer should be less than one millisecond.

Flexible meta-space capability, which can return unused HotSpot VM-like metadata (meta-space) memory to the operating system more quickly, thus reducing meta-space footprint and simplifying meta-space code, thereby reducing maintenance costs. There are a lot of out-of-heap memory usage problems in metaspace. The plan requires replacing the existing memory allocator with a partner-based allocation scheme and provides an algorithm for dividing memory into multiple partitions to meet memory requests. This approach, which has been used in places such as the Linux kernel, will make it feasible to allocate memory in smaller blocks to reduce the overhead of the classloader. Debris will also be reduced. In addition, memory commitments from operating systems to memory management will be delayed as needed, reducing the footprint of loaders that start on a large stage but do not use them immediately or may not fully use them. In order to make full use of the flexibility provided by partner allocation, meta-space memory is arranged into uniform particles, which can be submitted or not committed independently of each other.

Enables C + + 14 language features to allow the use of C + + 14 features in JDK C + + source code and provides specific guidance on which features can be used in HotSpot VM code. The language functions used by the C + + code in the JDK 15 JDK have been limited to the C + + 98 and03 language standard. With JDK 11, the source code has been updated to support builds using newer versions of the C + standard. This includes the ability to build with the latest version of the compiler that supports the C + + 11 + 14 language features. This proposal does not recommend changes to the style or usage of C + + code used outside HotSpot. But to take advantage of the C + language features, you need to make some build-time changes, depending on the platform compiler.

The vector API of the incubator phase, in which JDK will be equipped with an incubator module, jdk.incubator.vector, to express vector computing that can be compiled into optimal vector hardware instructions on the supported CPU architecture to achieve better performance than equivalent scalar computing. Vector API provides a mechanism for writing complex vector algorithms using Java, which uses pre-existing support in HotSpot VM for vectorization, but its user model makes vectorization more predictable and reliable. The goals of the proposal include providing a clear and concise API to express a range of vector computing, supporting a variety of CPU architectures independent of the platform, and providing reliable runtime compilation and performance on x64 and AArch74 architectures. Elegant demotion is also a goal.

Migrate JDK to Windows / AArch74 platform. With the release of new server and consumer AArch74 (ARM64) hardware, Windows / AArch74 has become an important platform due to demand. Although the migration itself is almost complete, the focus of this recommendation is to integrate the ports into the mainline JDK repository.

On x64 and AArch74 architectures, migrate JDK to Alpine Linux and other Linux distributions that use musl as their primary C library. Musl is the Linux implementation of the standard library function described in ISO C and Posix standards. Because of its small image, Alpine Linux has been widely used in cloud deployments, microservices, and container environments. The Docker image of Linux is smaller than 6MB. Letting Java run out of the box in such a setting would allow Tomcat,Jetty,Spring and other popular frameworks to run natively in these environments. By using jlink to reduce the size of the Java runtime, users can create even smaller images that are customized to run specific applications.

The OpenJDK source code base is migrated from Mercurial to Git. This effort is driven by the size of the version control system metadata and the advantages of available tools and hosting.

The migration to GitHub is related to the migration from Mercurial to Git, and the JDK 16 source code repository is located on the popular code sharing site. The transition of Mercurial JDK and JDK-sandbox to Git,GitHub and Skara was completed on 5 September and contributions are now open.

That's all for "what are the new features of JDK 16:Java 16?" Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.