Bertrand Delsart's RTSJ WebLog

Want a Metronome like RTGC ? Do It Yourself in Java RTS...

Example of RTGC control from the Java application to make it behave similarly to other RTGC technologies. [Read More]

Posted at 07:34AM Feb 04, 2008 by delsart in Sun  |  Comments[2]

Java RTS product documentation has been updated

Thanks Antonia for updating the product documentation.

Of course, the first one to look at is the RTGC doc

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 application !

Bertrand

Posted at 05:00AM Dec 05, 2007 by delsart in Sun  |  Comments[0]

Java RTS 2.0 Update1 Released

Hi all,

I've not been very active on my blog because, in addition to my technical leader tasks and the work on the real-time garbage collector, I was also the release leader for our latest 2.0 update release.

Now the baby is out ! Go download it .

In addition to security enhancements in the JDK libraries, we greatly improved the tools support, particularly with the DTrace probes that will allow you to debug your timing issues.

The evaluation bundles are available for download. The documentation browsable on the web will be updated shortly but the one in the bundles should be up to date. I'll keep you informed.

Bertrand.

Posted at 02:56AM Nov 29, 2007 by delsart in Sun  |  Comments[0]

I'm back... with a brand new real-time garbage collector.

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

If you are French, you might prefer a presentation I gave during Sun's TechDays in Paris: http://java.developpez.tv/suntechdays2007/#vid14.

In addition, you can read the documentation of our Java RTS product to find even more information about the RTGC. 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.

Bertrand.

Posted at 03:26AM Oct 18, 2007 by delsart in Sun  |  Comments[0]

Real-Time Java Programming: RT-GC versus RTSJ ?

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 your needs.

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 RTSJ !

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.

Posted at 12:21AM Dec 13, 2005 by delsart in Sun  |  Comments[0]