4 ms·

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.

by perbu 3y ago

nightowl_games 3y ago
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.
- RetroTechie 3y ago
  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.
  - skitter 3y ago
    You're right, but that's what's meant - using the Go GC vs also implementing a custom one.
  - coldtea 3y ago
    >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.
karmakaze 3y ago
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.
- perbu 3y ago
  Thanks. That makes a lot of sense and isn't as complicated as I thought it would be.
perbu 3y ago
From the project page: GC is handled by the golang runtime, which has its own GC This is pretty cool, imo.
mbreese 3y ago
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”.
pjmlp 3y ago
Go GC is already written in Go.
paulddraper 3y ago
It'd be hard not to hook into the Go GC in an application written in Go...
coldtea 3y ago
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.

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.

by perbu 3y ago

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.

nightowl_games 3y ago

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.

RetroTechie 3y ago
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.
- skitter 3y ago
  You're right, but that's what's meant - using the Go GC vs also implementing a custom one.
- coldtea 3y ago
  >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.

karmakaze 3y ago

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.

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

perbu 3y ago

From the project page: GC is handled by the golang runtime, which has its own GC This is pretty cool, imo.

mbreese 3y ago

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

pjmlp 3y ago

Go GC is already written in Go.

paulddraper 3y ago

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

coldtea 3y ago

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.