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

[Jonathan M Davis]

On Monday, April 09, 2018 23:21:23 Nordlöw via Digitalmars-d wrote:
> On Monday, 9 April 2018 at 20:20:39 UTC, Ali wrote:
> > 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 kinds of GC's would be of interest?
> >>
> >> Which attempts have been made already?
> >
> > I think the priority is not having pluggable GC's, or a better
> > GC, but to fully support @nogc and deterministic and manual
> > memory management
> > which as I understood is on the roadmap
>
> Through allocators solely or will the GC adapt in some way?

I don't think that there are any plans to fundamentally change how the GC
works from the language perspective. The implementation may be improved or
replaced, but the GC isn't going anywhere, and any code that uses the GC
should continue to be able to do so as it has. Certainly, we're not getting
rid of or marginalizing the GC. We just want to make sure that code doesn't
use the GC when it doesn't need to or doesn't seriously benefit from using
the GC. More of Phobos should be @nogc than is currently, but it's never
going to be the case that all of Phobos is @nogc. There are real benefits to
using the GC, and we don't want to throw that away. We just don't want to
rely on it when it doesn't make sense.

There has been some discussion of adding some sort of RC capabilities to the
language with the idea that a type could be designed to be RC-ed that way,
but I don't think that the details have been sorted out yet, and I'm not
sure that it's even clear whether that's going to involve anything other
than GC-allocated memory (e.g. if the GC is used, then it can take care of
circular references, whereas if it isn't, then we have to get into weak
references and all of the complications that go with that). I believe that
Walter started looking into it, but I don't know how far he got before he
got sidetracked.

In particular, as I understand it, Walter's work with scope and DIP 1000 was
primarily motivated by whatever he was trying to do with RC, because without
something like DIP 1000, it becomes much harder (if not impossible) to do RC
in a fully @safe manner. So, whatever we end up seeing with regards to RC
support in the language is going to have to wait until DIP 1000 has been
fully sorted out, which will probably be a while.

Also, any work that's done to improve the GC at this point isn't something
that's going to be done by Walter. So, improvement to the GC is the sort of
thing that's likely to happen in parallel to any language improvements like
adding better RC support.

- Jonathan M Davis