Bottom line re GC in D

[via Digitalmars-d]

On Wednesday, 9 July 2014 at 13:01:36 UTC, bearophile wrote:
> The huge amount of work done on the OracleVM GC that is not 
> easy to match.
> D need for low-level code (currently user code can't tell the 
> GC what are the current actual contents of a union, this 
> includes Algebraic), D desire to interface efficiently to C 
> code.

I think it is a pity that there has been no real effort to 
experiment with restricting/extending semantics in a way that 
could lead to cache efficient GC collection.

1. annotate pointers that may point to GC memory (global dataflow 
or explict)
2. ensure that regular memory retain pointers to GC memory when 
it is live in C code
3. do global analysis of possible datastructures to minimize 
scanned fields/structs
4. improve stack traversal speed
5. improve ADTs with GC performance-enhancing features to reduce 
scanning
6. optional fat GC pointer implementations to get faster scanning

But yeah, if one insists on having C semantics throughout, then 
there is no hope…