New features in Java 9, such as JEP 143, 193, 197, 199, and 295, help in performance improvisation of distributed frameworks, such as JavaSpaces and CORBA. JEP 376, 222, 164, and so on help in the development of modular and easy-to-maintain applications. JEP 158, 266, and 254 help in having better controlled and easy-to-maintain concurrent systems with ease of performing a root cause analysis through application logs.
Some of the nice features in Java 9 that help in enhancing a distributed system's performance are as follows:
| JEP | Feature | Benefit | Challenges | Description |
| 158 | Unified JVM logging | This is for performance improvisation and better tracking. | NA | Provide an infrastructure for JVM logging for better identification of the root cause of crashes or performance issues. These features are adopted from JRockit--the industry's highest performing JVM (part of Oracle Fusion Middleware). |
| 102 | Process API updates | This is for better monitoring, control, and management of native processes. | NA | In a distributed environment, we may have systems with different operating systems. Using this feature developer can monitor native processes and control them through a uniform API. |
| 110 | HTTP/2 client | This is to replace the existing problematic API HttpURLConnection with the new HTTP client. | NA |
This is an existing HttpURLConnection API designed for outdated protocols (FTP, gopher, and so on). It supports HTTP/1.1, which is too abstract. It's hard to use and maintain, and many features are not documented. It supports one thread per request/response (blocking mode). |
| 143 | Improve contended locking | This is to significantly benefit real-world applications in addition to industry benchmarks. | Needs to provide performance gain without offsetting performance regressions. |
This project will explore performance improvements in the following areas related to contended Java monitors: 1. Field reordering and cache line alignment. 2. Speed up PlatformEvent::unpark(). 3. Quicker Java monitor enter operations. 4. Quicker Java monitor exit operations. 5. Quicker Java monitor notify/notifyAll operations. |
| 158 | Unified JVM logging | Provides easy and faster root cause analysis in the case of a JVM crash or sluggishness in the distributed environment. |
This may impact:
|
This logging framework will provide the following features:
|
| 165 | Compiler control |
Compiler testing is possible while it's running. Developing a workaround for bugs and encapsulation of compiler options is also good hygiene. This provides better control in distributed computing. |
NA | JVM compilers can be controlled at runtime using certain flags (called directives). |
| 193 | Variable handles | With the increasing trend in concurrent and parallel programming, this feature will help programmers achieve atomic and ordered operations on variables defined in the code and have better control over them. | Ensure safety, integrity, performance, and usability. | Variable handle is a reference to a variable under different access modes (static, instance, array elements, array views, byte or char array, and so on). This requires library enhancements. |
| 197 | Segmented code cache |
Provides performance improvement through separation of specialized code. Provides better control of JVM memory footprint. From a distributed computing perspective, this will improve the management of heterogeneous code (GPU code) and AOT-compiled code. |
Having a fixed size per code heap leads to a potential waste of memory in case one code heap is full and there is still space in another code heap. This will cause problems for very small code cache sizes. An option for turning it off is required. | Instead of having a single code heap, the code cache is divided into distinct code heaps; each heap contains compiled code of a particular type. Three top-level types are JVM internal (non-method), profiled, and non-profiled code. |
| 199 | Smart Java compilation, phase 2 | This improves build speed and allows incremental builds. | At present, the quality of the code and stability of the tool are not poor and not publicly releasable. | This improves the sjavac tool so that it can be used by default in the JDK build. It also generalizes it so that it can be used to build large projects other than the JDK. |
| 200 | The modular JDK |
Compliance with JSR 376. |
Should address all the important use cases. |
Divide the JDK into a set of modules that can be combined at compile time, build time, or runtime into a variety of configurations as follows: full Java SE platform, the full JRE, the full JDK, compact profiles, and custom configurations. The modular structure proposed is as follows:
|