The JVM handles the garbage collection for Java so if someone writes a JVM in a garbage collected language I would suspect two garbage collectors to be running (one for GO and one for the bytecode the JVM is running).
It would be an interesting concept to pass through Java objects for the GO garbage collector to deal with but that sounds incredibly difficult or impossible.
At least if you are interpreting the language just using the garbage collector of the host language will pretty surly simplify the design a lot. Actually a design where every Java object is simply represented by a Go object should give this for free.
It is actually very easy/simple. Imagine a piece of Java code that calls "new Object()". I don't program in Go, but essentially, the VM would create a temporary variable x := MakeObject(typename = "Object"). Then if that's assigned somewhere, the VM would store the record. When things go out of scope, the GC collects.
Ah I didn't see those so I'll have to take a look. The reason I thought it was very difficult and maybe even impossible was mostly because passing through to GO changes the behavior or Java to a point where it could cause some adverse affects in applications tuned or expecting it to work as the other JVMs work.
For many things that may be the case, but to my knowledge Java doesn't make any strict assumptions about garbage collection. You can get drastically different behavior just by passing different parameters to your JVM for instance.
As long as the Go garbage collection works, it shouldn't affect how the program runs. That's kind of the whole point of GC. Hell, you could write a toy VM with no garbage collection, and it would work fine until you blew your memory.
It would be an interesting concept to pass through Java objects for the GO garbage collector to deal with but that sounds incredibly difficult or impossible.