Prompt: Make a research for which JDK Enhancement Proposals, known as JEPs, try to improve the CPU and memory usage of Java applications.

I. Introduction: The Significance of Resource Efficiency in Java Development and the Role of JEPs

In the realm of modern software development, the efficient utilization of computational resources, particularly CPU and memory, stands as a cornerstone of application performance, scalability, and cost-effectiveness. Java applications, widely deployed across diverse environments ranging from enterprise servers to embedded systems and cloud-native architectures, are particularly sensitive to resource consumption. Inefficient resource usage can manifest in various detrimental ways, including elevated operational expenditures due to increased infrastructure demands, diminished application responsiveness leading to poor user experiences, and limitations in the ability of applications to scale effectively under high load. Addressing these challenges necessitates a continuous focus on optimizing how Java applications consume and manage CPU cycles and memory.

The Java Development Kit (JDK) Enhancement Proposal (JEP) process serves as the primary and structured pathway for introducing significant improvements and innovations to the Java platform and its associated ecosystem.1 These proposals, which are meticulously documented and reviewed by the Java community, cover a broad spectrum of potential enhancements, encompassing new language features designed to improve developer productivity, Application Programming Interface (API) extensions aimed at providing richer functionality, and crucial modifications to the underlying Java Virtual Machine (JVM) that are often geared towards bolstering performance and resource management.3 Within this landscape of ongoing development, numerous JEPs have been specifically conceived and implemented with the explicit goal of enhancing the CPU and memory efficiency of Java applications. This report undertakes a focused analysis of these key JEPs, drawing upon provided research materials to elucidate the proposed mechanisms, objectives, and potential impacts of these enhancements on the Java platform.

II. Methodology: Approach to Identifying and Analyzing Performance-Enhancing JEPs

To effectively address the user's query regarding JDK Enhancement Proposals that aim to improve the CPU and memory usage of Java applications, a systematic approach was employed, mirroring the steps outlined in the initial request. The investigation commenced with the acquisition of a comprehensive list of JEPs by examining the provided research snippets.1 Notably, snippet 4 presented a particularly detailed and categorized list of JEPs, offering a valuable foundation for this analysis.

Following the initial list acquisition, a keyword-based filtering process was conducted. This involved scrutinizing the titles and brief descriptions of the JEPs for the presence of terms directly related to the user's interest, such as "performance," "CPU," "memory," "optimization," "resource usage," and "efficiency," alongside other semantically similar terms. This filtering stage served to narrow down the extensive list to a more manageable set of potentially relevant proposals that explicitly indicated an intention to improve resource utilization.

For each JEP identified through the filtering process, the subsequent step involved retrieving more detailed descriptions and objectives. This was accomplished by systematically searching the provided research snippets for mentions of these specific JEP numbers. Snippets from 10 onwards proved particularly useful in this stage, often containing more in-depth information, especially for JEPs associated with recent JDK releases.

With the detailed descriptions in hand, a careful analysis was performed to ascertain whether each JEP explicitly mentioned improvements to CPU and/or memory usage. The focus on explicit mentions was a deliberate choice to ensure the report's accuracy and direct relevance to the user's query. This stage involved a thorough reading of the objectives, descriptions, and motivations outlined in the JEP documentation and associated articles.

Finally, the JEPs that explicitly targeted CPU improvements, memory improvements, or both were compiled into categorized lists. For each JEP in these lists, a summary of the key changes proposed and the underlying mechanisms intended to achieve these improvements was developed, drawing directly from the analyzed research materials.

III. JDK Enhancement Proposals Targeting CPU Usage

The analysis of the provided research material revealed several JDK Enhancement Proposals that primarily focus on improving the CPU usage of Java applications. These JEPs span various aspects of the JVM and core libraries, reflecting a multifaceted approach to enhancing performance.

JEP 509: JFR CPU-Time Profiling (Experimental) 10 introduces an experimental feature to the JDK Flight Recorder (JFR) specifically designed to capture CPU-time profiling information on Linux operating systems. The primary goal of this JEP is to empower developers with the ability to precisely measure the CPU cycles consumed by specific elements within their Java programs.14 This capability is crucial for identifying performance bottlenecks and pinpointing areas where CPU optimization efforts would be most effective. As highlighted in 14, without such profiling data, developers might inadvertently focus on optimizing program elements that have a negligible impact on overall performance, leading to wasted effort. By providing detailed insights into CPU consumption at a granular level, JEP 509 enables developers to make data-driven decisions regarding performance tuning and CPU efficiency.

JEP 475: Late Barrier Expansion for G1 15 aims to simplify the implementation of the G1 garbage collector's barriers, which are responsible for recording information about application memory accesses. This simplification is achieved by shifting the expansion of these barriers from an early stage to a later point in the C2 JIT (Just-In-Time) compilation pipeline.18 The primary goals of this JEP, as outlined in 18, include reducing the execution time of the C2 compiler when the G1 garbage collector is in use and enhancing the comprehensibility of G1 barriers for HotSpot developers. Furthermore, preliminary experiments have indicated that a naive implementation of late barrier expansion can already achieve code quality that is comparable to code optimized by C2 using the earlier expansion strategy.18 This enhancement directly contributes to CPU efficiency by reducing the overhead associated with the C2 compilation process itself, thereby decreasing the time and CPU resources required for application startup and warm-up phases.16 The JEP also strives to ensure that the C2 compiler preserves critical invariants regarding the relative ordering of memory accesses, safepoints, and barriers.18

JEP 423: Region Pinning for G1 5 addresses the challenge of reducing latency in Java applications that interact with unmanaged code through the Java Native Interface (JNI). Traditionally, the default garbage collector, G1, would entirely disable garbage collection during JNI critical regions to prevent the movement of critical objects. This approach could lead to significant latency issues, including thread stalling. JEP 423 introduces the concept of region pinning, allowing G1 to pin specific memory regions containing critical objects during garbage collection operations.23 By preventing the evacuation of these pinned regions, the JEP eliminates the need to disable garbage collection during JNI critical regions, thus reducing thread stalling, minimizing additional latency to start garbage collection, and avoiding regressions in GC pause times.22 This enhancement directly improves CPU responsiveness and overall application performance in scenarios involving frequent JNI interactions.

