Faced with the demands of mission-critical applications, many enterprise developers have pushed the Java language and the Java Virtual Machine (JVM) to the limit. The most common issue seen in transactional environments is achieving predictable response time or latency – in other words, the time it takes the system to respond to a request or to move a transaction through the IT infrastructure. In such environments, Garbage Collection (GC) moves from being a valued feature to a major headache.

Developers respond in different ways to the dilemma of GC-induced pauses. For example, a developer working for a financial services firm could set up application environments with enough memory at the beginning of each trading day to avoid encountering GC until the markets close, while another developer could create hybrid systems with non-Java technology critical sections talking to a Java software infrastructure.

In cases like these, almost all developers believe they have a performance problem and think – “if the overall system were only 10 percent faster, we’d be fine.”

Sometimes they are correct. Sometimes you do need more transaction processing in a given amount of time and speeding up the entire system will help. In most cases, however, what you really want is to prioritize your important tasks and ensure that they’ll never get interrupted or delayed by lower priority tasks. This is where a real-time Java system can help; however, to make an intelligent choice between real-time and non-real-time Java system implementations, developers must first understand more about the sources of unpredictability.

The Real-Time Specification for Java
The Java community has long recognized the need for predictability, or the ability to meet time-based requirements, within Java software applications. The thinking was that a Java technology-based system could be built that would allow both real-time and non-real-time components of industrial control and robotics applications to coexist in the same program. Thus 10 years ago, the Real-Time Specification for Java (RTSJ) was born as JSR-001.

The RTSJ includes a host of features, such as priority scheduling and asynchronous event handling, specifically targeted at control applications, but the specification in its original form didn’t contemplate the use of GC by time-critical code. Instead it defined Immortal and Scoped memory areas in addition to the Java system heap. Using Immortal and Scoped memory requires some getting used to, so a general perception developed that the RTSJ has a steep learning curve and is difficult to use.