Welcome!

Java Authors: Pat Romanski, Liz McMillan, Elizabeth White, Dana Gardner, Jim Kaskade

Related Topics: Java

Java: Article

The Right Time for Real Time Java

Addressing the sources of unpredictability in Java applications

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.

More Stories By Paul Hohensee

Paul Hohensee is a senior staff engineer at Sun Microsystems where he is the Java Platform Standard Edition JVM Technical Lead. His primary focus is JVM performance along with hardware and platform support for Java and other dynamic languages. Earlier in his career he worked on dynamic binary translation as well as optimizing compilers and libraries for the first symmetric multiprocessors.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.