JEP 416: Reimplement Core Reflection with Method Handles 7 proposes a significant internal change to the Java platform by reimplementing the core reflection mechanisms (java.lang.reflect.Method, Constructor, and Field) on top of java.lang.invoke method handles.28 The primary motivation behind this JEP is to reduce the maintenance and development costs associated with both the reflection and method handle APIs.27 The new implementation performs direct invocations of method handles for specific reflective objects.27 Notably, microbenchmarks have demonstrated that when Method, Constructor, and Field instances are held in static final fields, the performance of the new implementation is significantly faster compared to the old implementation.28 While some performance degradation might be observed in microbenchmarks when these instances are held in non-constant fields, real-world benchmarks using established libraries have not shown significant performance regressions.27 This reimplementation not only streamlines the internal workings of reflection but also reduces the cost of upgrading reflection support for new language features and simplifies the HotSpot VM by removing the special treatment of MagicAccessorImpl subclasses.27

JEP 376: ZGC: Concurrent Thread-Stack Processing 30 addresses the challenge of minimizing garbage collection pauses in the Z Garbage Collector (ZGC). The JEP proposes to move the processing of thread stacks from safepoints to a concurrent phase.30 The goals of this enhancement include making stack processing lazy, cooperative, concurrent, and incremental, as well as removing all other per-thread root processing from ZGC safepoints.30 By achieving these goals, the JEP aims to ensure that the time spent inside GC safepoints does not exceed one millisecond, even on systems with large memory configurations.30 The implementation introduces a stack watermark barrier, which facilitates the concurrent processing of thread stacks.30 This change allows the ZGC to process all roots in the JVM concurrently, rather than relying on stop-the-world pauses, thereby significantly reducing the duration of GC pauses and improving overall CPU utilization by allowing application threads to execute more continuously.31

JEP 346: Promptly Return Unused Committed Memory from G1 33 focuses on enhancing the G1 garbage collector's ability to manage memory resources more efficiently. The JEP proposes that G1 should automatically return unused Java heap memory to the operating system when the application is idle.34 This behavior is particularly beneficial in containerized environments where resource consumption directly translates to operational costs.34 During periods of application inactivity, G1 will periodically assess the Java heap usage and, if appropriate, initiate a process to uncommit unused portions of the heap, returning this memory to the underlying operating system.34 This feature can be controlled through various options, including the G1PeriodicGCInvokesConcurrent option, which determines the type of periodic garbage collection to be performed.34 While the primary focus of this JEP is on memory management, the ability to dynamically adjust the JVM's memory footprint based on application activity can indirectly contribute to better CPU utilization by reducing the overhead associated with managing a larger-than-necessary heap.

JEP 307: Parallel Full GC for G1 39 addresses the worst-case latency scenarios that can occur with the G1 garbage collector. While G1 is designed to largely avoid full garbage collections, they can still occur when concurrent collections are unable to reclaim memory quickly enough. The original implementation of the full GC in G1 utilized a single-threaded mark-sweep-compact algorithm. JEP 307 proposes to improve G1's worst-case latencies by making this full GC phase parallel.41 By parallelizing the mark-sweep-compact algorithm and utilizing the same number of threads as the young and mixed collections (controlled by the -XX:ParallelGCThreads option), this enhancement aims to significantly reduce the duration of full GC pauses, leading to improved CPU responsiveness and overall application performance under heavy memory pressure.40

JEP 246: Leverage CPU Instructions for GHASH and RSA 43 targets the performance of specific cryptographic operations that are frequently used in Java applications, particularly in secure communication protocols like TLS. The JEP proposes to improve the performance of GHASH (used in the GCM cipher mode) and RSA cryptographic operations by leveraging recently introduced CPU instructions available on SPARC and Intel x64 architectures.43 By utilizing hardware-level acceleration for these computationally intensive tasks, the JEP aims to significantly improve the speed and efficiency of cryptographic operations within the JVM, leading to reduced CPU utilization and faster execution of secure applications.

JEP 143: Improve Contended Locking 3 focuses on optimizing the performance of contended Java object monitors, which are fundamental for thread synchronization in Java. The JEP explores various areas for improvement, including field reordering, cache line alignment, and the speed of monitor enter, exit, and notification operations.47 The goal is to enhance the overall performance of contended monitors, which can become a bottleneck in highly concurrent applications, leading to better CPU utilization by reducing the overhead associated with thread synchronization.48

JEP Number

Title

JDK Release Status

Key CPU Improvement Mechanisms

509

JFR CPU-Time Profiling (Experimental)

Candidate

Enhances JDK Flight Recorder to capture CPU-time profiling information on Linux, enabling better performance analysis.

475

Late Barrier Expansion for G1

24

Simplifies G1 GC barriers by shifting expansion to later in the JIT pipeline, reducing overhead and improving code efficiency.

423

Region Pinning for G1

22

Allows G1 GC to pin memory regions during JNI critical regions, avoiding the need to disable GC and reducing thread stalling.

416

Reimplement Core Reflection with Method Handles

18

Replaces bytecode generation for reflection with method handles, potentially improving performance for reflective operations.

376

ZGC: Concurrent Thread-Stack Processing

16

Moves ZGC thread-stack processing to a concurrent phase, significantly reducing stop-the-world pause times.

346

Promptly Return Unused Committed Memory from G1

12

Enhances G1 to automatically return unused heap memory to the OS, indirectly improving CPU usage by managing a more appropriately sized heap.

307

Parallel Full GC for G1

10

Parallelizes the full garbage collection phase in G1, reducing the duration of the longest GC pauses.

246

Leverage CPU Instructions for GHASH and RSA

9

Improves the performance of GHASH and RSA cryptographic operations by utilizing specific CPU instructions.

143

Improve Contended Locking

9

Optimizes the performance of contended Java object monitors, reducing synchronization overhead in multithreaded applications.

IV. JDK Enhancement Proposals Targeting Memory Usage

