4 ms·

> Garbage collection is currently only supported on ARM microcontrollers (Cortex-M). For this platform, a simple conservative mark-sweep collector has been impl

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

learnfromstory 7y ago
Can you elaborate? How are pointers to floats problematic? Or is it something else?
- munificent 7y ago
  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.
- viraptor 7y ago
  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.
- pcwalton 7y ago
  Because 1.0 is 0x3f800000, which is often right in the middle of the heap.
0815test 7y ago
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?
- tyingq 7y ago
  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.
- ComputerGuru 7y ago
  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).
- mook 7y ago
  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
  - iampims 7y ago
    You can already do this: GOGC=off [1] [1] https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/
  - 7y ago
ori_b 7y ago
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.
- compsciphd 7y ago
  I don't believe go can have uninitialized values. every variable has a default "zero value"
  - aykevl 7y ago
    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.
wbl 7y ago
Depends on your definition of embedded.
IshKebab 7y ago
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?
- opless 7y ago
  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.
  - chrisseaton 7y ago
    I think the person you’re replying to means a GC that needs headroom, not a GC like Python’s which generally doesn’t.
    - masklinn 7y ago
      FWIW micropython replace's cpython's refcount-with-cycle-breaker by a mark-and-sweep GC: https://github.com/micropython/micropython/wiki/Memory-Manager https://github.com/micropython/micropython/wiki/Memory-Manag...
aykevl 7y ago
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.
- owaislone 7y ago
  GC works even in WASM? That's great! What size wasm targets does TinyGo generate compared to the regular Go compiler?
  - sendilkumarn 7y ago
    It produces much smaller binaries My blog post on it -> https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168 https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168
  - justinclift 7y ago
    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/ https://justinclift.github.io/tinygo_canvas2/ (~19.5kB) https://justinclift.github.io/tinygo-wasm-rotating-cube/ https://justinclift.github.io/tinygo-wasm-rotating-cube/ (WebGL, ~12kB)
- mntmoss 7y ago
  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!

learnfromstory 7y ago

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

munificent 7y ago
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.
viraptor 7y ago
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.
pcwalton 7y ago
Because 1.0 is 0x3f800000, which is often right in the middle of the heap.

0815test 7y ago

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?

tyingq 7y ago
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.
ComputerGuru 7y ago
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).
mook 7y ago
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
- iampims 7y ago
  You can already do this: GOGC=off [1] [1] https://blog.cloudflare.com/go-dont-collect-my-garbage/ https://blog.cloudflare.com/go-dont-collect-my-garbage/
- 7y ago

ori_b 7y ago

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.

compsciphd 7y ago
I don't believe go can have uninitialized values. every variable has a default "zero value"
- aykevl 7y ago
  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.

wbl 7y ago

Depends on your definition of embedded.

IshKebab 7y ago

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?

opless 7y ago
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.
- chrisseaton 7y ago
  I think the person you’re replying to means a GC that needs headroom, not a GC like Python’s which generally doesn’t.
  - masklinn 7y ago
    FWIW micropython replace's cpython's refcount-with-cycle-breaker by a mark-and-sweep GC: https://github.com/micropython/micropython/wiki/Memory-Manager https://github.com/micropython/micropython/wiki/Memory-Manag...

aykevl 7y ago

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.

owaislone 7y ago
GC works even in WASM? That's great! What size wasm targets does TinyGo generate compared to the regular Go compiler?
- sendilkumarn 7y ago
  It produces much smaller binaries My blog post on it -> https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168 https://dev.to/sendilkumarn/tiny-go-to-webassembly-5168
- justinclift 7y ago
  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/ https://justinclift.github.io/tinygo_canvas2/ (~19.5kB) https://justinclift.github.io/tinygo-wasm-rotating-cube/ https://justinclift.github.io/tinygo-wasm-rotating-cube/ (WebGL, ~12kB)
mntmoss 7y ago
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!