Prof. Dr. Eric Bodden

Bryan Cattle recently explained why their autonomous car developed for the DARPA urban challenge did not make it: They simply had a memory leak in their C# code, filling up their entire heap space after about 28 minutes which made the computer crash. It’s important to note that this is not at all any flaw in C#. As C# is now, it was the programmers’ fault: In their code they kept around a list of obstacles which the car passed by. Obstacles that came out of sight were deleted… but not quite. Because the obstacles were registered as event listeners somewhere else in the code they were reachable and hence could not be garbage collected. Too bad, but how could such a problem have been avoided?

First of all, they were aware of the problem beforehand. They just did not know what was causing the space leak, i.e. which objects were referencing their obstacles. For Java-based programs Java 6 now brings quite handy support for solving such questions. If you use Eclipse Europa with a Java 6 JVM you can just have the Eclipse debugger show you all the references to a given object. This is great!

However, you could just as well have used association aspects or the relational aspects we proposed for next year’s AOSD conference. Using a relational aspect you can just implement your listener like this:

relational abstract aspect SimpleObserver(Subject s, Observer o) {
    abstract pointcut subjectChanged(Subject subj);

    relational after(): subjectChanged(s) {
        o. notify(s );
    }

}

This would automatically notify the observer o when subject s is updated. And the crucial thing about this: It automagically uses weak references for memory management! Hence, by default you get no space leaks at all. If o becomes weakly reachable, it will be garbage collected and the observer-relationship with it. If just more people would use such technologies. I am sure Bryan will consider it next time…