Several JEPs have been specifically designed to improve the memory usage characteristics of Java applications. These proposals address various aspects of memory management within the JVM and the core libraries.

JEP 450: Compact Object Headers (Experimental) 51 introduces an experimental feature aimed at reducing the size of object headers in the HotSpot JVM. On 64-bit architectures, object headers, which contain metadata about objects, can occupy a significant amount of memory (between 96 and 128 bits). This JEP proposes to reduce this size down to 64 bits.53 This reduction is achieved by compacting the mark word and the class pointer into a single 64-bit header.58 By decreasing the size of each object header from 12 bytes to 8 bytes 51, this feature aims to reduce the overall heap size required by Java applications, improve deployment density by allowing more applications to run within the same memory footprint, and potentially increase data locality, leading to better performance due to improved CPU cache utilization.51 This JEP is inspired by Project Lilliput, which has a broader goal of reducing the memory footprint of the JVM.55 As it is an experimental feature in JDK 24, it must be explicitly enabled using specific JVM options.51

JEP 439: Generational ZGC 5 extends the Z Garbage Collector (ZGC) by introducing the concept of separate generations for young and old objects.63 This enhancement allows ZGC to more frequently collect young objects, which have a higher tendency to die young, thus reclaiming memory more efficiently.61 The primary goals of this JEP include lowering the risks of allocation stalls, reducing the required heap memory overhead, and decreasing the CPU overhead associated with garbage collection.62 While preserving the essential low-pause-time characteristics of non-generational ZGC, the generational approach splits the heap into two logical generations that are collected independently.63 This strategy leverages the weak generational hypothesis, which posits that younger objects are more likely to be garbage.61 By focusing collection efforts on the young generation, ZGC aims to improve overall memory efficiency and reduce the frequency of more resource-intensive old generation collections.

JEP 387: Elastic Metaspace 4 was delivered as a feature in JDK 16. While the provided snippets do not offer detailed information about this JEP, the name itself suggests improvements in the dynamic management of Metaspace. Metaspace is the area of native memory used by the HotSpot JVM to store class metadata. An "elastic" Metaspace likely indicates enhancements that allow this memory region to more dynamically resize based on the application's needs, potentially reducing the overall memory footprint by more efficiently managing the allocation and deallocation of memory used for class-related data. This could involve a greater ability for Metaspace to return unused memory to the operating system, further optimizing memory utilization.

JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) 65 marked a significant step in the maturity of the Z Garbage Collector. Introduced as an experimental feature in JDK 11 (JEP 333), JEP 377 promoted ZGC to a production-ready feature in JDK 15.70 ZGC was designed with the primary goals of achieving low GC pause times (not exceeding 10ms), handling heaps ranging from a few hundred megabytes to multiple terabytes, and limiting the reduction in application throughput compared to using G1.73 As a concurrent, single-generation, region-based, NUMA-aware, and compacting collector 73, ZGC's design inherently involves efficient memory management to support these goals, particularly when dealing with very large heaps. Features like concurrent class unloading and the ability to uncommit unused memory (introduced in JEP 351 69) further contribute to ZGC's memory efficiency.

JEP 351: ZGC: Uncommit Unused Memory (Experimental) 74 specifically addresses the memory footprint of applications using the Z Garbage Collector. This experimental JEP enhances ZGC to return unused heap memory to the operating system.74 This is particularly beneficial for applications running in environments where memory resources are a concern, such as containerized deployments or scenarios where applications might experience periods of low activity.74 ZGC achieves this by identifying ZPages (heap regions) that have been unused for a specified period and evicting them from its page cache, subsequently uncommitting the memory associated with these pages.74 This uncommit capability is enabled by default but can be controlled using the -XX:ZUncommitDelay=<seconds> option to configure the timeout for unused memory.74 Importantly, ZGC will never uncommit memory such that the heap size falls below the minimum specified size (-Xms).74

JEP 254: Compact Strings 79 introduced a more space-efficient internal representation for java.lang.String objects and related classes like StringBuilder and StringBuffer.79 Prior to this JEP, strings in Java used a char array with two bytes per character (UTF-16 encoding). However, many String objects, especially in certain applications, contain only Latin-1 characters, which can be represented using a single byte. JEP 254 changes the internal storage to a byte array plus an encoding-flag field.81 The encoding flag indicates whether the characters are stored as ISO-8859-1/Latin-1 (one byte per character) or as UTF-16 (two bytes per character), based on the string's content.79 This optimization can reduce the memory required for String objects containing only single-byte characters by up to 50% 79, leading to significant overall memory savings in applications with a large number of strings. This was primarily an implementation change without any modifications to public APIs.81

JEP 192: String Deduplication in G1 84 focuses on reducing memory consumption by addressing the common issue of duplicate String objects on the Java heap. In many large-scale Java applications, a significant portion of the heap's live data set is occupied by String objects, and a substantial fraction of these are often duplicates (i.e., they have the same content).84 JEP 192 enhances the G1 garbage collector to automatically and continuously deduplicate these redundant String instances.85 The deduplication process involves making duplicate String objects share the same underlying char array.85 This is achieved by a background deduplication thread that processes a queue of candidate String objects identified during garbage collection. A hashtable is used to track unique character arrays, and when a duplicate is found, the String object is updated to point to the existing array, allowing the original array to be garbage collected.85 This feature, which is only implemented for the G1 garbage collector, is expected to result in an average heap reduction of around 10%.85

JEP 149: Reduce Core-Library Memory Usage 88 represents a broad effort to decrease the dynamic memory used by the core-library classes within the JDK without negatively impacting performance.89 This JEP explored various potential improvements to library classes and their native implementations to reduce heap usage.89 Some of the candidate techniques investigated included reducing the size of java.lang.Class objects by moving infrequently used fields (related to reflection and annotations) to separate helper classes 89, and potentially disabling the reflection compiler, which generates bytecode for method calls to improve performance but also contributes to the dynamic footprint.89 Other areas of investigation included tuning the initial sizes of internal tables, caches, and buffers to minimize memory wastage.89 The overall goal was to identify and implement memory reductions that are effective, maintainable, and have minimal performance impact on typical workloads.89

