Hacker News Reader

Comment by pcwalton | Hacker News Reader

> Garbage collection is currently only supported on ARM microcontrollers (Cortex-M). For this platform, a simple conservative mark-sweep collector has been implemented. Other platforms will just allocate memory without ever freeing it.

Conservative garbage collection has serious problems on 32-bit. Stuck pointers happen quite often. The usual culprit is floats, which thankfully don't usually appear in embedded code, but by no means is the problem limited to floats.

View on HN

Oops, those docs need updating. The GC now works on all platforms (including RISC-V and WebAssembly!) except for AVR because the AVR backend is just too unreliable at the moment and you wouldn't want a GC in 2kB of memory anyway.

GC works even in WASM? That's great! What size wasm targets does TinyGo generate compared to the regular Go compiler?

It produces much smaller binaries My blog post on it -> https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168

In the (reasonably simple) stuff we've been doing so far, TinyGo produced wasm files are 2-3% the size of mainline Go produced wasm files. eg:

https://justinclift.github.io/tinygo_canvas2/ (~19.5kB)

https://justinclift.github.io/tinygo-wasm-rotating-cube/ (WebGL, ~12kB)

That's wonderful to hear, I just wish I had learned about it sooner. I kept looking back at TinyGo for WASM tasks, because it looked like the right combo of size footprint and runtime capabilities, then ultimately thinking "hmm but the GC issue."

I'll probably take a look later today!

Can you elaborate? How are pointers to floats problematic? Or is it something else?

Conservative GCs don't know which bytes in memory are actually pointers, so they treat every word in memory as being a pointer if it looks like one. This means if you have some other value that happens to look like a pointer — in this case a float — the GC will think it's pointing to some other memory and keep that memory around even though it isn't used.

Conservative GC is pretty much: look at all reachable memory, whatever looks like a pointer to a range which is allocated keeps that range allocated.

Pros: you don't have to care about type information and precise stack/structure walking.

Cons: If you have range 0x8000-0x8010 allocated, and have a variable with integer value 0x8001 somewhere in the memory, it will keep that range allocated. It doesn't matter that it's an int, not a pointer. Floats and 32-bit pointers have quite a lot of accidental collisions that way.

Because 1.0 is 0x3f800000, which is often right in the middle of the heap.

Also, even on 64 bit machines, conservative GCs often just do a naive scan of the stack. And of uninitialized values on the heap. This means that garbage may be treated as live. Garbage often includes pointers that should no longer be live.

I don't believe go can have uninitialized values. every variable has a default "zero value"

Not on the heap, but it can certainly have uninitialized variables on the stack. These cannot be created in normal Go code but the optimizer may decide to leave some values uninitialized when it determines that this is safe to do.

Also they're targeting a BBC:Microbit, which has an nRF51822 - the smaller version with only 16 kB of RAM. 16 kB! How is garbage collection going to work here for anything but the most trivial examples?

You can run MicroPython on the nRF51822. That's a GC language. I've ran some fairly complex programs on it.

Lack of careful programming and you run out of memory, but that's more a function of assuming you have a large memory space, not GC in general.

I think the person you’re replying to means a GC that needs headroom, not a GC like Python’s which generally doesn’t.

FWIW micropython replace's cpython's refcount-with-cycle-breaker by a mark-and-sweep GC: https://github.com/micropython/micropython/wiki/Memory-Manag...

I have some trouble seeing the point of a Go compiler/implementation without any working GC, or with the only GC being a problematic mark+sweep implementation. Is this just a proof-of-concept effort, or do they expect to add workable GC down the line?

Personally, I welcome all comers, regardless of intent or completeness. That they offer a minimal refcounted implementation for the platform more likely to need it sooner seems to signal good intent.

I say this watching 30+ years of alternate implementations of different languages and runtimes. Even those that failed (or maybe moreso) indirectly inspired positive changes in the survivors.

I don’t know go, but it almost certainly lets you write non-idiomatic go code that doesn’t use GC allocated memory? Usually languages not designed for systems programming have these features for interop purposes (ffi, p/invoke, etc).

Although if that’s the case, I personally don’t get the draw. Typically these managed/higher-level/interpreted languages are harder to use than the embedded-friendly alternatives if you’re not using their automatic memory management. But a lot of times people just want to stick to (really weird and distant) versions of languages they already know/use (D is probably the only exception here for obvious reasons).

While I have no insight to their plans, perhaps a non-GC toolchain could still be used for short-lived programs (such as command line tools)? Don't even need to free anything if it's short enough, the OS can deal with it when the process exits

You can already do this: GOGC=off [1]

[1] https://blog.cloudflare.com/go-dont-collect-my-garbage/

>a non-GC toolchain could still be used for short-lived programs (such as command line tools)

Or missile firmware: https://groups.google.com/forum/message/raw?msg=comp.lang.ad...

https://tinygo.org/usage/important-options/ Take a look at the `-gc` flag. The values have changed in the latest version (need to update the docs!) but it does provide an option to disable the GC entirely.

The conservative mark-sweep implementation was the easiest to write: I don't think there is any real GC that is simpler. In the long term, the plan is to add other GCs that are precise and can be used in a real time context. However, note that such a conservative mark-sweep GC is good enough for many use cases already (look at MicroPython!) and that other GCs will likely cause additional RAM/flash bloat.

Depends on your definition of embedded.

Reply on news.ycombinator.com