Potential GSoC project - GC improvements

Jeremy DeHaan via Digitalmars-d digitalmars-d at puremagic.com
Sat Mar 12 11:25:50 PST 2016


On Saturday, 12 March 2016 at 08:50:06 UTC, 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.

Rainer has two different precise GC's in pull requests right now 
and both are slower than the current one unless there are false 
pointers.  I would expect anything I come up with to largely act 
the same. The reason I keep pushing for a generational garbage 
collector is because I think it would be where we would see the 
most benefit in terms of general performance.


> Once the GC is fully precise we can implement a fully 
> compacting GC, 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. It should be quite possible to avoid 
> needing fork() or anything like it altogether. I know that the 
> .NET GC doesn't need to use anything like it.

A compacting GC could be built on top of a generational GC 
without much difficulty I would think, if we wanted to go that 
route. The compaction would just happen as part of a collection 
cycle when things are moved into the next generation. I have 
concerns about doing any compaction though, mostly because D can 
have both references and pointers to objects, and I don't know 
how we would want to go about updating pointers. Especially since 
pointers to D objects can exists in C and C++ code.

Another reason I want to work on a generational GC is because 
this can also lead into a concurrent GC without trying to emulate 
fork() on windows. The .Net GC has 3 generations with the last 
one having its collections running concurrently because it is 
unlikely to affect anything else going on. They don't bother 
running the other generations concurrently because their 
collections are really short. We could do something similar.

Perhaps someone more intimate with GC's than I am can speak up, 
but I think that a generational GC would be the best use of time 
in relation to performance gains. Other things can then be 
implemented on top of it later.


> Also, I would strongly recommend getting this book and reading 
> it cover to cover before starting:
> http://www.amazon.com/gp/product/1420082795/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687562&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0471941484&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0QD9X3E5QATSBCBT6BMM

Thank you for the link to the book. I was planning on this one 
http://www.amazon.com/gp/product/0471941484/ , but maybe I will 
buy them both.




More information about the Digitalmars-d mailing list