JEP 147: Reduce Class Metadata Footprint 92 specifically aimed at decreasing the memory footprint of class metadata within the HotSpot JVM, with a particular focus on improving performance on small devices.95 This JEP drew inspiration from memory-reduction techniques used in CVM, an embedded JVM.95 Some of the strategies explored included keeping rarely-used fields out of the core class, method, and field data structures, using the smallest possible data types for struct fields, encoding certain fields to fit into smaller types, carefully grouping fields of similar sizes to avoid unnecessary padding, using 16-bit offsets instead of 32-bit pointers for some data, and employing unions for groups of fields where only one is in use at a time.95 The goal of this JEP was to achieve a 25% reduction in the memory footprint of class, method, and field metadata (excluding bytecodes and interned strings) without causing more than a 1% regression in application startup and runtime performance.95

JEP 122: Remove the Permanent Generation 96 represents a significant architectural change in the HotSpot JVM's memory management. Prior to this JEP (delivered in Java 8), class metadata, interned Strings, and class static variables were stored in a dedicated portion of the heap called the permanent generation. JEP 122 proposed and implemented the removal of this permanent generation, moving class metadata to native memory and interned Strings and class statics to the Java heap.101 This change simplified memory management by eliminating the need to tune the size of the permanent generation, a common source of confusion and performance issues. By managing class metadata in native memory and leveraging the existing garbage collection mechanisms for interned Strings and statics, this JEP indirectly impacted memory usage patterns and paved the way for further memory-related optimizations in subsequent JDK releases.

JEP Number

Title

JDK Release

Key Memory Improvement Mechanisms

450

Compact Object Headers (Experimental)

24

Reduces the size of object headers from 96-128 bits to 64 bits, decreasing heap size and improving density.

439

Generational ZGC

21

Extends ZGC to use generational garbage collection, focusing on young objects to reduce memory overhead.

387

Elastic Metaspace

16

Improves dynamic resizing and management of Metaspace for more efficient memory usage of class metadata.

377

ZGC: A Scalable Low-Latency Garbage Collector (Production)

15

Design inherently involves efficient memory management for large heaps with low latency.

351

ZGC: Uncommit Unused Memory (Experimental)

13

Allows ZGC to return unused heap memory to the operating system, reducing memory footprint.

254

Compact Strings

9

Changes internal string representation to use byte arrays for Latin-1 characters, reducing string memory usage.

192

String Deduplication in G1

8u20

Enhances G1 GC to automatically deduplicate duplicate String instances, reducing heap live data.

149

Reduce Core-Library Memory Usage

8

Aims to reduce dynamic memory usage across core library classes through various techniques.

147

Reduce Class Metadata Footprint

8

Reduces the memory footprint of HotSpot's class metadata, especially beneficial for small devices.

122

Remove the Permanent Generation

8

Removes the permanent generation, simplifying memory management and moving metadata to native memory and heap.

V. JDK Enhancement Proposals Targeting Both CPU and Memory Usage

Several JEPs have been identified that aim to improve both the CPU and memory usage of Java applications, often through mechanisms that have a dual impact on resource efficiency.

JEP 483: Ahead-of-Time Class Loading & Linking 55 focuses on optimizing the application startup process. By making the classes of an application instantly available in a loaded and linked state when the HotSpot JVM starts, this JEP aims to improve startup time, which directly translates to reduced CPU cycles spent during initialization.106 This is achieved by monitoring an application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs.106 Furthermore, by pre-loading and linking classes, the memory footprint at runtime can potentially be reduced, as these classes are readily available and do not need to be loaded and linked on demand for each application run.108 The AOT cache itself does consume memory, but the trade-off results in faster startup and potentially better overall runtime performance due to reduced overhead.

JEP 444: Virtual Threads 5 introduces a new concurrency model to the Java platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.62 By allowing a much larger number of concurrent tasks to be handled with significantly less overhead compared to traditional platform threads, virtual threads can lead to improved CPU utilization, especially in I/O-bound workloads where many threads might otherwise be blocked waiting for operations to complete.112 Moreover, virtual threads typically have a much smaller memory footprint compared to platform threads, as they do not require a dedicated OS thread and have smaller stack sizes.114 This can result in substantial memory savings for applications that need to manage a large number of concurrent operations.

JEP 431: Sequenced Collections While the provided snippets do not explicitly link this JEP to direct CPU or memory performance enhancements, research indicates that this JEP introduces new interfaces to represent collections with a defined encounter order. This can indirectly impact performance in scenarios where the order of elements in a collection is semantically important and needs to be consistently maintained, potentially avoiding the need for custom ordering logic that could consume additional CPU cycles. However, the primary focus of this JEP is on API design and functionality rather than direct performance optimization.

JEP 350: Dynamic CDS Archives 116 extends the Class-Data Sharing (CDS) feature to allow for the dynamic archiving of application classes at the end of Java application execution. This builds upon the existing AppCDS (Application Class-Data Sharing) functionality. The dynamically generated archive, created on top of the default system archive, contains all loaded application classes and library classes not present in the base archive.116 In subsequent runs of the same application, this dynamic CDS archive can be memory-mapped, making the application's classes instantly available in a loaded and linked state.116 This leads to improved startup time, reducing the CPU cycles spent on class loading and linking. Furthermore, by sharing this archive across multiple JVM instances running the same application, the overall memory footprint can be reduced, as the class metadata is shared rather than being loaded separately by each instance.117

JEP 310: Application Class-Data Sharing 42 enhanced the existing Class-Data Sharing (CDS) feature by allowing application classes to be placed in the shared archive.122 When the JVM starts, it loads classes into memory as a preliminary step, which can introduce latency, especially for applications with many classes. AppCDS addresses this by allowing application classes to be pre-processed and stored in a shared archive.119 This archive can then be memory-mapped at JVM startup, making the application's classes instantly available in a loaded and linked state.122 This significantly reduces the application startup time, leading to lower CPU consumption during initialization. Moreover, when multiple JVMs on the same host use the same shared archive, the memory footprint can be reduced, as the class data is shared across processes.119

