Design

The Future of Java Revisited

By Eric J. Bruno, March 05, 2010

What does the future hold for Java in light of Oracle's acquisition of it?

Sun HotSpot and Oracle JRockit Integration

In my opinion, the most surprising announcement so far has been the proposed integration of HotSpot and JRockit. For years, the former BEA JVM and Sun's JVM have been locked in a battle of performance and management features. The two have gone back and forth over best scores in performance benchmarks, overall latency, and garbage collection technology.

While many consider Sun's HotSpot JIT compiler technology to be the best implementation available, JRockit's garbage collector technology and other targeted performance enhancements have made it popular for certain classes of applications, such as those used in the financial markets. In fact, JRockit Real-Time's ability to be swapped in place of an existing VM to provide real-time application behavior has been an advantage over Sun's Java RTS product, which requires application code changes in most cases. However, Sun's HotSpot is perceived to be one of most reliable JVM implementations available, which is arguably more important than simply being the fastest. Also, HotSpot supports far more OS and hardware platform combinations.

Given that both JVMs have their own advantages, combining the two is expected to lead to outstanding results. Oracle has so far stated the following goals in combining the JVMs:

Improved Management and Monitoring. HotSpot brings with it the VisualVM and VisualGC tools, which allow you to visually profile, inspect, and analyze a running Java application's memory usage and performance over time. Oracle offers the JRockit Mission Control set of tools, which visually report and profile application execution, GC activity, and latency due to thread synchronization, IO, or memory-related issues. Additionally, JRockit Mission Control provides unobtrusive monitoring and reporting even in a production environment.

Native Execution on Hypervisors. Running the Java VM on the hardware directly, beyond the limitations of a traditional OS, has been a goal of both Sun and BEA before Oracle acquired them. This design potentially eliminates a substantial layer of software between the Java application and the hardware itself (and perhaps even the word "virtual" from virtual machine). In fact, Azul has been doing something similar for years, building specialized hardware and a Java VM that work together without a traditional OS in between. By targeting a hypervisor instead of specialized hardware, Oracle will have the advantage in that the resultant JVM will run on standard hardware already deployed in data centers; i.e. Intel, AMD, and Sparc-based systems.

Advanced Garbage Collection. Combining both Oracle/BEA's and Sun's investments in garbage collection technology and implementations should advance the state of Java GC technology in one big leap (hopefully). Whereas Sun has separate GC implementations for real-time behavior (Java RTS' Real-Time Garbage Collector), and for throughput (the Java SE 6 parallel collector), JRockit supports fewer collectors, and instead allows you to specify modes of operation. In addition, with support for dynamic modes, the collector can choose the best garbage collection strategy to use at runtime. With a lot of interesting work being done by both teams separately (such as Sun's work with the G1 collector), it will be interesting to see what these teams can do when working together.

NUMA Support for Multicore Systems. Non-uniform memory access (NUMA) is a design where memory access times depend on the memory location's physical location relative to the processor executing the code. This has become a more relevant topic with advances in multicore processor technology. For instance, in a multicore processor, each core may have its own local data cache, with a shared secondary cache at the processor level (see Figure 1).

Figure 1: A NUMA architecture within a multicore processor.

An alternative design is where all cores share a processor-level cache, although this is not necessarily a better design. For example, the shared cache is typically further physically from each core, and access must be coordinated between cores.

Combining VM Technologies

In an Oracle TechCast interview on the Oracle Tech Network, Mark Reinhold, Java SE Principal Engineer, expressed excitement about the combined VM technology, but emphasized the need to be patient. Reinhold said that the plan is a long-term one, where stability of the resultant JVM will be the highest priority. He also mentioned that combining the JVMs would not be an easy task, and it will probably be two years before they become one. Overall, Reinhold expects the best features of each JVM to be combined into a superior product offering.

E.J.B.

In either case, in order to achieve the best performance and lowest latency, the JVM needs to know about and support NUMA architectures. For instance, by working with the hardware, the JVM can attempt to execute code on a core with a "warm cache," which is the cache that already contains the required data.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!