GC: two major pain point the compiler/druntime can help with

[deadalnix]

Hi,

With Steven; we've been working on a new GC for D with good 
result. However, there are 2 major pain points that limit what 
any GC can do that I would like to see addressed.

1. Static data that contain pointer or not are not differentiated.

The compiler put all the static data in 2 segments, depending on 
whether they are zero initialized or not. Then these segment are 
passed down to the GC to scan. Any application that has large 
buffer of static data, for instance precomputed result to speedup 
computations, ends up scanning them again and again for pointers.

The compiler knows what static data may or may not contain 
pointers, and could split them up in different segment, and the 
runtime could only pass down the appropriate segment. This is an 
almost free win.

2. The Current GC API touches memory all over the place.

The current GC API loads a pointer to a GC object, then load the 
vtbl, then load the method to call int he vtbl, and does similar 
things in the TypeInfo API. All of these data are on disparate 
part of the memory on their own pages.

We designed our GC to touch only one page on the fast path. As a 
result, we get 4x TLB and cache misses in the plumbing between 
the application and the GC, causing the plumbing to to be half 
the cost of an allocation !!!

This API needs to be redesigned. The way it is usually done in 
the wild is to make the allocator overridable using weak 
functions. This allows to customize the allocator at link time 
without paying an absurd cost like we do.