Tuesday August 05, 2008
Want your Java fast or predictable ? Java RTS 2.1 is here
Filed under:
realtime
When
you leave work, would you rather
it be likely that you get home really quickly, or would you rather be
sure you will get home by a certain time ?
If you send a birthday card, would
you rather they try to get it there as soon as possible, or just know
it will definitely get there on the day ?
If you order something for yourself
on Amazon, do you pick the cheapest delivery option because most of the
time it gets there 2 days after it ships even though it doesn't say so ?
Fast, and Better Late than
Never, but...

For many years, we have focussed in Java SE on making the
runtime fast. Fast in a number of ways: fast to render graphics (in
particular, in the
upcoming 6u10
release), fast to execute server
applications, fast to start up, for example. And if you follow
Dave Dagastine's blog you
will know that we
frequently
hold the gold medal for various of the races laid out by the
SPEC.
But one thing the
HotSpot JVM
is not tuned for is
hard predictability.
That is to say, there is no
guarantee that a certain task will take no longer than a certain amount
of time. The native OS may choose to schedule something ahead of the
JVM process supporting your application. Classloading or performance
optimizations such as just-in-time compilations may put your
application thread in the backseat. Or, probably most recognizable to
users of your application, a garbage collection may kick in when you
least expect it. Such
non-deterministic behavior is just fine for many applications.
Moreover, it allows the JVM to tune for big picture performance
characteristics,
like overall throughput averaged over a complete run of your
application, even if one or two of your application tasks unexpectedly
end up taking longer than you thought. The needs of the many
outweighing the needs of the few,
in Vulcan.

But anyone who has been late picking up a small child
from daycare will know that there are some tasks that just
have to get
done within a certain time period. Even if it's at the expense of
completing others
you thought you might have time for.
...sometimes, Best is Never Late
So for nearly as many years as we have had been tuning performance in
the JDK,
Greg has
been leading our real-time variant of Java SE, called the
Java Real
Time System (Java RTS). This implementation is at the other end of
the predictability versus speed continuum, where your application may
select tasks (zero to all of them) as tasks that must complete within a
given time period. There is no 'better late than never' here: late
equals failure for this implementation of Java SE.
Java RTS 2.1 is Released !
And Java RTS recently hit a new milestone with a significant upgrade to
version 2.1, which
you can
check out here.
The main elements of Java RTS over the usual Java SE you are probably
more familiar with are:-
- the javax.realtime.* APIs
In addition to the regular Java SE APIs, these APIs allow you to code
parts of your application with the real-time guarantees it needs. This
means Java RTS runs regular Java SE applications, but provides no
realtime guarantees to any of the tasks in the application unless you
adapt the application to use the javax.realtime APIs to ask for those
guarantees.
- a VM tuned for realtime behavior
For example, containing a garbage collector that runs at a lower
priority than real time application threads so as not to delay them.
- Bindings to the realtime aspects of the underlying OS
The realtime system is only as good as the underlying OS can guarantee
(which is why we only offer it on Solaris and some Linux
distributions). These bindings, for example, ensure that JVM threads
are properly scheduled by the OS scheduler.
Our own
Paul Hohensee
and
Brian
Goetz have been writing in detail about both the additional
programming APIs and the implementation,
here and
here.
We've got folks using the Java RTS in traditional settings like
industrial automation projects, an of course in robots - where the
multiple processing involved in moving a complex limb have to be
coordinated,
even at JavaOne.. But
more recently we have a lot of interest in the financial world from
folks writing trading applications, where certain timing guarantees
need to be met.
In a world where
even
driving in a circle can get crazy, its good to know you can choose
Predictable if you need it.
Posted by dannycoward
( Aug 05 2008, 07:50:04 PM PDT )
Permalink