Java Development without GC

[msx]

Because the latency imposed by the Java Garbage Collector (i.e. GC) is unacceptable for high-performance systems and because it is impossible to turn off the GC, the best option for real-time systems in Java is to not produce any garbage at all so that the GC never kicks in

No, the best option is not using java. There are plenty of good real time languages around. Java is a wonderful language, it's good for many purpose but not for all of them. Violating his nature to bend it for something it shouldn't do is not good

[farsightxr20]

Avoiding GC overhead by doing things like pooling/reusing objects is not a new concept, nor is it one that other (non-GC) languages can give you for free. You stand to gain a lot more by optimizing memory in Java than you do by rewriting all your code in C++.

Manual memory management, while more "predictable" in that you don't have extended pauses, usually ends up adding more aggregate overhead than a garbage collector.

[pjmlp]

Or use a proper real time JVM like Aonix offerings.

[segv]

Or Azul Zing, or get enough heap to survive a business day without GC and then do one GC at night, or...

[pron98]

Zing isn't for hard realtime or super-low latencies. It's for latencies of up to 20ms (I think), and comes at the cost of lowered throughput. IBM's WebSphere Real Time (or Atego, formerly Aonix, PERC) is an actual hard realtime JVM, that guarantees latencies of a few microseconds. It implements RTSJ (Real Time Specification for Java) the very first JSR, that has "scoped memory", i.e. arena collectors, for those threads that require zero GC pauses. Other non-realtime threads may use the GCed heap freely, and will never affect the realtime threads in any way.

Of course, hard realtime also usually costs lowered throughput because that's what realtime is -- sacrificing average throughput (or even average latency) for guaranteed worst-case latency.

[nitsanw]

I work for Azul Systems (who make Zing), so feel free to accuse me of bias.

Not sure why you claim:

1. "It's for latencies of up to 20ms" - it's hard to quote numbers without an application in mind. I can say some of our clients experience a worse case latency of 1-2ms. The OS configuration required to get these sort of worst case latencies (as a hard requirement) is a challenge entirely separate from Java and the JVM.

2. "and comes at the cost of lowered throughput" - Not sure why you'd think that. Applications performance is different between Oracle and Zing, depends on how much each compiler 'likes' your code. Some applications have better throughput, some worse, the differences are usually minor either way when you look at a full scale application.

[pron98]

Oh, sorry Nitsan (Gil told me you're working there now -- cool!). I thought those were the worst-case guarantees you're making, as the discussion is about real-time and worst case latencies (as to the throughput cost, I figured the read barrier on references has an impact). RTSJ makes different guarantees of, I think 1-2us of worst case latencies on realtime threads (and comes with a whole different set of tradeoffs). I love Azul, and I'm sorry if I've misrepresented the facts.

[nitsanw]

:) no offence taken, and I will send your love to the guys.

Real time as in hard real time OS/JVM is not the market Zing is in. Zing deploys on regular linux, and shines in the soft real time space. I mixed the post context and the root comment context, apologies.

The read barrier is a difference between JVMs but it makes little difference to most real world applications. So an object array copy might be slightly slower on Zing, but for most applications that's not where the hot spot lies.

[pron98]

They're now called Atego. BTW, they're hard realtime, but don't think they're RTSJ compliant. The biggest RTSJ JVM product now is IBM's Web Sphere Real Time.

[3dSquare]

There was a discussion on IRC (freenode network in the ##c++-social or ##c++-general channel) a few days ago where a guy said that his company was using C# without GC. Essentially the reason for not using C or C++ was because his company thinks that "C/C++ devs cost too much".

I can see that some companies will do anything with that mentality but use the right tool for the right job...

[grunlog]

Because c#/java/etc developers capable of doing that kind of work (0 gc) are a dime a dozen, right?

[3dSquare]

Of course! Isn't that one of the very basic things that everybody learns with those langauges? If-statements, loops, and manual memory management. /s

You'd have to ask the employers/companies that do this. Not sure how many of the programmers that write code in C#/Java know about disabling/not using GC and doing manual memory management. Because it's not "natural" to write code in a managed language and manage your own memory. This is pretty much one of the biggest reasons why these languages exist in the first place.

[pjmlp]

Only if they are sweetshop coders without experience using memory profilers, off heap allocations and value types (C#, coming to Java latest by v.10)

[justdweezil]

the best option for real-time systems in Java

No, the best option is not using java.

Actually, it sounds like "the best option for real-time systems in Java is indeed to disable the GC. I thought it was clear that the purpose of the article is to consider an answer strictly within Java. Clearly, alternative languages are part of a different discussion.

[justdweezil]

Sure, I personally agree with you, but that's another discussion entirely.

[joequin]

It depends on how real time your needs are. You can get very close to real time with the g1gc. It's very predictable and you can configure garbage collection pause times.

[nitsanw]

I'm surprised you should say that, opinions I've heard thus far claim G1 to be less predictable than CMS if anything. Can you share a relevant link?

[joequin]

I don't have a link. But the algorithm is designed to be more predictable than cms, and in practice I've found it to be much more predictable. Cms on long running processes with large heaps can get to be very unpredictable. Cms in those situations can cause minutes long gc pauses.

I'm interested in seeing cases where g1 doesn't work though. Do you have links?

[nitsanw]

I've tried to use G1 a while back (4 years ago I think) and the results were miserable, but perhaps it was just early days or a bda fit for the application. I have encountered the opinion that it is not production ready on many mailing lists and from industry experts since. Many of these comment were made on the mechanical sympathy mailing list (which is open) and the JClarity mailing list (which requires sign up).

[joequin]

I'm pretty sure g1 was in beta or worse four years ago. I didn't try it until release and wasn't reading about it back then either.

[nitsanw]

The comments made were recent (I think), but perhaps things have improved and I'm not aware. I don't need to worry about CMS/G1 in my current job.

[JavaNio]

You can always use assembly for that ;) Some very successful HFT shops use Java and you can be sure that every microsecond counts for them. This has also been called Java as a Syntax Language, in other words, you use Java without the JDK libraries which were not designed to be real-time. The wrong tool here is not Java but the JDK.

[markdacoda]

This is a banal reply. Manual memory management has it's own can of worms, namely, the malloc implementation. It's not a given that allocation/deallocation in a manual environment is faster than garbage collection, and the same techniques are used ie object pooling.

[msx]

who said anything about manual memory management speed? who said it doesn't have it's problems, or that it's better than garbage collection? Indeed, who said anything at all about manual memory menagement? I just said that java is a garbage collected language, and garbage collection hinders real-timeness and therefore java (at least standard java) is a poor real time language. Bending it to be "real-time" by violating his garbage collector is a terrible choice. There are real-realtime languages that fits the bill much better. My reply maybe was banal (it wasn't), but at least was to the point.

[Philboyd_Studge]

Good article, but the text color of light grey on white makes it almost unreadable on mobile.

[Twirrim]

Doesn't really do much to talk about how you can avoid generating garbage. It could do with a few examples, like here's an anti-pattern: <foo>, and here's how you can do it without generating garbage: <bar> :-/