When I started work on this project it had precise GC and with it, Starlight had lots of segfaults because we didn't have any way to force object rooting then I created MiGC which was a simple almost precise collector i.e it can collect roots on the stack but it is an optional feature that is disabled by default and I also introduced shadow stack which makes keeping variables rooted easy but in exchange it does generate much more code to keep variable on the stack and also link it to shadow stack. In some cases, a shadow stack is indeed faster than a conservative collection but in some cases, it is not i.e when a function has lots of roots. After MiGC I decided to have a generic GC API so it is possible to have multiple GCs but now I think this is unnecessary.
So after this journey, I think it is worth simply switch to a semi-conservative collector and entirely remove generic GC API. MiGC is not the best choice as it uses mimalloc API to detect GC pointers on the stack and this API is known to be not the fastest one so we need to develop new garbage collector and probably we could take a look at WebKit's Riptide GC and RCImmixCons algorithms
One another problem with having a generic GC API is that compiler does not produce optimized code for allocations. It always does call to gc.allocate through dynamic dispatch.
When I started work on this project it had precise GC and with it, Starlight had lots of segfaults because we didn't have any way to force object rooting then I created MiGC which was a simple almost precise collector i.e it can collect roots on the stack but it is an optional feature that is disabled by default and I also introduced shadow stack which makes keeping variables rooted easy but in exchange it does generate much more code to keep variable on the stack and also link it to shadow stack. In some cases, a shadow stack is indeed faster than a conservative collection but in some cases, it is not i.e when a function has lots of roots. After MiGC I decided to have a generic GC API so it is possible to have multiple GCs but now I think this is unnecessary.
So after this journey, I think it is worth simply switch to a semi-conservative collector and entirely remove generic GC API. MiGC is not the best choice as it uses mimalloc API to detect GC pointers on the stack and this API is known to be not the fastest one so we need to develop new garbage collector and probably we could take a look at WebKit's Riptide GC and RCImmixCons algorithms