Precise GC

[deadalnix]

Le 08/04/2012 03:56, Walter Bright a écrit :
> Of course, many of us have been thinking about this for a looong time,
> and what is the best way to go about it. The usual technique is for the
> compiler to emit some sort of table for each TypeInfo giving the layout
> of the object, i.e. where the pointers are.
>
> The general problem with these is the table is non-trivial, as it will
> require things like iterated data blocks, etc. It has to be compressed
> to save space, and the gc then has to execute a fair amount of code to
> decode it.
>
> It also requires some significant work on the compiler end, leading of
> course to complexity, rigidity, development bottlenecks, and the usual
> bugs.
>
> An alternative Andrei and I have been talking about is to put in the
> TypeInfo a pointer to a function. That function will contain customized
> code to mark the pointers in an instance of that type. That custom code
> will be generated by a template defined by the library. All the compiler
> has to do is stupidly instantiate the template for the type, and insert
> an address to the generated function.
>
> The compiler need know NOTHING about how the marking works.
>
> Even better, as ctRegex has demonstrated, the custom generated code can
> be very, very fast compared with a runtime table-driven approach. (The
> slow part will be calling the function indirectly.)
>
> And best of all, the design is pushed out of the compiler into the
> library, so various schemes can be tried out without needing compiler work.
>
> I think this is an exciting idea, it will enable us to get a precise gc
> by enabling people to work on it in parallel rather than serially
> waiting for me.

This id a good idea. However, this doesn't handle type qualifiers. And 
this is important !

D2 type system is made in such a way that most data are either thread 
local or immutable, and a small amount is shared. Both thread local 
storage and immutability are source of BIG improvement for the GC. Doing 
without it is a huge design error.

For instance, Ocaml's GC is known to be more performant than Java's. 
Because in Caml, most data are immutable, and the GC take advantage of 
this. Immutability means 100% concurrent garbage collection.

In the other hand, TLS can be collected independently and only influence 
the thread that own the data. Both are every powerfull improvement, and 
the design you propose « as this » cannot provide any mean to handle 
that. Which is a big missed opportunity, and will be hard to change in 
the future.