Potential GSoC project - GC improvements

[Chris Wright via Digitalmars-d]

On Sat, 12 Mar 2016 00:50:06 -0800, Adam Wilson wrote:
> If I may make a suggestion. The lock free work is unlikely to require
> the entirety of GSoC. And the precise GC is the next most important
> thing on your list and will have the biggest impact on GC performance.
> 
> Once the GC is fully precise we can implement a fully compacting GC,

Unions mean we can't be entirely precise, but we can get pretty close. 
Stack maps and type pointer maps are entirely separate efforts, and type 
pointer maps will be easier to implement, so the first pass will probably 
only include type pointer maps.

Switching to a compacting GC is risky. It's a transparent change if 
you're only working with D code, but if you interface to other languages, 
it breaks things horribly.

> which improves the usefulness of generational collection. Additionally,
> precision allows a significant amount of work to be done in improving
> the performance of the GC in multi-threaded scenarios.

Primarily because less memory needs to be scanned on average, so less 
work needs to be done and GC pauses are shorter. There's nothing specific 
to multithreading there.

> It should be
> quite possible to avoid needing fork() or anything like it altogether.

fork() is used to avoid pausing the program at all during the mark phase.

> I know that the .NET GC doesn't need to use anything like it.

The .NET GC stops all managed threads during a collection.

During a nursery or gen 1 collection, on average it's probably fast 
enough that forking wouldn't give that much benefit. During a full 
collection, if your application is latency-sensitive, a forking strategy 
would be better.

But .NET can't do that because Windows doesn't have a fork() system call, 
and it's expensive to emulate.