Reference cycles memory leak about rune HOT 6 OPEN

Hey. Thanks for outlining this! It is indeed expected behavior right now and I'll queue it up to be documented in the book.

I'm not sure how to dynamically disallow such cycles. But I know some folks are interested in tinkering with integrating a gc, which to me would be the proper solution to dealing with cycles.

from rune.

Maybe weak references should be added in any case, even if cycles were not a problem?

from rune.

@vi I'm not against adding weak references. All though I personally don't use them very much. If anyone else wants to give it a stab, feel free!

from rune.

Note that most of the necessary plumbing to prevent the shared block from being de-allocated is already in place. All you'd really need to do for an initial implementation is try and take the interior value once the strong ref count reaches zero.

All though this has to be done in a way which doesn't change the size of the Shared<T> container, which might be a little tricky since need to distinguish between strong and weak reference. Possibly smuggling an aligned pointer marker could be useful here. Which would be done by asserting that the pointer to SharedBox<T> is aligned when created and mark weak references by setting the least significant bit.

from rune.

Started fiddling on the plumbing for a gc in the gc branch.

from rune.

This is a very interesting issue for scripting languages but seems to be practically unsolvable, given that even the most popular runtimes like CPython would fail on this (if you add at least one more layer like a list)

"Just" tracing doesn't help because you don't know when to run it. Running it to often would destroy performance. Running it when memory is low would introduce gigantic latencies and would make your memory usage go in waves from ~0 to 100%.

This leaves you with either heap generations to cope with "short lived" objects (like the JVM does) or escape analysis (like golang)... and a fully fledged GC. As long as every non-trivial value sits behind a Shared<> escape analysis (at least to a very shallow depth) is possible - given that you know how to track the value afterwards 🤨

The problem is that small but entangled memory leaks can be very hard to detect and trace. Big ones (like allocating in a loop) are easy to detect and solve with just a single manual drop.

from rune.