Bertrand Delsart's RTSJ WebLog: Real-Time Java related weblog

I've started to think about this blogs a few weeks ago. The frenzy about our recent release of our first RTLinux version of JavaRTS was a good occasion to rush thinks... and to stop trying to improve the attached program

Now that we run on Linux, you should be able to easily compare the main RTSJ based products. In fact, a few of our customers like the simplicity of our competitor's RTGC. Don't tell me you never heard about it, it is called Metronome ! When I was asked whether we could do the same, I answered no. I had not designed the GC to work that way. Then, I realized that it can behave similarly and, going further, you could tune it to something that fits your particular needs.

Our RTGC technology is very flexible. The GC work is performed by threads that need not run at the highest priority. Hence, our time-critical threads run at higher priority and are never preempted. This make is very easy to achieve hard real-time with our solution... and easy to know in advance what is the worst case execution time for these threads.

Now, soft real-time is harder. In soft real-time, there is a balance between throughput and determinism. It should depend on the customer needs. It tries to be less expensive... but sometime fails to guarantee determinism.

Metronome is relatively easy to understand. This GC is a periodic activity that runs at a higher priority that the real-time threads and very frequently preempts them... but for a limited time. For instance, every 3ms, you will be preempted for 1ms. Provided you trust than 1ms is enough to guarantee that memory will be recycled fast enough, you can easily compute the jitter/overhead on the execution of your threads. From 0 to 3ms of execution time, you will be preempted from from 0 to 1ms. From 3 to 6, you loose 1 to 2ms...

Our RTGC is more complex... because of its flexibility. You can decide what is the priority of the RTGC. You can even decide on how many CPUs it runs. The default RTGC policy it to try to maximize both throughput and determinism for the soft real-time threads... as long as the system is not to heavily loaded. The RTGC will run at a lower priority that any other real-time activity. When you increase the load, the RTGC does not have enough spare CPU cycles to recycle memory for the RT threads, hence we end up boosting it... preempting the soft real-time threads till it completes (unless they can run on the other CPUs).

Some of our customers would like to reduce this preemption time by giving more CPU to the RTGC even if they are not sure he will need it. I was thinking about implementing it in the next release and thought: "Wait a minute! No need to extend the JVM ! We can use the RTGC management code to do it... from Java !!!"

I started to write a very simple Java thread that periodicaly changed the default priority of the RTGC. In fact, I already like this approach better than the usual Metronome scheme because the RTGC was not idle during the 3ms period. If there was no real-time activity, it ran in preference to the java.lang.Threads, allowing the RTGC to complete faster and thus preempt the real-time tjhreads less often. This version is called PreemptionPolicy. With the monitoring code, you can see the priority changes:

GC prio set to 11
GC prio set to 39
GC prio set to 11
GC prio set to 39
GC prio set to 11
GC prio set to 39
GC prio set to 11
GC prio set to 39

I was going to publish it in this blog when I realized that I could do even better. Why not combining both approaches. When the system is not loaded, I would prefer the RTGC to run at priority 11. Hence, I should not change the default RTGC priority. Now, when the load is increased, the RTGC may be boosted. To avoid long pause times, I just need to temporarily lower that boosted priority. This version is called ConstrainedPolicy. When not loaded, the priority remaines at 11. When I tweak a parameter to boost the RTGC earlier, the priority varies as expected:

Activating the constrained policy
GC prio set to 11
GC prio set to 11
GC prio set to 11
Force the GC to be boosted early
GC prio set to 11
GC prio set to 40
GC prio set to 11
GC prio set to 40
...

Have a look at the corresponding Java code and output. Code is provided as is, without any guarantee. In fact, I made a few editorial changes before uploading this blog and will need to test the new version next Monday. I will let you know if there is any issue.

Go download our free evaluation of the Solaris product or the new Early-Access version of the RTLinux version to try it yourself. If you like these policies, why not to monitor your application behavior and dynamically change the policy depending on your expected load and desired behavior ?