Potential GSoC project - GC improvements

[Adam Wilson via Digitalmars-d]

Rainer Schuetze wrote:
>
>
> On 18.03.2016 22:04, Jeremy deHaan wrote:
>> On Friday, 18 March 2016 at 16:41:21 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 15.03.2016 02:34, Jeremy DeHaan wrote:
>>>> [...]
>>>
>>> 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:
>>>
>>> [...]
>>
>> Thank you for the feedback. I'm still working on my proposal so nothing
>> is set in stone just yet. I'm very interested in working on the GC for
>> this GSoC, so what would you suggest be my main focus? It sounds like
>> you already have a GC that is more or less what I was planning on
>> implementing...
>
> Well, there are a number of unfinished parts left:
>
> - as far as I understand the precise GC PR
> https://github.com/D-Programming-Language/druntime/pull/1022 is
> currently stalled because it doesn't yield better overall performance
> than the current GC in most situations. The reasoning is that it should
> be able compensate the additional time during allocation (saving pointer
> information) by improved scanning using that information to skip
> non-pointers. That didn't work out yet, though.
>
> - last time I checked generating RTInfo (which contains the pointer
> info) was a bit unreliable, see
> https://github.com/D-Programming-Language/dmd/pull/2480 and
> https://github.com/D-Programming-Language/dmd/pull/3958.
>
> - I only implemented the DATA and TLS section TypeInfo emission for the
> OMF backend, this needs to be ported to other platforms. Martin Nowak
> recently considered to just emit pointer locations. This would make the
> scanning function a bit simpler, but might need a bit more memory in the
> binary.
>
> Regarding the concurrent GC: I consider my implementation a prototype
> with rough edges and a lot of optimization opportunities. I'm not sure
> whether page protection is good enough to implement a generational GC,
> but it might still be possible to take advantage of the information that
> a page hasn't been written to.
> Judging from https://blog.golang.org/go15gc Go 1.5 seems to be using a
> similar GC (concurrent mark-and-sweep), though with proper write
> barriers. I guess there is a lot of stuff that can be used from their
> experience.
>
>  > so what would you suggest be my main focus?
>
> Given that 32-bit applications are becoming legacy, and false pointers
> are not a common problem in 64-bit processes (they do happen eventually,
> though) I suspect that concurrency of the GC would make a much larger
> impact on the D language than preciseness. A good target should be to
> reduce stop-the-world-time to something acceptable for interactive
> programs, i.e. well below 50ms.

I would argue that precision is still important as it enables a 
compacting GC. While technically possible to implement a generational GC 
without compaction, it's generally not considered wise. And even though 
64-bit does not suffer from false pointers as much as 32-bit does it 
still will, especially when used in the big-data, analytics, and 
scientific scenarios that D seems to have made real traction in. While 
false pointers are a problem for a simple command line app, and probably 
even most Vibe.D servers, there is a significant class of work being 
done in D today that would be directly effected by them.

-- 
// Adam Wilson
// quiet.dlang.dev