JEP 197: Segmented Code Cache 47 introduced a significant change to the organization of the JVM's code cache. Instead of a single monolithic code heap, the code cache is divided into distinct segments, each containing compiled code of a particular type (non-method, profiled, and non-profiled code).124 This segmentation aims to improve performance (CPU) by enabling shorter sweep times during code cache management, potentially leading to better instruction cache locality and reduced fragmentation of highly optimized code.124 Additionally, by providing better control over the JVM's memory footprint through the ability to manage the sizes of these different code heap segments, this JEP also contributes to improved memory usage.124

JEP 158: Unified JVM Logging 126 introduced a common logging system for all components of the JVM. While the primary goal of this JEP was to provide a more flexible and configurable logging framework, efficient logging can indirectly contribute to better CPU and memory usage. By allowing for more granular control over the logging output and the ability to easily diagnose performance issues, developers and system administrators can more quickly identify and address areas of inefficiency in their applications, potentially leading to optimizations that reduce both CPU and memory consumption.

JEP Number

Title

JDK Release

Key CPU Improvement Mechanisms

Key Memory Improvement Mechanisms

483

Ahead-of-Time Class Loading & Linking

24

Improves startup time by pre-loading and linking classes.

Reduces memory footprint by sharing loaded and linked class data in a cache.

444

Virtual Threads

21

Improves CPU utilization for I/O-bound tasks with lightweight threads.

Reduces memory footprint per concurrent task compared to platform threads.

350

Dynamic CDS Archives

13

Improves startup time by dynamically archiving and sharing application classes.

Reduces memory footprint by sharing the archive across JVM instances.

310

Application Class-Data Sharing

10

Improves startup time by memory-mapping shared application class data.

Reduces memory usage by sharing class data across multiple JVMs.

197

Segmented Code Cache

9

Improves performance through better code locality and reduced fragmentation.

Provides better control over JVM memory footprint by managing code heap segments.

158

Unified JVM Logging

9

Indirectly improves efficiency by facilitating quicker identification and resolution of performance bottlenecks.

Indirectly improves efficiency by facilitating quicker identification and resolution of memory-related issues.

VI. Conclusion: Key Trends and Future Directions in Java Performance Optimization through JEPs

The analysis of these JDK Enhancement Proposals reveals several key trends in the ongoing efforts to optimize the performance and resource efficiency of the Java platform. A significant emphasis continues to be placed on refining the garbage collection mechanisms, with advancements seen across different collectors like G1 and ZGC. These improvements target both reducing CPU overhead through concurrent processing and parallelization, as well as minimizing memory footprint through techniques like generational collection and the ability to uncommit unused memory.

Memory footprint reduction remains a critical area of focus, with JEPs like Compact Object Headers and Compact Strings directly aiming to decrease the memory consumed by fundamental data structures. The Class-Data Sharing (CDS) feature, along with its extensions for applications and dynamic archiving, demonstrates a sustained effort to improve both startup time and memory usage by enabling the sharing of class metadata across JVM instances.

The introduction of virtual threads in JEP 444 represents a notable advancement in how Java handles concurrency, offering a more resource-efficient model for managing large numbers of concurrent tasks, particularly in I/O-bound applications. This signifies an adaptation to modern application architectures and the demands of high-throughput systems.

Furthermore, the ongoing optimization of specific runtime aspects, such as reflection and cryptography, highlights a comprehensive strategy for improving performance across various facets of Java application execution. The progression of features from experimental to production-ready status, as seen with ZGC and Shenandoah (mentioned in 67), indicates a mature and iterative approach to platform enhancement.

Looking towards the future, the "Lookahead" section in snippets like 5 hints at continued evolution in areas such as scoped values and structured concurrency, which could further impact resource efficiency. Moreover, ongoing projects like Valhalla 52, with its aim to introduce value types, promise additional opportunities for enhancing both the performance and memory usage of Java applications by allowing for more efficient data representation and manipulation. The continuous stream of JEPs focused on these critical areas underscores the Java platform's commitment to remaining a high-performance and resource-efficient choice for a wide range of development needs.

