Starlight-JS / starlight

JS engine in Rust
https://teletype.in/@starlight-js
Mozilla Public License 2.0
511 stars 9 forks source link

Switch to semi-conservative GC and remove support for multiple GCs #53

Closed playXE closed 3 years ago

playXE commented 3 years ago

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

playXE commented 3 years ago

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.