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.
