[ricccardo]

I think what he means is that Go's built-in GC cannot be used to handle GC for the JVM. So the developer probably has to develop a GC for JVM data in Go. But since Go is a GCed language, the implementation of the JVM GC itself will be GCed at times. So you have two nested garbage collectors.

[munificent]

> I think what he means is that Go's built-in GC cannot be used to handle GC for the JVM.

Sure it can, and that appears to be what this JVM does. There's nothing in the JVM spec that says you have to implement your own GC any more than you have to implement IEEE floating point numbers yourself. In fact, I don't think the JVM mentions GC at all. It just assumes infinite memory.

If your implementation platform (in this case Go and the Go runtime) gives you something, by all means use it.

[haberman]

> I don't think the JVM mentions GC at all. It just assumes infinite memory.

It seems like it must mention something about finalizers.

[munificent]

Actually, strangely enough, I can't find any mention of finalizers at all in the JVM spec. The Java spec does, of course, but I can't find it in the JVM spec.