Hacker News Reader

Comment by bullen | Hacker News Reader

So Go GC + Java GC?

No. It’s using Go’s built in GC: https://github.com/platypusguy/jacobin#garbage-collection

The Go GC could be the Java GC.

Then it would be hard to write this in Go. Can't see how you'd be able to hook into the Go GC in an application written in Go.

From TFA:

> An important factor in reducing the size of the codebase and executable is that Jacobin relies on Go’s built-in memory management to perform garbage collection, and so it contains no GC code.

I don't see how you can't see it.

I can see how using Go's GC reduces the codebase.

But I don't see how that reduces binary size.

Compiled Go programs include a Go runtime in their binary, correct? (statically linked).

So if Go program uses Go's builtin GC, that GC wouldn't be part of the program code, but would be part of the runtime that it's packed with in the binary, right?

In essence replacing [GC in Go program part of the binary] with [GC in Go runtime part of the binary].

I mean, I can see the advantage(s) there. But reducing binary size doesn't seem to be one of them. Unless you count [Go program using its own GC + the one in Go runtime] vs. [only the one in Go runtime].

It's still a (read: at least 1) GC included in the binary.

You're right, but that's what's meant - using the Go GC vs also implementing a custom one.

>But reducing binary size doesn't seem to be one of them. Unless you count [Go program using its own GC + the one in Go runtime] vs. [only the one in Go runtime]

Yes, of course that's what they mean. Not having 0 code for GC altogether, but just using the GC that you already have, and is required overhead, as opposed to implementing another and having both.

Every Java reference to an object can be a reference to the allocated Go object for that object. The Go objects are the Java objects with no extra indirection. The Go object would be bytes with each reference field being a struct with a pointer. There should be a low level use these bytes for 'allocating' this object.

Thanks. That makes a lot of sense and isn't as complicated as I thought it would be.

From the project page: GC is handled by the golang runtime, which has its own GC

This is pretty cool, imo.

You couldn’t necessarily “hook into” it from the Java side, as it would be an opaque interface. But the Go side would make the Java GC process “just work”.

Go GC is already written in Go.

It'd be hard not to hook into the Go GC in an application written in Go...

I believe it's a quit common practice to delegate the GC needs of a GC-language implemented on top of another GC-language, on the latter's GC.

As long as the language is GC agnostic, and just cares for stuff being collected, and not for some particular exposed semantics of the GC, it should be ok.

Inception GC

only go's gc. there's no gc code, if I read correctly.

Reply on news.ycombinator.com