When implementing an interpreter, is it good or bad to build a garbage collector in the host language?

Question

Suppose you are using an interpreter for the GCed language in the GCed language. It seems to me that you will get a free garbage collection if you are careful enough in your design.

How is this even done? Is there any good reason not to do this?

Answer 1

Language and runtime are two different things. They are not associated with IMHO.

Therefore, if your existing runtime offers the GC already, there must be a good reason to extend the runtime of the other GC. In the good old days, when memory allocation in the OS was slow and expensive, applications brought their own cumulus managers, which are more efficient when working with small pieces of data. It was one readon to add another memory management to an existing runtime (or OS). But if you are talking about Java, .NET or so - they should be good and efficient enough for most tasks.

However, you may need to create an appropriate interface / API for memory and object management tasks (and others) so that your language’s runtime (“guest”) can be implemented later in another runtime.

Answer 2

There should be no problems for the translator using the GC host, IMHO, especially in the first place. As always, their goal should be to make something work, and then make it work correctly, and then do it quickly. This is especially true for domain languages ​​(DSL), where the goal is a small language. For them, the implementation of a full GC will be excessive.