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