One of the main goals of Java language design is to make the application real. Java is designed in such a way that a .class file can be created in one operating system. And, it can run smoothly on another operating system or another computer, as long as the Java Runtime Environment is installed on the target system. Initially, Java runtime was much slower than other languages and their translators (such as C and C ++). Later versions of Java discovered improvements at the compiler level.
A complex dynamic complex called Just-In-Time (JIT) was introduced to provide better runtime performance. The JIT converter selectively selects the code for the most common methods in the application and converts them to the original code at runtime. When compiling methods, the JVM calls executable device code in a directly organized process instead of interpreting the bytecode code line by line. Due to improvements at different levels of the assembler level, the JIT compiler runs very fast and improves the overall performance of the Java application.
But this method has some disadvantages. For large, complex Java applications, JIT can take a long time to warm up. Java applications may contain methods that are used infrequently, so they will not be mounted. These methods may need to be explained when called. There may be performance problems due to repeated frequency calls.
According to the announcement, Java 9 will support Ahead of Time (AOT) time to increase the startup time of Java and SMB applications with the greatest impact on maximum performance. It must be built early because even if the JIT compiler is fast, Java programs will become too large to take JIT long to warm up entirely. Also, Java methods that are not used frequently may not be compiled. Performance loss is triggered by redundancy calls.
However, it is worth mentioning that the only supported module is java.base. The reason for this decision is to reduce the problem area “because Java code in java.base is already known and can be tested internally.”
One benefit is to reduce JVM runtime, which means more people can use Java to create command line tools, similar to the tools provided in the written language.
The fast boot time for the AOT and the smaller space in the code should be particularly useful for managed and cloud services, Klang said. “In an era of architectural architecture based on distributed and interactive distributed services, short-term services will directly benefit from more aggressive improvements that start only in J or J assembly in a minute or two.
AOT Pure does not allow developers to dynamically generate code, which can be useful in some situations, such as fast runtime evaluation, making reflection faster or running languages dynamically written on top of the JVM much faster than quick messages.
The Time-of-Time application only supports 64-bit Linux systems running on Java-64-bit, and the only module supported for AOT build java.base.
You may not be able to compile Java code by using categories and byte tags dynamically created, which must be run on the same system or an operating device of the same configuration, and the Java application will use the AOT code.
Also, not all applications benefit from compiled AOT code. Because this is an optional feature, you can avoid the potential degradation of your user application performance. If the user realizes that the app is slow to run or does not perform the expected peak performance, you can use the -Us: -UseAOT to switch between AOT or delete any AOT libraries.
