4 ms·
It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the sing
by c-cube 4y ago
It's just very hard to write a solid concurrent GC. There are not many in existence today. Here the challenge was doubled by the obligation to preserve the single core performance of existing programs, with the very fast allocation path on the minor heap. It's always harder to add these features to an existing language that already has significant programs written in it.
- amelius 4y agoWould it be possible to take this work and turn it into a more general GC library that language implementers can use beside LLVM?
- c-cube 4y agoIf your language matches ocaml's runtime semantics, then sure. It means uniform representation, 63bits integers, etc. but can be quite useful if your language is ML-ish.
- sadiq 4y agoAlso worth pointing out there's design constraints on the OCaml 5 GC imposed by some of OCaml's language features (looking at you ephemerons) and C API invariants. There may be different constraints for other runtimes.