References to java programs coded using primitives

Question

I've heard of Java programs with strict latency requirements where "new" instructions are never -or very rarely- used (because no new=>no objects->no GC=>improved latency)... instead all business logic is handled using primitives.

I couldnt find references to this technique online though... any link to a webpage discussing this technique or snippets of code would be much appreciated.

Answer 1

Update (March 2012): While there is no public announcement available, it appears Oracle has shut down their JavaRTS group.

The two topics you should look at are the Real-Time Specification for Java (JSR-1, JSR-282) and the Safety-Critical Specification for Java (JSR-302), (aonix page). RTSJ provides the resources for doing the type of careful memory management you are talking about in your question, though most of the users of RTSJ probably tolerate greater jitter than an "all-primitives" approach would (and, for that tolerance, they get the benefits of GC by using an RTGC). For some examples of the kinds of limited allocation (limiting when/where/how many times you can use new) search for "rtsj scoped memory rules", and here's an example academic paper on the topic. You should also look at "eventrons" as an example of trying to solve these high-frequency, low-latency constraints in Java in a (relatively) clean way.

For a specific new story on the use of JavaRTS in trading contexts, see here. For some instructions on how to get the most deterministic behavior out of JavaRTS in particular, see here.

Safety-Critical users are more likely to have these sorts of constraints, and SC-Java is (expected to be) partially a downscoped version of RTSJ. You can see some examples of what the expert group is looking at in Doug Locke's 2007 status slides from JTRES.

Several folks produce JVMs intended for use in this environment. Aonix/Atego's PERC; aicas' JamaicaVM; Apogee's Aphelion. The Sun/Oracle JavaRTS is targeted more towards larger applications that can tolerate (and benefit from) less stringent constraints.

While the "all-primitives" approach you cite is an extreme form of this type of programming, you are most likely to find resources around this topic at one of the above references.

For the "business logic in primitives?" naysayers above me, note that substantial amounts of IRS tax business logic is implemented in IBM assembler, and a number of "enterprise" layers like Java are being looked at to wrap (not replace!) that logic. Put that in your pipe and smoke it.

I can't cite any specifics here, but there are a number of defense applications using Java (usually a flavor of RTSJ) that have very tight constraints on memory allocation, and much of the code is statically-allocated, primitive focused. Signal processing, etc... I did a search for open source materials on systems I'm aware of, and these documents (see especially the references sections) point the way to some specific examples of these applications.

• http://www.aicas.com/papers/scj.pdf
• http://www.cs.purdue.edu/homes/jv/pubs/safecert09.pdf
• AN/FPS-85 SpaceTrack Radar: http://unix.org.in/2010/10/sun-java-real-time-system-selected-for-space-surveillance-radar-java-technology-enables-real-time-behavior-and-throughputaviation/ and http://www.globalsecurity.org/space/systems/an-fps-85.htm
• Army FCS: http://www.militaryaerospace.com/index/display/article-display/234337/articles/military-aerospace-electronics/volume-16/issue-8/news/aonix-hard-real-time-java-technology-useful-for-command-and-control.html

Answer 2

Check out the Realtime specification for Java.

Though it has rather more complicated rules w.r.t. allocation.

Answer 3

There might be some trading systems that do this, but from my understanding (My colleagues work in Java based low-latency trading platforms) a good fast modern JVM combined with sensible coding practice removes the need to go for 'pure primitives' in code. That said I'm not a low-latency developer, our middleware team only worries about 1,000's of txn's per minute, not 10,000's+. Can't say I've found a convincing article on this, although I'm happy to be pleasantly surprised :)

Answer 4

I have worked on a number of such systems. You will need to worry about creating objects if you need sub millisecond latencies. It is possible to write an application which doesn't GC all day, just to avoid any GC delays.

However, 99%+ of applications don't need this extreme.

Answer 5

I've used this technique in game programming, where too many long GC delays can degrade the user experience. In practice it's not necessary to eliminate all "new" instructions, just keep them to a sensible level.

A good example of a library that uses a lot of these techniques is Javolution - well worth a look if you are either interested in how it is coded or want to use ready-built data structures and algorithms that support operation with minimal allocations.

Answer 6

No, I have never heard of such programs, or even of the technique.

It seems like a bad idea, because then you are effectively limited to what you can do in C or similar low-level languages. And if you want that, it's easier to write in C. Plus there are many ways to avoid long GC pauses, and in practice most low-latency requirements can be met by them.

Plus, in order to do anything useful, you'll have to use the Java platform APIs, or other 3rd party libraries, which will probably allocate plenty of objects behind your back, so avoiding all object instantiations is probably not even practical in a non-trivial program.

So I am fairly certain that this is an urban legend, or at most a niche idea.

Edit:

This technique is used to obtain realtime or low-latency behaviour. Nowadays it might be obsolete because of better GC algorithms, but this will of course depend on circumstances. So it is probably something to consider at least for hotspots of an algorithm.

As an example:

Many Java realtime environments place some restrictions on object creation. This does not mean that they can only use primitives: Use of complex objects is still possible, but for example Safety Critical Java ( http://www.aicas.com/papers/scj.pdf ) requires all object instantiations to happen during an initialization phase. Once the application is running ("mission phase"), instantiation is no longer allowed, so you have to work with the object instances you have.

This avoids the unpredictability introduced by dynamic allocation and garbage collection, but still allows the use of dynamic memory (in a limited fashion).

Thanks to andersoj & mikera for explaining this to me.