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.

 That sounds cool, perhaps people can have customizable GC for
specific applications?

Looking forward to D having a precise GC

On 4/7/12 8:56 PM, Walter Bright wrote:
[snip]
> 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.

I'm also very excited about this design, and will make time to help with the library part of the implementation.

Maybe we can get a GSoC project on that. We already have a related proposal (lock-free GC).


Andrei

On 4/7/12 9:49 PM, Andrei Alexandrescu wrote:
> On 4/7/12 8:56 PM, Walter Bright wrote:
> [snip]
>> 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.
>
> I'm also very excited about this design, and will make time to help with
> the library part of the implementation.
>
> Maybe we can get a GSoC project on that. We already have a related
> proposal (lock-free GC).

BTW one exciting thing about both this and the nascent attributes design is they integrate wonderful with language's generic and generative capabilities.

Andrei

Hey, that sounds awesome.  I think I geeked out a bit.

Would this make it any easier to reference count types that can be statically proven to have no cyclical references?

On 4/7/2012 7:58 PM, Chad J wrote:
> Hey, that sounds awesome. I think I geeked out a bit.
>
> Would this make it any easier to reference count types that can be statically
> proven to have no cyclical references?


It has nothing to do with reference counting that I can think of.

On 4/7/12 9:59 PM, Walter Bright wrote:
> On 4/7/2012 7:58 PM, Chad J wrote:
>> Hey, that sounds awesome. I think I geeked out a bit.
>>
>> Would this make it any easier to reference count types that can be
>> statically
>> proven to have no cyclical references?
>
>
> It has nothing to do with reference counting that I can think of.

Nevertheless good food for thought. This is all very cool.

Andrei

On 04/08/2012 03:56 AM, Walter Bright wrote:
> 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.

That actually sounds like a pretty awesome idea.

On 04/08/2012 10:45 AM, Timon Gehr wrote:
> That actually sounds like a pretty awesome idea.

Make sure that the compiler does not actually rely on the fact that the template generates a function. The design should include the possibility of just generating tables. It all should be completely transparent to the compiler, if that is possible.

On 04/08/2012 10:45 AM, Timon Gehr wrote:
> That actually sounds like a pretty awesome idea.

I understand that the stack will still have to be scanned conservatively, but how does the scheme deal with closures?