search

kyren / gc-arena

Incremental garbage collection from safe Rust
Creative Commons Zero v1.0 Universal
438 stars 36 forks source link

Make DynamicRootSet store bare types rather than Gc pointers #54

Closed kyren closed 1 year ago

kyren commented 1 year ago

Improves the usability of the DynamicRootSet by a great deal, also reduces the size of DynamicRoot types.

Also makes #53 not strictly necessary anymore.

There is one situation where one might be slightly worse off this way, which is that there will be an extra pointer indirection if the user was already going to store a Gc<'gc, T>, but in all other cases this is a strict improvement.

kyren commented 1 year ago

Added a few general fixes to the dynamic roots stuff as well.

kyren commented 1 year ago

Talked about this in Discord a bit, but just writing this here so I remember it later...

One thing I didn't think about is that following the held Rc pointer will always happen on access anyway, because we need to check the SetId pointer, then the held object will be right next to it, so it's probably not actually much of a downside? We should probably have performance tests...

If we were concerned about API stability, it would lock us out of a potentially faster API later, but... we could also just add a faster API in addition to this one, since It's still a bit obnoxious to root a non-Gc type with the old API. We could probably make something that didn't require a pointer indirection to check the set ID, and then having the object pointer right there would be a win, but even then there's still going to be pointer indirection to change the Rc count... I'm really not knowledgable enough to know what the exact impact would be.

The main case I see here for this is simplification, I have a big Value type enum with 9 variants, then some of those variants have other variants, some of which contain Gc internally and some contain GcCell internally.

This allows you to make registered types without having to "unfold" enums like this, makes it so i don't have to write a parallel GcCell API, and makes it so that #53 is not required. If we had fine grained mutability and no GcCell type, this would mabe change the equation a bit, but I still really don't like being forced to wrap and unfold enums, and #53 had a bit more splash damage in https://github.com/kyren/deimos than I anticipated.