Does it make sense to implement a Garbage Collector in a Language with Garbage Collection

Question

I want to implement a garbage collector (GC) in Java or Haskell, but does this make sense?

Will I be able to control when my own implementation of the GC kicks in and not the GC of the implementation language?

I guess that there can be three kinds of answers for this question:

1. Set a flag when running the virtual machine (VM) that disables the GC of the implementation language.
2. Use a special construct that lets me manage my own memory, like using continuation-passing style (CPS) to manage my own evaluation strategy.
3. No, use a language with no GC.

Looking at these:

1. I prefer the second option since I will be able to use that construct in all languages.
2. I don't like the first option because I'll have to manage the memory of my interpreter as well.
3. (And I don't prefer the third option neither, but I can't control that)

This is not a duplicate of I build a interpreter on a language with a garbage collector. I need a garbage collector for the interpreter? as I do not want to bootstrap my interpreter with the underlying GC.

Answer 1

As so often in IT, the answer is: it depends.

When your interpreter keeps control of all "objects" within your context; then of course, your interpreter will probably keep a list of all "its" objects. So even when those objects would somehow be visible to the JVM, they would all be reachable, thus alive; so they could not be subject to JVM gc.

But when you somehow "embed" the objects that your interpreter deals with into the surrounding java context - then the JVM gc could be responsible for them.

Coming from there, the answer would go into the direction: yes, this could be possible. But beyond that; it really depends on your goal and driving requirements. Are you implementing this for pure education purposes; or are you interested in creating some sort of "real" product that is of "real" value to other people?

If the later is the case, then you probably want to embed your interpreter very tightly with the JVM - in order to benefit from the massive investment that turned the JVM into the great platform it is today. You see, almost 20 years of research went into current JVM JIT compiler and GC technology. Do you want to take advantage of that in order to "do your own thing" ...

So, as outlined: it very much depends on your "real" goals.

Finally: you might find this SE-Radio podcast on JRuby and the JVM platform helpful in the context of your question. The JRuby folks were simply not happy with the performance of the standard Ruby engine; and they choose the JVM as platform to build a better Ruby engine ...

Answer 2

Makes sense for what? If you want to implement your own GC just to learn the algorithms involved, it doesn't matter. A GC basically just manages resources that reference each other, until they don't. That's perfectly doable in Java and other GCed languages. Instead of freeing the memory, you'd just call another method on the object and remove it from a list of 'living' objects.

For a shipping product? Not sure. You can take advantage of existing mechanisms in the implementation language, but a GC in particular usually needs control over when memory should be relinquished. And if the implementation language prevents that, that's a problem.