Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky]

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
> How difficult would it be to migrate an existing modern 
> GC-implementation into D's?

Which one? None of of even close to advanced GCs are pluggable, 
most in addition to being hardwired to a runtime/VM codebase, 
also rely on things like:
- particular object layout as in object header (Java, Dart + many 
JavaScript engines certainly do this)
- safe points and custom stackmaps
- some use tagged pointers and forbid explicit pointer arithmetic
- most heavily rely on GC pointers not being mixed with non-GC 
pointers
- generational ones need write barriers (pieces of code that 
guard each assignment of reference)
- most concurrent ones use read-barriers as well

> Which kinds of GC's would be of interest?

I believe we can get away with parallel mark-sweep + 
snapshot-based concurrency. It has some limitations but in D land 
with GC not being the single source of memory it should work fine.

> Which attempts have been made already?

I still think that mostly precise Immix style GC would also work, 
it won’t be 1:1 porting job though. Many things to figure out.