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?

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?

Considering no one has done it, very.

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

There's been threads about this. I'd do a search for "precise GC" in general.

> Which attempts have been made already?

https://github.com/dlang/druntime/pull/1603

On Monday, 9 April 2018 at 18:39:11 UTC, Jack Stouffer 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?
>
> Considering no one has done it, very.

What's the reason for this being so hard?

A too unstrict programming model that enables (has enabled) to much bit-fiddling with pointers (classes)?

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.

On Mon, Apr 09, 2018 at 07:43:00PM +0000, Dmitry Olshansky via Digitalmars-d wrote:
> On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
[...]
> > 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.

Last I remembered, you were working on a GC prototype for D?  Any news on that, or have you basically given it up?


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

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

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?

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

On Monday, 9 April 2018 at 23:21:23 UTC, Nordlöw wrote:
> Through allocators solely or will the GC adapt in some way?

Here is the relevant line from the vision document
"@nogc: Use of D without a garbage collector, most likely by using reference counting and related methods Unique/Weak references) for reclamation of resources. This task is made challenging by the safety requirement. We believe we have an attack in the upcoming allocators/collections combos."

And the link to the vision document https://wiki.dlang.org/Vision/2018H1

In general, I do recommend you read the document carefully, and it important to note that is in it, and what is not in it

Obviously, there is no mention on working on the GC
There is also no direct mention of changing Phobos or modifying Phobos

Also it might be important to read the vision document in order
priority number 1 is "1. Lock down the language definition"
this very much align with many comments I've seen here from Andrei or Walter
that they are more interested in seeing the existing features used, rather than adding new features

The vision document doesn't seem to introduce any new feature, mostly improvements to existing features, or making existing feature more usable

On Monday, 9 April 2018 at 19:43:00 UTC, Dmitry Olshansky wrote:
> None of of even close to advanced GCs are pluggable

Eclipse OMR contains a pluggable GC, and it's used in OpenJ9, which claims to be an enterprise-grade JVM.