New garbage collector? about raptorjit

[Ravenslofty]

I think RaptorJIT needs a new garbage collector because the current one is not thread safe, making it a blocker on internal multi-threading.

I would be in favour of a compacting generational design with a minor and major heap, but to my knowledge this is incompatible with the design of the Lua 5.1 C API, because C does not like it when you change pointer locations while it's running.

It's entirely possible to go the other direction with a Go-style concurrent mark-sweep algorithm focused entirely on latency, but there's a point where GC latency affects GC throughput, and the OCaml generational design is useful enough for Jane Street to do HFT, so I'm fairly sure it's soft real-time.

[fsfod]

A moving\compacting collector would also hurt the JIT's ability to embed pointers in emitted code forcing some extra indirection.

[Ravenslofty]

Could you be more specific with that? While pointer moving does result in indirection, since the VM uses NaN-tagging, pointers are usually pretty obvious, and can be patched in a GC pause if necessary, AIUI.