A lot of the features have already been described in the blogs that were written when the early access version became available. Check for instance Jim Connor's or Roland Westrelin's weblogs. Hence, I'll focus on memory management improvements.
Of course, the first point is that the Java Heap can now be bigger. With the 64-bit version, the size of the heap is now limited mostly by the physical memory available on your system. In addition, since the RTGC is fully concurrent, JavaRTS scales well: a bigger heap does not increase the pause times. Even if we have not yet seen a customer application impacted by fragmentation issues, a bigger heap offers an additional safety margin. The 64-bit drawback is that we do not yet support compressed oops. Hence, we suffer from the usual small throughput penalty due to the bigger size of the pointers. However, since the RTGC runs less often and recycles memory more efficiently when the Heap is very big compared to the live data, throughput can in fact improve for memory intensive applications.
The second point worth noting is the auto-tuner. We have worked with Sun Research Labs to improve the out-of-the-box soft real-time experience, optimizing the frequency of the RTGC cycles. The new auto-tuner is more precise. It also learns faster, improving the determinism for the first GC runs. Finally, it monitors the memory consumption and is able to better react to load changes. In fact, it will memorize information on the different loads and gradually learn how the application behaves. This should ensure that the RTGC is less likely to have to be boosted and disrupt the soft real-time threads. For more information, have a look at Sun labs technical report TR-2009-186.
For those familiar with the previous versions of the product, we have also reduced the number of CPUs used by default for the RTGC. It is still overestimated so that the auto-tuner should always be able to start the RTGC often enough to cope with the allocation rate. However, it no longer uses by default all the available CPUs. This allows even java.lang.Thread to benefit from our pauseless GC in the default configuration.
Thanks Antonia for updating the product documentation.
Of course, the first one to look at is the
More seriously, if you have started to use the technology, please try
our early-access version of the
DTrace probes .
We have found them very helpful to identify jitter
sources in running applications. In future versions, we will use these
probes to build tools that simplify the debugging of timing
issues. However, I really recommend trying to write your own DTrace
scripts. Without DTrace to help us debug the Java Virtual Machine, we
would not have been able to reach such a good determinism in Java
RTS. Now, you'll be able to use it for the determinism of your Java
Sorry, I was supposed to come back and tell you more about ScopedMemory and RTGC. A lot of things happened and it seems I missed the deadline
The good news is that I have been very busy working on a new real-time garbage collection technology. The results have exceeded our expectations. I've not yet published papers about it but you can find a lot of information in a few presentations.
The best reference was the
technical session TS2901 given during JavaOne'07. You can easily access the slides. If you are curious, you can also listen to me speaking in english
In addition, you can read the documentation of our Java RTS product to find even more information about the
This documentation is still an ongoing work. Please provide your feedback, I'll try to answer any question in my blog... and in future documents.
Thanks to these achievements, ScopedMemory should be used only by customers that really have very high determinism requirements (a few tens of microseconds).
This new RTGC is sufficient for most of our customers... and I'll probably focus on it in my next blogs.
Here is my first weblog on Real-Time Java™ issues. Well, this is
in fact my very first weblog and I hope you will be forgiving. To
make it even worse, English is not my native language... I'm french
Let's start with a few words about myself to explain while I am the
one writing this weblog. I have been working for ten years on ports
and implementations of Java Virtual Machines, both for servers and
embedded systems. Two years ago, I joined Sun Microsystems to work
with Greg Bollella on the implementation of the Real-Time Java
Specification™ (RTSJ) on top of HotSpot™ (go to
http://java.sun.com/j2se/realtime/ for more information). As the
most senior engineer of the team, I participated to the design of most
of the components and I was in charge of their global integration. The
major part of my contributions was on the memory management,
particularly the new memory model based on ScopedMemory, which allows
hard real-time threads to allocate memory without relying on the
garbage collector. I am now focusing on the alternative, real-time
garbage collection. In addition to the knowledge of the JVM, the team
has been interacting with a lot of early access customers, both during
training sessions and on the feedback mailing lists.
As a result, I am aware of the limits and the defaults of both
real-time garbage collection and ScopedMemory ! Fortunately, each
approach has a few advantages and I do believe they are
complementary. I'll explain it further in future weblogs.
For now, let's just say that we initially focused on ScopedMemory to
prove that we could achieve with the Java language a behavior as
deterministic as what is doable with other languages (response times
in the 10 to 20 microseconds range). This is done while keeping most
of the advantages of the Java language, including the safety of the
memory management, which prevents memory corruption. Of course, there
is no free lunch. The drawback is that to offer this safety without
impacting the response times, constraints had to be added to the
programming model. The alternative is to use real-time garbage
collection. Response times go up to a few milliseconds. If this is
sufficient for your needs, you may have to pay for CPU and memory
overhead induced by the GC but it is worth the price in terms of
productivity. As a conclusion on the memory management, use
ScopedMemory only if real-time garbage collection does not fulfill
However, the important message in this weblog is that the RTSJ is not
only about memory management. A lot of people think that having a
real-time garbage collector will be sufficient to solve their
real-time needs. My opinion is that the reasons that made them choose
the Java language should also make them consider using the RTSJ. The
gap between the Java languages and the other languages comes from:
a portable programming environment with a very rich set of libraries
a very robust runtime environment, with dynamic checks allowing users
to recover from unexpected errors.
With respect to real-time, there is a similar gap between your current
JVM and a JVM that implements the RTSJ.
First, in terms of libraries, the RTSJ provides a very rich set of
APIs... too rich to explain in a single weblog. For instance, the RTSJ
provides first-grade support for asynchronous activities. Imagine that
instead of providing a single handler to a limited set of POSIX
signal, you can create new events and attach several handlers to each
of them. In addition, each handler can run at a different priority and
you can do anything you want into these handlers... including
blocking! It will be up to the Java Virtual Machine to optimize the
resources and efficiently create/schedule/recycle execution
environments for these handlers. This goes much further than what
other real-time programming environments offer. Another API that is
worth mentioning is the RawMemoryAccess API. Instead of having to
write your own native method to access a physical resource (like a
device), it can be done with a Java method. Since this is a standard
API, a smart compiler will be able to inline this API call, making it
much more efficient than a native call.
However, the real gain of the RTSJ is that all these APIs include
dynamic checks that allow you to detect and solve temporal issues.
This is particularly important if you consider that temporal issues
are much more complex and unpredictable than for instance null pointer
or array index errors. Even better, a lot of these temporal issues are
automatically solved. For instance, you can manage CPU burst due to
the arrival of a huge flow of events. For each handler, you can easily
specify what to do if it is released too frequently. You can for
instance let the system ignore or defer the following releases. This
allow you to easily define the worst-case CPU overhead due to the
handling of asynchronous events. In fact, an implementation of the
RTSJ can optionally provide a feasibility algorithm that checks that
you always have enough CPU power to execute the periodic threads and
aperiodic handlers you have defined. Even without the feasibility
analysis, a JVM must at least provide deadline miss detection. Hence,
if a thread does not get enough CPU to perform its work, you can
easily register a (higher priority) handler to take a corrective
action and keep your system stable. I think that with respect to
robustness, this single feature is sufficient to justify using the
As a conclusion, whether you switched to Java for the portability of
its environment or for its execution robustness, you should consider
using the RTSJ for similar reasons (provided you have real-time
constraints ). Do not get afraid because of ScopedMemory. Its use
can be limited to a small subset of your program... and completely
avoided if a real-time garbage collector is sufficient for your needs.
In fact, my feeling is that it would be even better to mix the two
approaches, using ScopedMemory only for the hardest of your hard
real-time threads (to achieve the smallest possible deadlines and be
confident you will always get the memory you need in these critical
threads). I'll try to convince you in future weblogs.