runtime: ensure some headroom for the GC to run #2884
Conversation
|
|
FWIW in the case I ran into, there was still plenty of system RAM, so the benefit of this patch may have been caused by the code's slightly different strategy rather than the large amount of headroom it tried to maintain. So maybe would do... though I have no idea whether it would prevent the OOM observed in the CI log. |
|
Do we have any numbers to demonstrate an improvement here? (Not saying this isn't a good idea, just wondering if there was a particular test or case or equivalent we could look through the gc debug log and say "Yup, this is better now.") |
|
If there is a particular log you want, I could get it on the affected machine... |
Yes, that's the problem this patch tries to fix. It didn't grow the heap when the runtime still had heap space left in its allocated slice of system RAM, however small. It will run much more efficiently when it has a bit more headroom.
It's not very deterministic, which makes it hard to reproduce. But you could for example look at how often it allocates and how often it runs the GC (the number of allocs should be a lot bigger than the number of GC cycles).
Yes... I need to look into that. I don't quite understand why it's running out of memory here (and whether this panic is even correct). |
|
I tried the fix in #2909 but unfortunately it doesn't help. |
The GC was originally designed for systems with a fixed amount of memory, like baremetal systems. Therefore, it just used what it could and ran a GC cycle when out of memory. Other systems (like Linux or WebAssembly) are different. In those systems, it is possible to grow the amount of memory on demand. But the GC only actually grew the heap when it was really out of memory, not when it was getting very close to being out of memory. This patch fixes this by ensuring there is at least 33% headroom for the GC. This means that programs can allocate around 50% more than what was live in the last GC cycle. It should fix a performance cliff when a program is almost, but not entirely, out of memory and the GC has to run almost every heap allocation.
|
I found a pretty stupid bug, it should be fixed now. |
The GC was originally designed for systems with a fixed amount of memory, like baremetal systems. Therefore, it just used what it could and ran a GC cycle when out of memory.
Other systems (like Linux or WebAssembly) are different. In those systems, it is possible to grow the amount of memory on demand. But the GC only actually grew the heap when it was really out of memory, not when it was getting very close to being out of memory.
This patch fixes this by ensuring there is at least 33% headroom for the GC. This means that programs can allocate around 50% more than what was live in the last GC cycle. It should fix a performance cliff when a program is almost, but not entirely, out of memory and the GC has to run almost every heap allocation. I believe I've seen this issue pop up from time to time (symptoms: very slow program that gets fast again with minor modifications and is stuck in GC somehow).
I did a code size comparison. On Linux/MacOS/Windows/WebAssembly, there is a small increase in size (around 50-200 bytes). On baremetal system, there is no change at all except for one oddball test (
tinygo build -size short -o test.hex -target=arduino -scheduler=tasks examples/blinky1). Not sure why: the IR is almost identical except for one difference in the switch of theruntime.sweepfunction. I guess I'm going to blame the AVR backend and say it's too small of an issue to care about.