Hacker News Reader

Comment by jaytaylor | Hacker News Reader

glancing through the source code I don't see any reason there would be double gc pauses. This appears to be a full jvm, not exec.Command("java", ...).Run().

View on HN

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.

Such schemes are not impossible, as Servo does something similar: https://blog.mozilla.org/research/2014/08/26/javascript-serv...

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.

But that's exactly what he does if you read his (poorly translated) blog posts.

I think it's actually much simpler to do it this way. It keeps the mapping between Java and Go constructs much tighter.

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.

Still a cool project either way.

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's actually much easier to just use the host language's memory model. Writing a GC is much harder.

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.

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.

> 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.

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

It seems like it must mention something about finalizers.

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.

Reply on news.ycombinator.com