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...
