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

If you write a program in Java, GC of JVM will automatically manage memory for your program. You now want implement a new GC for another programming language, but it is also a program. So GC of JVM will manage memory for your own GC, then your own GC will manage memory for target programming language.

The question is, if the GC of JVM stop the world, it will stop your own GC, your own GC will also stop the world for your target programming language.

So, yes, you can implement your own GC in Java or other language with GC, but it not necessary. If your own GC will not be managed by other GC, that's ok.

Answer 2

You've clearly already made up your mind about this question. It is possible, remotely, that a GC scheme one comes up with would somehow be better than what the JVM supplies already. But consider this: of all the languages that have been ported to the JVM, by all the brilliant developers out there, how many have not leveraged the JVM, including its GC?

Still, this is a matter of opinion and experimentation. Hopefully we'll all have the wisdom to cast an idea as an hypothesis and seek to disprove it before spinning in a potentially wrong direction. If it withstands disproof attempts, then go for it

I recommend actually programming different approaches with a relatively robust example application of your own devise. Figure out a metric for GC effectiveness. Figure out how much effort it takes you to write your own, and how it affects the metric for good or ill. Your own experience then will guide you.

Answer 3

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 4

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.