feat(runtime): Prevent stack overflow while collecting large lists

[spotandjake]

Summary

This pr prevents stack overflows during the collection of large and extremely large lists.

Notes

• Smallest program size decreased because of increased code sharing in decRefChildren
• All data structures now support extremely deep nested objects in the final position.

---

Problem

While working on #2247 I noticed that decRef was overflowing the stack with lists that were only around 1350 elements.

Solution (For those interested)

The reason for this is that decRef and decRefChildren were not tco optimized, so the two options were to either handle lists separately or find a way to optimize decRef for tail calls. I decided on the second approach as it is more generic and provides improvements for other data structures as well.

The way I went about this was with a slightly cursed but valid modification where we free the parent before the children, this only works because we immediately decRef the children and when we free we don't zero the memory but instead just merge the blocks which will leave our child pointers unaffected. When freeing children we free most of the children in a loop and then free the final child outside of the loop in the tail position of decRefChildren allowing for the tco optimization. Initially this bloated our smallest program size by 100 bytes but I noticed that we are doing effectively the same operations for all dataTypes so I combined everything into a shared helper function that actually reduced our bundle size by 47 bytes.

Why not handle lists separately

Handling lists separately would have certainly been easier and if we are not up for the changes I made here it is still a viable approach however, it would add overhead to every ADT decRef and likely result in a hundred or so additional bytes being added to our smallest program size.

[ospencer]

Can you explain what parentPtr is for? It's not obvious to me reading through the code.

[spotandjake]

Can you explain what parentPtr is for? It's not obvious to me reading through the code.

Essentially Memory.decRef has the behaviour that it returned the pointer passed in, I needed to find a way to preserve this behaviour through the tco optimization which required passing the parentPtr through decRef and decRefChildren, otherwise we wouldn't be able to preserve the behaviour while putting decRefChildren in the tail position.

[ospencer]

That behavior isn't used by decRef or decRefChildren at all; you could just return it in the function that's exported at the end, e.g. let decRef = userPtr => { decRef(userPtr, false); userPtr }.

[ospencer]

The internal decRef can just return void.

[spotandjake]

The internal decRef can just return void.

I made that change, that simplifies the pointer handling semantics quite a bit.

[ospencer]

Nice.