Potential GSoC project - GC improvements

[Rainer Schuetze via Digitalmars-d]

On 15.03.2016 02:34, Jeremy DeHaan wrote:
> I haven't had power for a couple of days, but it looks like the
> discussion has gone along pretty ok. After reading everything, I think
> I'm inclined to agree with Adam and the main focus of my proposal will
> be a precise GC (or as precise as we can get). I'll definitely need some
> guidance, but I'll be learning everything I can about GC's and precision
> until the start of the project.
>
> On Monday, 14 March 2016 at 05:28:13 UTC, Adam Wilson wrote:
>> Maybe ... why don't instead of trying to compete with everybody else,
>> we do our own thing, and do it very well. As long as we're just
>> another "me too" operation people will treat us like we are. Let's
>> focus on being the best D language out there. And D needs a GC, so
>> let's build the best damn garbage collector the natively-compiled
>> world has every seen.
>
>
> That is what I hope to work towards. Hopefully next year I can work on
> making a generational GC, or something else depending on how much time I
> could dedicate between when this GSoC is finished and the next begins.
>
> Adam, can you reach out to Craig and let him know you're willing to
> mentor this project if it get's accepted? I talked with him a few days
> ago via email and he said that someone would need to take it on but he
> wasn't sure who.
>

Being always way behind reading the forum these days, I'm a little late 
and have not read all the messages in this thread thoroughly. Here are 
some thoughts:

The precise GC used by Visual D is not only heap-precise, but also has 
type information to scan the data and TLS segments precisely. This is
done with a patched dmd now based on version 2.066 and is not part of 
the PR. It uses the solution that I presented at DConf 2013: 
http://dconf.org/2013/talks/schuetze.pdf

Creating information for stack and registers seems a lot of work with 
uncertain return: Apart from having to describe your code in very high 
detail, there is usually no guarantee that you can unwind the stack 
properly, especially when calling through C/C++ functions that you have 
no control of.

A moving collector is possible IMO, but it needs write barriers, and the 
idea of adding these explicitly has met quite some resistance, 
especially by Walter. Write barriers are also necessary for incremental 
collections. It changes the way you can interact with C/C++ because it's 
no longer good enough to just keep a pointer used by C visible to the 
GC, you have to pin it explicitly.

You can have very coarse barriers by using the page protection mechanism 
of the hardware, that's what I implemented for Windows, see 
http://rainers.github.io/visuald/druntime/concurrentgc.html. This is 
similar to Sociomantics concurrent GC using fork. It scans in the 
background, but not with multiple threads in parallel.

Unfortunately, this work has rotton almost 2 years now, but I hope to 
get back to it some day...