Tuesday, June 15, 2010

Taking Out The Trash

Most (all?) dynamic programming languages these days use a garbage collector. Even some static languages use a garbage collector. This is generally considered a good thing. Google can help convince you of the benefit.

Unfortunately garbage collectors have a couple downsides. One downside is that they tend to conflict with parallelism, a growing problem with today's abundance of multicore processors. The main disadvantage, however, is the pause in processing when the garbage collector pauses processing to clean the heap. This means that real-time processing (audio, video, games) can't be done in today's high-level languages. The typical solution is to rely on an external library written in a language without garbage collection, typically C or C++.

Perhaps all we need is better garbage collectors. What I think, however, is that we need some means of designating which portions of code a garbage collector may interfere with. Honestly I have no idea what I'm proposing, but I like dynamic languages like Ruby and Javascript far too much to decide that I have to simply rely on a different language for real-time code.

No comments: