Real time Java

General Discussions
#1

I just posted this over at gamedev.net in response to yet another thread about Java performance for games etc. Leaving the uninformed criticisms of speed behind, one true issue is the non deterministic behavior caused by garbage collection. Well there is someone working on the problem, and I’ve seen information at javalobby and in JDJ, but a search here turned up no information so I thought I would throw it out there:

[quote]Non-deterministic behavior is truly the reason Java has struggled for real time applications, but if you are willing to add a little to the learning curve a solution does exist:

http://javolution.org/

btw, the author has used this library along with a homegrown OpenGL interface to write hard realtime air traffic control software for the airline industry. There is a pdf presentation on a NASA site:

http://spacecom.grc.nasa.gov/icnsconf/docs/2003/05_B2/B2-07-Naqvi.pdf
[/quote]
heh heh, I just quoted myself :stuck_out_tongue:

Oh the slides also outline their approach to essentially replacing Swing with OpenGL and letting the graphics card do almost all of the UI work. While they open sourced the real time libraries they did not open source that part. I emailed the author but got no response about it…

#2

What a strange coincidence! I haven’t read gamedev.net forums for six months and last night I had a look and spotted that thread. I was so aghast I didn’t bother replying to it - it’s amazing how nothing’s changed at all in there.

In another strange old coincidence, this is how the LWJGL came about. I was bidding to do realtime TV graphics and I needed to get some code together that worked. The first incarnation, JGLIB, was open sourced and became LWJGL, and we ditched AWT completely in LWJGL to allow people to write their own GUIs entirely in OpenGL. It works a treat. See Quix, Alien Flux, and Tribal trouble for examples of proper GUIs in OpenGL!

The realtime problem in Java is a little overblown, and the solution is a time-bounded garbage collector that could guarantee collection of ‘n’ bytes of space in ‘m’ time. The solution presented in the library isn’t really a realtime solution, but it’s very similar to some techniques I used in Alien Flux, just much more complicated :wink:

To my mind, it should be entirely possible to create a garbage collector that can make guarantees about the time it takes to allocate a certain number of bytes; and therefore, the worst case time for any method is its normal execution time where the cost of every new() operation is the guaranteed GC time. Maybe we’ll get such a collector in 1.6 (6.0?) but until then the existing collectors are close.

Another issue is the fact that new() can throw an OutOfMemoryError. How does realtime cope with that? Perhaps a realtime collector could be quite trivially implemented to collect when it has to but if it breaks its bounded time limit it has to throw an OutOfMemoryError instead. Which the application should deal with anyway.

P’raps.

Cas :slight_smile:

#3

[quote]and the solution is a time-bounded garbage collector that could guarantee collection of ‘n’ bytes of space in ‘m’ time. The solution presented in the library isn’t really a realtime solution, but it’s very similar to some techniques I used in Alien Flux, just much more complicated :wink:
[/quote]
don’t we (almost) have that already? I thought there was a JVM flag that let you specify max number of nanoseconds spent on any one GC.

(although I’m probably much mistaken :-/)

#4

There is such a flag, but it’s not hard realtime, nor even soft realtime for that matter. It’s a tuning goal, not a guarantee.

Cas :slight_smile: