"a realtime system must have a deterministic time to complete a task".<p>Incorrect, a realtime system must only have execution times below a certain threshold. malloc/free is just as non-deterministic as GC allocated memory (in practical systems). If you put effort into it you can make malloc/free do really stupid things too. If I wrote a program that allocated and freed the right size strings the program would eventually crash.<p>With any sort of modern CPU it would be almost impossible to produce non-trivial programs with deterministic execution times. I'd hazard a guess that there are very few 'realtime' programs that couldn't be written using the JVM. If you can do HFT on the JVM it's realtime enough.<p>To make systems with deterministic execution times you'd have to start looking at extremely limited processors that lack RAM (or have really exotic ram that doesn't refresh), as well as removing other resources that are essential to building software the modern way.<p>All this proves is that for this particular problem the JVM is probably unsuitable for a realtime system. The fortunate thing is that I don't think any real time program actually needs to allocate strings in this manner.<p>In all seriousness most of the reason that the JVM is not used on realtime systems is because there aren't very many cheap CPUs capable of executing java byte code that are certified for operation in the harsh environments that a lot of realtime systems operate in. My friend builds realtime systems and he codes in C because that's the only compiler available for the CPU.<p>He'd start using Netduino in a heartbeat if it could survive being next to an electric generator inside the Hoover dam.
Having done some hard-core real-time programming in the past, and currently thinking about a low-latency benchmark between languages, I am not sure that this sort of test is useful in a real-time environment. Also, using a garbage-collected language in a real-time environment would require some extra care.<p>One of the things to consider in engineering a real-time environment is what is the central data-flow load of the system. For example, in a medical data-acquisition environment, allocating an object for each tick would not likely be wise. In fact, use of malloc might not be called for, statically allocating buffers being a better avenue.<p>In the case of a low-latency financial trading system written in a garbage-collected language, it might be prudent to allocate all the objects before 0830 (if that is when trading starts) and free them after the market close.<p>There is a wide range of real-time response requirements (for financial exchanges, response times of less than a hundred of milliseconds (eg, 395 from BATS) for full turnaround are expected). Electrocardiogram data needs to be sampled once each millisecond, but the jitter in sampling times needs to be low.<p>Looks like some good tools there, but without the engineering context it is hard to draw a useful conclusion.
A microbenchmark like this is not very conclusive. The G1 collector is designed to handle the heap fragmentation problem and thus reduce the maximum pause time due to stop-the-world GC. It's not designed for maximum throughput.<p>Each GC algorithm has its worst-case behavior; saying "avoid at all costs" because of a single scenario is not very helpful.<p>Also, what were the JVM flags for each test? All I can see in these graphs is the bump at the beginning before the heap has sized to a stable level.
Your graphs make it very hard to compare the performance of the different collectors. What about putting all of them in the same plot, making that logarithmic, and include cumulative time (on a separate linear axis)?
The G1 Garbage collector isn't certified for realtime operation. If you want a Java VM that's certified for HARD realtime, you can check out IBM's latest real time GC policy that I believe came out with IBM's Java 7.
G1 is still under active development, but even with ideal implementation it wouldn't shine best performance<p>Reason 1. G1 is using SATB write barrier which is more expensive than crad marking barrier other HotSpot's collectors are using<p>Reason 2. G1 have to use STW pause to move object around. E.g. if your heap is fulled in half we life objects, you have to physically move 1MiB live data in memory to reclaim 1MiB of free space, cleaning sparse regions first will effectively reduce this proportion but G1 is still have to work very hard to reclaim each meg of free space<p>If you need low pause GC in JVM today. use concurrent mark sweep
<a href="http://java.dzone.com/articles/how-tame-java-gc-pauses" rel="nofollow">http://java.dzone.com/articles/how-tame-java-gc-pauses</a>
<a href="http://aragozin.blogspot.com/2011/07/gc-check-list-for-data-grid-nodes.html" rel="nofollow">http://aragozin.blogspot.com/2011/07/gc-check-list-for-data-...</a>
Your test is only one very specific scenario. I'm not a GC expert, but on EtherPad, which was a very complex monolithic JVM app, we had to turn to concurrent GC as the default GC just choked with any settings. If you haven't seen much difference between GC settings in the past, have you actually worked on realistic systems that strain the JVM GC, versus your contrived one?<p>I don't know the semantics of "real-time" (argued in other comments), but if you are coming from that angle, maybe you are looking for guarantees -- it seems like there ought to be a way to write GC so that it just works no matter what you throw at it, and it seems like G1 is not that.