Subscribe to our mailing list

* indicates required

Thursday, October 30, 2008

What's the strangest thing in Java?

There's an interesting discussion going on at right now. Someone asked "What’s the strangest thing about the Java platform?"

I can think of a lot of strange things about Java (space precludes a full enumeration here). Offhand, I'd say one of the more disturbing aspects of Java is its ill-behaved (unpredictable) System.gc( ) method.

According to Sun, System.gc( ) is not 100% reliable: "When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects." Notice the wording ("best effort"). There is absolutely no guarantee that gc() will actually force a garbage collection. This is well known to anybody who has actually tried to use it in anger.

The problem is, in the rare case when you actually do need to use gc(), you really do need it to work (or at least behave in a well-understood, deterministic way). Otherwise you can't make any serious use of it in a mission-critical application. Not to put too fine a point on it, but: If a method is not guaranteed to do what you expect it to do, then it seems to me the method becomes quite dangerous. I don't know about you, but I rely on System calls to work. If you can't rely on a System call, what can you rely on?

Suppose you've written a reentry program for a spacecraft, and you have an absolute need for a particular routine (e.g., to fire retro-rockets) to execute, without interruption, starting at a particular point in time. The spacecraft will be lost and the mission will fail (at a cost to taxpayers of $300 million) if the retro-rockets don't fire on time or don't shut off on time.

Now imagine that just as your program's fireRetroRockets() method is entered, the JVM decides to "stop the world" and do a garbage-collect.

Houston, we have a . . . well, you know.

The point is, if you could call System.gc( ) ahead of time, and count on it doing exactly what you want it to do (collect garbage immediately, so that an uncommanded GC won't happen at the wrong moment), you could save the mission. (Arguably.)

Obviously, this example is somewhat academic. No one in his right mind would actually use Java to program a spacecraft, in real life.

And that, I think, says a great deal about the Java platform.


  1. It sounds like you actually want one of the many real time JVM implementations... which could theoretically run a spacecraft.

  2. Thanks for the input, Bob. I don't plan to build a spacecraft at the present time. However, I would be very happy to at least be able to use Java to create 800x600 animations that run at 15+ fps without stuttering (as the JVM stops to collect garbage) every few seconds. You have a good point. Realtime JVM... I'll look into it. Thanks!

  3. What you've described is not strange at all... it's a well-known behavior with any system that uses garbage collection.

    In the old AI days, so the story goes, they created a robot that could play ping-pong with a pool cue, batting the ball back to its human opponent with just the tip of the cue. Very impressive. Up until the point the program spazzed out and hung while it garbage collected, the ping-pong ball bouncing merrily past the frozen robot. The program you see was written in Lisp, which like Java does garbage collection whenever the hell it feels like. =)

    There's a reason real-time programming requires a slightly different approach and specialized knowledge and experience to do it effectively. Garbage collection is only one of the quagmires, and as I said it's not all that strange.

    As for your statement
    "Obviously, this example is somewhat academic. No one in his right mind would actually use Java to program a spacecraft, in real life."

    You make a leetle joke, yes? =)
    I know of at least one defense contractor company that was designing a real-time system for on-board command-and-control for a military platform. Scary. In your example, a satellite might be lost. Pffft. They were building a system that could cost the lives of a thousand or more US military personnel if it real-time pooch-screwed during a battle. And they were writing it in Java. Using one of the real-time JVM implementations, to be sure, but my initial investigations suggest real-time Java is an oxymoron, at least for now.

    Have you ever driven a car at 60 mph and all of a sudden have the engine cut out, just die? I have. And that was just a faulty electronic fuel injection system. Imagine the 20 or so computers in your current car, all controlled in real time by Java... imagine you and your family in that car, barreling down the road at 70 mph... hiccup

  4. Thanks for the input, Tinker. What I'm calling "strange" is not garbage collection behavior per se, but the fact that Sun won't guarantee that System.gc() does anything when you call it! To me, that's strange. I realize there may be good reasons for this behavior; perhaps by the very nature of the garbage collection algorithms Sun uses, executing gc() at the wrong time could cause a reentrancy problem or leave something in an unpredictable state, etc. That's fine. In that case, don't give me a gc() method at all. Especially don't give it to me and then tell me not to use it. (Sun, as you know, urges programmers not to try to manage garbage themselves.)


Add a comment. Registration required because trolls.