Potential GSoC project - GC improvements

[Rainer Schuetze via Digitalmars-d]

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.