runtime (gc): add a new "list" GC

[niaow]

This memory manager uses a simple linked list to track active allocations, and measures the gaps between them to find available memory. Performance is not great for large heaps, but is sufficient for microcontrollers with single-digit kilobytes of memory.

This is effectively a simplified version of #1193 containing only the GC itself so that it is easier to review.

The ./testdata/gc.go test was run on an Arduino Uno and passes. It is slow.

The false-positive rate problem still applies to microcontrollers where the address space is mostly used.

[niaow]

Size comparison:

[niaow@finch tinygo]$ build/tinygo build -target=arduino -size short -gc=conservative -o /tmp/gc.hex ./testdata/gc.go 
   code    data     bss |   flash     ram
   3768      89     689 |    3857     778
[niaow@finch tinygo]$ build/tinygo build -target=arduino -size short -gc=list -o /tmp/gc.hex ./testdata/gc.go 
   code    data     bss |   flash     ram
   2712      94     686 |    2806     780

[aykevl]

I looked at the code (not super in-depth though) and it looks reasonable to me. Thank you for this effort! This is indeed much easier to review when it's separated from a precise GC (which will be quite a bit of work and may also be useful for -gc=conservative).

Can you add a test for this GC? You can add a test in main_test.go, see the opt=1, opt=0, and ldflags tests.

[aykevl]

I'm slightly worried that a quadratic algorithm in a GC might be a problem. Maybe not on the AVR though with its very limited memory.

I think there is a way to avoid this sorting, at least if it's fine to limit the maximum object size to half the address space (which seems like a reasonable limitation to me). You can use one bit of allocHeader.len (e.g. the top bit) to store the mark state. Then, during sweeping, you can iterate through all objects and remove the ones that haven't been marked.

[niaow]

That seems reasonable.

[aykevl]

It's just an idea for how it can be improved. The code as-is already looks good to me.

[niaow]

Actually, I think this may be better as-is. That tagging strategy would actually also make the scan quadratic (the list needs to be fully traversed each time we need to find what to scan). I think the current strategy with the scan stack is at least a bit more readable.

[aykevl]

This also looks like a quadratic algorithm here: for every possible root, all allocations are scanned.

[niaow]

Unfortunately yes. Not sure if this can/should be changed. This worked much better with the precise GC because there were far fewer roots to deal with. This is also fairly reasonable on AVR where I don't really see more than a dozen allocations very often.

[aykevl]

Two things I realize now:

• The memory should be aligned. You can use the align function for this. This is a no-op on AVR and should be optimized away entirely. On other platforms, it is necessary for correct functioning.

  size = align(size)

• You might want to use a zeroSizedAlloc global (like in gc_conservative.go) to return for when the size is zero. This does sometimes happen in practice, although it is rare. The Go spec explicitly allows this:

  Pointers to distinct zero-size variables may or may not be equal.

  On the other hand, it's rare and costs RAM/flash, so it would be reasonable to leave this out.

[niaow]

Adding the 0-sized alloc in because it only costs 1 byte of RAM (and saves 28 bytes of flash for some reason).

[niaow]

I am not entirely sure what you mean with the alignment. Assuming that heapStart is aligned (which I picked up from the conservative collector), findMem should always return appropriately aligned data. The header preserves pointer/word alignment, and every subsequent start is corrected with an align call.

[niaow]

@aykevl I am currently planning to do some GC cleanup to try to ensure that all of the conservative GCs behave similarly. Should we merge this first or should I push this to later?

[deadprogram]

Either way, please note merge conflicts @niaow

[niaow]

I am going to close this. This GC has too many issues and we have other priorities right now.