rune VS gc-arena

Two projects that may be of interest, related to this topic:

- Rune (https://github.com/CeleritasCelery/rune) - A re-implementation of Emacs but in Rust (like Remacs, but actively developed)

- Pimacs (https://github.com/federicotdn/pimacs) - Same, but using Go (created by me, but developed in a very slow pace)

[2] https://github.com/CeleritasCelery/rune/issues/17#issuecomme...

I second this ! I had trouble finding the github link, but here is is https://github.com/CeleritasCelery/rune

> How is anything rooted here? The lifetime changed from 'arena to 'root but I don't see a root being created.

In this example, the Vec has been rooted previously. So pushing an object into the Vec will make it "transitively" rooted (accessible from the root). You would root a struct with the root_struct![1] macro, which works very similar to the root! macro shown in the post.

However you made you realize one error; The rooted `Vec` in the example you pointed is a by value type, but in the implementation you can only get references to rooted structs, so that example needs to be updated.

> But later we see roots not obeying a LIFO order, under "Preventing escapes" where roots are dynamically created and destroyed in an arbitrary order.

Objects are just a copyable wrapper around a pointer, so they are not the part that has the LIFO semantics. inside the root! macro[2] there is a `StackRoot` type that is the actual "root". The object just borrows from that so that is has a 'root lifetime and is valid post gc. The actual root struct is not exposed outside of the macro.

I hope this makes the distinction between "roots" and "objects" clearer. Objects are just pointers to heap data. When we root an object we store the data it points to on the root stack and create a new `StackRoot`. Then we say this object is rooted. But the struct that "does the rooting" is inside the macro and not exposed. Rooting a struct works similarly.

[1] https://github.com/CeleritasCelery/rune/blob/5a616efbed763b9...

Hack on Rune

I'm going to point out one potential footgun with your library: circularly-linked Drops.

If you have values A and B, both instances of T that implement Drop and hold a Gc to one another, then either A sees a dropped B or B sees a dropped A, and you get UB. Technically this isn't a problem because you already marked it as an unsafe trait, but your documentation should also mention this problem.

You have a safe derive macro for Collectable, however, so it needs to reject Drop. This is possible with some weird macro magic[0].

For those wondering, while Python doesn't have UB, it used to enforce the same rules until PEP 442[1]. Circularly linked garbage that implemented __del__ would instead get stored in sys.gc.garbage and you'd have to go in there and break references on __del__ types. However, native code objects will actually still trigger this behavior[2] presumably to avoid UB.

I have no clue if Java finalizers need to worry about this.

[0] In Ruffle we use gc_arena as our garbage collector. It enforces no_drop in it's Collect derive macro. See: https://github.com/kyren/gc-arena/blob/master/src/gc-arena-d...

Actually, I lied: no_drop is one of two safe constraints you can use Collect with. The alternative is require_static, which only works because gc_arena treats the entire GC heap as a data structure that is owned and has a lifetime that all Gc pointers borrow. This doesn't work for dumpster, though, so ignore it.

[1] https://peps.python.org/pep-0442/

[2] https://docs.python.org/3/library/gc.html#gc.garbage

I foresee some potential problems with this approach. I would recommend trying to find an arena-based GC crate that you could use. gc-arena looks promising, although I haven't tried it — it seems to be built for your specific use case.

gc-arena uses closures to create "mutation sessions" where you are allowed to mutate the heap (see example).

One example of the second approach is the gc-arena library- see the implementation of the make_arena! macro.