Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze

[Rainer Schuetze]

On 06.06.2013 21:42, Diggory wrote:
> Interesting talk. It seems there are a few features D could provide
> which would make for some more powerful GCs:
>
> - Hook for when generating code which reads/writes a pointer allowing GC
> to put in read/write barriers where necessary.
>
> - Hook for union assignment so that the GC could emplace the correct
> type bits
>
> - Hook for passing pointers to extern(XXX) functions so that the GC can
> pin the arguments allowing a compacting GC
>

There are also D functions annotated extern(C) to subvert the module 
system. It might be a bit expensive to pin any pointer passed to such 
function.

> - Hook for function call/return so that stack type-info can be stored.
> There's actually another way to do this which would have less overhead -
> at compile time the compiler could write the address range of each
> function along with a bitmap for possible pointers in that function to
> some known location. When the GC runs it could unwind the stack and look
> each frame pointer up in the list of functions to find the bit pattern
> to use. When calling a function that does some low-level stuff and might
> prevent the unwinding from working correctly it would be possible to
> switch back to conservative mode until the function returns.

I was considering something like that too (AFAICT exception handling on 
Win64 works similar), but the problem is to actually properly unwind the 
stack. If you have called some C function with a callback into your D 
code, stack unwinding might not be able to find the correct stack frames 
above the C function, so that you don't scan the stack above that.