Works cited

  1. JEP 1: JDK Enhancement-Proposal & Roadmap Process, accessed April 23, 2025, https://openjdk.org/jeps/1
  2. JDK Enhancement Proposal - Wikipedia, accessed April 23, 2025, https://en.wikipedia.org/wiki/JDK_Enhancement_Proposal
  3. OpenJDK Project JEPs (JDK Enhancement Proposals) - VM Options Explorer, accessed April 23, 2025, https://chriswhocodes.com/jepmap.html
  4. JEP 0: JEP Index - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/0
  5. A list of major Java and JVM features since JDK 17 to 22 - Digma AI, accessed April 23, 2025, https://digma.ai/a-list-of-major-java-and-jvm-features-since-jdk-17-to-22/
  6. JDK Releases - Java, accessed April 23, 2025, https://www.java.com/releases/
  7. The not-so-hidden gems in Java 18: The JDK Enhancement Proposals - Oracle Blogs, accessed April 23, 2025, https://blogs.oracle.com/javamagazine/post/java-18-gems-jdks
  8. A categorized list of all Java and JVM features since JDK 8 to 21 - Advanced Web Machinery, accessed April 23, 2025, https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-21/
  9. How to Read a JDK Enhancement Proposal - Inside Java Newscast #74 // nipafx, accessed April 23, 2025, https://nipafx.dev/inside-java-newscast-74/
  10. OpenJDK News Roundup: Compact Source, Module Import Declarations, Key Derivation, Scoped Values - InfoQ, accessed April 23, 2025, https://www.infoq.com/news/2025/04/jdk-news-roundup-apr14-2025/
  11. OpenJDK News: Source Compacting, Module Declarations, and More - MojoAuth, accessed April 23, 2025, https://mojoauth.com/blog/openjdk-news-source-compacting-module-declarations-and-more/
  12. Eight JEPs Advance to Candidate Status as Java Community Prepares for JDK 25, accessed April 23, 2025, https://adtmag.com/articles/2025/04/23/eight-jeps-advance-to-candidate-status.aspx
  13. JEP 509: JFR CPU-Time Profiling (Experimental) - daily.dev, accessed April 23, 2025, https://app.daily.dev/posts/jep-509-jfr-cpu-time-profiling-experimental--cbiu49npu
  14. JEP 509: JFR CPU-Time Profiling (Experimental) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/509
  15. Oracle Releases Java 24, accessed April 23, 2025, https://www.oracle.com/news/announcement/oracle-releases-java-24-2025-03-18/
  16. Performance Improvements in JDK 24 - Inside.java, accessed April 23, 2025, https://inside.java/2025/03/19/performance-improvements-in-jdk24/
  17. What's new in Java 24 - PVS-Studio, accessed April 23, 2025, https://pvs-studio.com/en/blog/posts/java/1233/
  18. JEP 475: Late Barrier Expansion for G1 - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/475
  19. JEP proposed to target JDK 24: 475: Late Barrier Expansion for G1 - OpenJDK mailing lists, accessed April 23, 2025, https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009432.html
  20. Java 22 available: features for improved performance - Techzine Europe, accessed April 23, 2025, https://www.techzine.eu/news/devops/117889/java-22-available-features-for-improved-performance/
  21. An overview of JDK 22 features - BellSoft, accessed April 23, 2025, https://bell-sw.com/blog/an-overview-of-jdk-22-features/
  22. What's New With Java 22 | JRebel by Perforce, accessed April 23, 2025, https://www.jrebel.com/blog/whats-new-java-22
  23. JEP 423: Introducing Region Pinning to G1 Garbage Collector in OpenJDK - InfoQ, accessed April 23, 2025, https://www.infoq.com/news/2023/12/region-pinning-to-g1-gc/
  24. [JDK-8318706] Implement JEP 423: Region Pinning for G1 - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8318706
  25. JEP 423: Region Pinning for G1 - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/423
  26. JDK-8277244 Release Note: JEP 416: Reimplement Core Reflection With Method Handles - Java Bug Database, accessed April 23, 2025, https://bugs.java.com/bugdatabase/view_bug?bug_id=8277244
  27. JDK-8266010 JEP 416: Reimplement Core Reflection with Method Handles - Bug ID, accessed April 23, 2025, https://bugs.java.com/bugdatabase/view_bug?bug_id=8266010
  28. JEP 416: Reimplement Core Reflection with Method Handles - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/416
  29. [JDK-8271820] Implementation of JEP 416: Reimplement Core Reflection with Method Handle - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8271820
  30. JEP 376: ZGC: Concurrent Thread-Stack Processing - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/376
  31. [JDK-8261332] Release Note: JEP 376: ZGC Concurrent Stack Processing - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/issues/?jql=parent%3DJDK-8239600
  32. [JDK-8261332] Release Note: JEP 376: ZGC Concurrent Stack, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8261332
  33. Does a compactor process return memory to the OS? - Apache Accumulo, accessed April 23, 2025, https://accumulo.apache.org/blog/2024/04/09/does-a-compactor-return-memory-to-OS.html
  34. JEP 346: Promptly Return Unused Committed Memory from G1 - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/346
  35. Java 12-GC (JEP 346)Is behavior is particularly disadvantageous in container environments where resources are paid by use? - Stack Overflow, accessed April 23, 2025, https://stackoverflow.com/questions/54490373/java-12-gc-jep-346is-behavior-is-particularly-disadvantageous-in-container-env
  36. Java 12 Features - DigitalOcean, accessed April 23, 2025, https://www.digitalocean.com/community/tutorials/java-12-features
  37. The arrival of Java 12! - Oracle Blogs, accessed April 23, 2025, https://blogs.oracle.com/java/post/the-arrival-of-java-12
  38. [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 - OpenJDK mailing lists, accessed April 23, 2025, https://mail.openjdk.org/pipermail/jdk-updates-dev/2020-April/002953.html
  39. Parallel full GC for G1 (JEP 307) - Packt+ | Advance your knowledge in tech, accessed April 23, 2025, https://www.packtpub.com/en-ic/product/java-11-and-12-new-features-9781789133271/chapter/garbage-collector-optimizations-4/section/parallel-full-gc-for-g1-jep-307-ch04lvl1sec17
  40. [JDK-8189726] Release Note: JEP 307: Parallel Full GC for G1 - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8189726
  41. JEP 307: Parallel Full GC for G1 - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/307
  42. Introducing Java SE 10 - Oracle Blogs, accessed April 23, 2025, https://blogs.oracle.com/java/post/introducing-java-se-10
  43. JEP 246: Leverage CPU Instructions for GHASH and RSA - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/246
  44. Build JEP on Win 10 64 bit · Issue #230 · ninia/jep - GitHub, accessed April 23, 2025, https://github.com/ninia/jep/issues/230
  45. jep/MANIFEST.in at master · ninia/jep - GitHub, accessed April 23, 2025, https://github.com/ninia/jep/blob/master/MANIFEST.in
  46. Index by Author to Volume 9 - American Economic Association, accessed April 23, 2025, https://www.aeaweb.org/articles?id=10.1257/jep.9.4.246
  47. 26 new Java 9 enhancements you will love - Packt, accessed April 23, 2025, https://www.packtpub.com/en-us/learning/how-to-tutorials/26-new-java-9-enhancements-you-will-love
  48. Performance Improvements of Contended Java Monitor from JDK 6 to 9 - vmlens, accessed April 23, 2025, https://vmlens.com/articles/performance-improvements-of-java-monitor/
  49. JEP 143: Improve Contended Locking - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/143
  50. [JDK-8049158] Improve Contended Locking Development - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/issues/?jql=parent%3DJDK-8046133
  51. Java Compact Object Headers (JEP 450) - HappyCoders.eu, accessed April 23, 2025, https://www.happycoders.eu/java/java-compact-object-headers-jep-450/
  52. JEP 450: Compact Object Headers. Proposed to Target JDK 24 : r/java - Reddit, accessed April 23, 2025, https://www.reddit.com/r/java/comments/1gd35vb/jep_450_compact_object_headers_proposed_to_target/
  53. [24] JEP 450: Compact Object Headers (Experimental) #3236 - GitHub, accessed April 23, 2025, https://github.com/eclipse-jdt/eclipse.jdt.core/issues/3236
  54. Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond, accessed April 23, 2025, http://blog.vanillajava.blog/2024/12/demystifying-java-object-sizes-compact.html
  55. Java 24 Delivers New Experimental and Many Final Features - InfoQ, accessed April 23, 2025, https://www.infoq.com/news/2025/03/java24-released/
  56. What's New With Java 24 | JRebel by Perforce, accessed April 23, 2025, https://www.jrebel.com/blog/whats-new-java-24
  57. Liberica JDK 24 builds are generally available - BellSoft, accessed April 23, 2025, https://bell-sw.com/blog/liberica-jdk-24-is-released/
  58. Java 24 Features Unveiled: 24 Highlights You Need to Know - BellSoft, accessed April 23, 2025, https://bell-sw.com/blog/an-overview-of-jdk-24-features/
  59. JEP-450 Review Todo - OpenJDK Wiki, accessed April 23, 2025, https://wiki.openjdk.org/display/lilliput/JEP-450+Review+Todo
  60. JEP 450: Compact Object Headers (Experimental) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/450
  61. Java 21 Hidden Heroes - JAX London 2025, accessed April 23, 2025, https://jaxlondon.com/blog/java21-hidden-heroes/
  62. Java 21 is here: Virtual threads, string templates, and more - Oracle Blogs, accessed April 23, 2025, https://blogs.oracle.com/javamagazine/post/java-21-now-available
  63. JEP 439: Generational ZGC - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/439
  64. Preparing for JDK 21: A Comprehensive Overview of Key Features and Enhancements, accessed April 23, 2025, https://foojay.io/today/preparing-for-jdk-21-a-comprehensive-overview-of-key-features-and-enhancements/
  65. Looking at Java 21: Generational ZGC | belief driven design, accessed April 23, 2025, https://belief-driven-design.com/looking-at-java-21-generational-zgc-e5c1c/
  66. JEP 474: ZGC: Generational Mode by Default - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/474
  67. The Arrival of Java 15 - Oracle Blogs, accessed April 23, 2025, https://blogs.oracle.com/java/post/the-arrival-of-java-15
  68. [JDK-8209683] JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8209683?jql=labels%20%3D%20jdk15-ptt-2020-04-02
  69. [JDK-8209683] JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production), accessed April 23, 2025, https://bugs.openjdk.java.net/browse/JDK-8209683?actionOrder=desc
  70. Oracle Announces Java 15, accessed April 23, 2025, https://www.oracle.com/news/announcement/oracle-announces-java-15-091520/
  71. A one-sentence summary of each new JEP from JDK 21 - JVM Weekly vol. 149 - Vived, accessed April 23, 2025, https://vived.io/a-one-sentence-summary-of-each-new-jep-from-jdk-21-jvm-weekly-vol-149/
  72. JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/377
  73. JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/333
  74. JEP 351: ZGC: Uncommit Unused Memory (Experimental) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/351
  75. Significant Changes in JDK 13 Release - Java - Oracle Help Center, accessed April 23, 2025, https://docs.oracle.com/en/java/javase/24/migrate/significant-changes-jdk-13.html
  76. JDK-8222481 Release Note: JEP 351: ZGC: Uncommit Unused Memory - Bug ID, accessed April 23, 2025, https://bugs.java.com/bugdatabase/view_bug?bug_id=8222481
  77. Oracle Keeps Driving Developer Productivity with New Java Release, accessed April 23, 2025, https://www.oracle.com/corporate/pressrelease/oow19-new-java-release-091619.html
  78. [JDK-8222481] Release Note: JEP 351: ZGC: Uncommit Unused, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8222481
  79. JDK 9 Release Notes - New Features, accessed April 23, 2025, https://www.oracle.com/java/technologies/javase/9-new-features.html
  80. [JavaSpecialists 306] - Measuring compact strings memory savings, accessed April 23, 2025, https://www.javaspecialists.eu/archive/Issue306-Measuring-compact-strings-memory-savings.html
  81. [JDK-8054307] JEP 254: Compact Strings - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.java.net/browse/JDK-8054307?actionOrder=desc
  82. [JDK-8176344] Release Note: JEP 254: Compact Strings - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/issues/?jql=parent%3DJDK-8054307
  83. JEP 254: Compact Strings - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/254
  84. JEP 192: String Deduplication in G1 : r/ProgrammingLanguages - Reddit, accessed April 23, 2025, https://www.reddit.com/r/ProgrammingLanguages/comments/k4g2ib/jep_192_string_deduplication_in_g1/
  85. JEP 192: String Deduplication in G1 - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/192
  86. JDK 17 G1/Parallel GC changes, accessed April 23, 2025, https://tschatzl.github.io/2021/09/16/jdk17-g1-parallel-gc-changes.html
  87. String Deduplication in JEP192 - OpenJDK mailing lists, accessed April 23, 2025, https://mail.openjdk.org/pipermail/hotspot-gc-dev/2014-February/009525.html
  88. [JDK-8005233] (JEP 149) Fully Concurrent ClassLoading - Java Bug System, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8005233?focusedCommentId=13293578&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
  89. JEP 149: Reduce Core-Library Memory Usage - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/149
  90. Standards & Documents Search | JEDEC, accessed April 23, 2025, https://www.jedec.org/document_search?items_per_page=40&search_api_views_fulltext=jep&order=title&sort=asc
  91. JDK-8005232 (JEP-149) Class Instance size reduction - Java Bug Database, accessed April 23, 2025, https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8005232
  92. Speer Gold Dot LE Duty 9mm Luger Ammunition 147 Grain Jacketed Hollow Point - 53619, accessed April 23, 2025, https://www.targetsportsusa.com/speer-gold-dot-law-enforcement-duty-9mm-luger-ammo-147-grain-jhp-53619-p-3527.aspx
  93. JEDEC JEP 147 - Procedure for Measuring Input Capacitance Using a Vector Network Analyzer (VNA) - Standards | GlobalSpec, accessed April 23, 2025, https://standards.globalspec.com/std/809462/jedec-jep-147
  94. PROCEDURE FOR MEASURING INPUT CAPACITANCE USING A VECTOR NETWORK ANALYZER (VNA): | JEDEC, accessed April 23, 2025, https://www.jedec.org/standards-documents/docs/jep-147
  95. JEP 147: Reduce Class Metadata Footprint - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/147
  96. jedec jep 122 Std. Antpedia, accessed April 23, 2025, https://m.antpedia.com/standard/sp/en/746385.html
  97. JEDEC JEP 122 - Failure Mechanisms and Models for Semiconductor Devices | GlobalSpec, accessed April 23, 2025, https://standards.globalspec.com/std/10047309/jedec-jep-122
  98. JEDEC PUBLICATION - CiteSeerX, accessed April 23, 2025, https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=1adfbb24400749acdf2f6c636be294511111892b
  99. JEP-122 | Failure Mechanisms and Models for Semiconductor Devices - Document Center, accessed April 23, 2025, https://www.document-center.com/standards/show/JEP-122/history/
  100. JEP-122 | Failure Mechanisms and Models for Semiconductor Devices - Document Center, accessed April 23, 2025, https://www.document-center.com/standards/show/JEP-122
  101. JEP 122: Remove the Permanent Generation - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/122
  102. FAILURE MECHANISMS AND MODELS FOR SEMICONDUCTOR DEVICES - JEDEC, accessed April 23, 2025, https://www.jedec.org/standards-documents/docs/jep-122e
  103. Failure Mechanisms and Models for Semiconductor Devices JEP122H - JEDEC, accessed April 23, 2025, https://www.jedec.org/sites/default/files/docs/JEP122H.pdf
  104. 1-JEDEC standards for product level qualification.pdf, accessed April 23, 2025, http://audace-reliability.crihan.fr/Ateliers_files/1-JEDEC%20standards%20for%20product%20level%20qualification.pdf
  105. SSB-1: Guidelines for Using Plastic Encapsulated Microcircuits and Semiconductors in Military, Aerospace and Other Rugged Applic - NASA NEPP, accessed April 23, 2025, https://nepp.nasa.gov/docuploads/77082CF9-CD35-4B5F-9CAE5004DE386E64/Guidelines%20for%20using%20PEMs.pdf
  106. Java Applications Can Start 40% Faster in Java 24 - InfoQ, accessed April 23, 2025, https://www.infoq.com/news/2025/03/java-24-leyden-ships/
  107. Java 24 Launches with JEP 483 for Enhanced Application Performance and Future Plans for 2025 - MojoAuth - Go Passwordless, accessed April 23, 2025, https://mojoauth.com/blog/news-2025-03-java-24-leyden-ships/
  108. Let's Take a Look at... JEP 483: Ahead-of-Time Class Loading & Linking! - Gunnar Morling, accessed April 23, 2025, https://www.morling.dev/blog/jep-483-aot-class-loading-linking/
  109. Java 24 Launches with JEP 483 for Enhanced Application Performance and Future Plans for 2025 - DEV Community, accessed April 23, 2025, https://dev.to/ssojet/java-24-launches-with-jep-483-for-enhanced-application-performance-and-future-plans-for-2025-588e
  110. JEP draft: Ahead-of-time Command Line Ergonomics - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/8350022
  111. JEP 483: Ahead-of-Time Class Loading & Linking - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/483
  112. JEP 444: Virtual Threads - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/444
  113. JEP draft: Structured Concurrency (Fifth Preview) - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/8340343
  114. Virtual Threads (JEP 444) - javaalmanac.io, accessed April 23, 2025, https://javaalmanac.io/features/virtual-threads/
  115. Virtual Threads - Oracle Help Center, accessed April 23, 2025, https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html
  116. JEP 350: Dynamic CDS Archives - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/350
  117. How to use CDS with Spring Boot applications - BellSoft, accessed April 23, 2025, https://bell-sw.com/blog/how-to-use-cds-with-spring-boot-applications/
  118. Application / Dynamic Class Data Sharing In HotSpot JVM - Ionut Balosin, accessed April 23, 2025, https://ionutbalosin.com/2022/04/application-dynamic-class-data-sharing-in-hotspot-jvm/
  119. Java 10 - Application Class-Data Sharing - Tutorialspoint, accessed April 23, 2025, https://www.tutorialspoint.com/java/java10_class_data_sharing.htm
  120. Java 10 Features You Must Be Knowing About - Code Pumpkin, accessed April 23, 2025, https://codepumpkin.com/java-10-features/
  121. What is new added features in Java 11, accessed April 23, 2025, https://www.dineshonjava.com/what-is-new-added-features-in-java-11/
  122. JEP 310: Application Class-Data Sharing - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/310
  123. [JDK-8190336] Make sure that AppCDS works on aarch64 platform, accessed April 23, 2025, https://bugs.openjdk.org/browse/JDK-8190336
  124. JEP 197: Segmented Code Cache - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/197
  125. Reasons to move to Java 11 - Azure | Microsoft Learn, accessed April 23, 2025, https://learn.microsoft.com/en-us/java/openjdk/reasons-to-move-to-java-11
  126. JEP 158: Unified JVM Logging - OpenJDK, accessed April 23, 2025, https://openjdk.org/jeps/158
  127. Embracing JVM unified logging (JEP-158 / JEP-271) - Brice Dutheil, accessed April 23, 2025, https://blog.arkey.fr/2020/07/28/embracing-jvm-unified-logging-jep-158-jep-271/
  128. Introduction to JVM Unified Logging (JEP-158 / JEP-271) - Foojay.io, accessed April 23, 2025, https://foojay.io/today/introduction-to-jvm-unified-logging-jep-158-jep-271/
  129. Embracing JVM unified logging (JEP-158 / JEP-271) - Foojay.io, accessed April 23, 2025, https://foojay.io/today/embracing-jvm-unified-logging/