Just checked it in. Of course, it doesn't actually do precise GC, it is just thrown over the wall for the library devs who are itching to get started on it.

I added a getGCInfo() method to TypeInfo that returns an immutable(void)*. This pointer can be anything - a pointer to data, to code, whatever, that implements whatever the GC might need to do precise collections. The value is generated by the template GCInfo(T) in object.d.

Some observations:

1. if there are no pointers in the allocated data, the GCInfo(T) should be null. This enables a fast static check with no indirection for this most common case.

2. closure memory is allocated by calling _d_allocmemory. For now, it should just use the old conservative mark/sweep. Later, I can add a GCInfo(T) for it.

3. Many types will follow similar patterns:

   ptr .. int .. ptr .. int

   ptr .. ptr

   int .. ptr

I suggest that specializations exist for these to avoid generating innumerable identical data structures or functions. In fact, if they are named with names like:
   scanpipi()
   scanpp()
   scanip()

then the linker will automatically remove duplicates.

4. Stack scanning remains imprecise, and should use the usual conservative method.

5. The "has pointers" bit array can, of course, be eliminated.

6. I suggest the GCInfo pointer be stored at the end of the allocated block, as then it won't affect the alignment of the allocated data.

Release the hounds!

On 4/15/2012 7:24 PM, Walter Bright wrote:
> 3. Many types will follow similar patterns:
>
> ptr .. int .. ptr .. int
>
> ptr .. ptr
>
> int .. ptr
>
> I suggest that specializations exist for these to avoid generating innumerable
> identical data structures or functions. In fact, if they are named with names like:
> scanpipi()
> scanpp()
> scanip()
>
> then the linker will automatically remove duplicates.

I realized after I posted this that the patterns:

ptr .. int .. ptr .. int
ptr .. int .. ptr
ptr .. int .. ptr .. int .. int

are the same as far as marking goes, and so should all generate the same function/data.

On 2012-04-16 04:24, Walter Bright wrote:
> Just checked it in. Of course, it doesn't actually do precise GC, it is
> just thrown over the wall for the library devs who are itching to get
> started on it.
>
> I added a getGCInfo() method to TypeInfo that returns an
> immutable(void)*. This pointer can be anything - a pointer to data, to
> code, whatever, that implements whatever the GC might need to do precise
> collections. The value is generated by the template GCInfo(T) in object.d.

Cool, but why was "getMembers" removed?

-- 
/Jacob Carlborg

On 16-04-2012 08:30, Jacob Carlborg wrote:
> On 2012-04-16 04:24, Walter Bright wrote:
>> Just checked it in. Of course, it doesn't actually do precise GC, it is
>> just thrown over the wall for the library devs who are itching to get
>> started on it.
>>
>> I added a getGCInfo() method to TypeInfo that returns an
>> immutable(void)*. This pointer can be anything - a pointer to data, to
>> code, whatever, that implements whatever the GC might need to do precise
>> collections. The value is generated by the template GCInfo(T) in
>> object.d.
>
> Cool, but why was "getMembers" removed?
>

I was wondering too. That seems rather arbitrary and unrelated to precise GC.

-- 
- Alex

On 4/15/2012 11:30 PM, Jacob Carlborg wrote:
> Cool, but why was "getMembers" removed?

1. It was intended to be used for precise gc.

2. It was never implemented (always returned null).

3. Nobody used it or asked for it.

4. GCInfo seems to be a better design.

On 2012-04-16 09:09, Walter Bright wrote:
> On 4/15/2012 11:30 PM, Jacob Carlborg wrote:
>> Cool, but why was "getMembers" removed?
>
> 1. It was intended to be used for precise gc.

I thought it was a first step for runtime reflection.

> 2. It was never implemented (always returned null).

I've noticed that.

> 3. Nobody used it or asked for it.

I've heard many people ask for a way to get the members of a class using runtime reflection and I always pointed to getMembers. I always thought it was supposed to be getMembers but that it wasn't finished yet. There's a bug report about it:

http://d.puremagic.com/issues/show_bug.cgi?id=2844

> 4. GCInfo seems to be a better design.

I see. Makes sense, I just thought it was for a different use.

-- 
/Jacob Carlborg

On 4/16/2012 1:20 AM, Jacob Carlborg wrote:
> I thought it was a first step for runtime reflection.

The thing about runtime reflection is you only need it for a few classes, while the compiler is doomed to generate the info for all of them. Andrei suggested a better design, which was to use compile time reflection to generate runtime information, as a library routine, on an as-needed basis.

In other words, it should be a library feature, not a language feature.


I think that by making the precise GC information a library feature, not a compiler one, we may be reaching a tipping point where the language is powerful enough that we may not need to add ever more language features.

Le 16/04/2012 04:24, Walter Bright a écrit :
> Just checked it in. Of course, it doesn't actually do precise GC, it is
> just thrown over the wall for the library devs who are itching to get
> started on it.
>
> I added a getGCInfo() method to TypeInfo that returns an
> immutable(void)*. This pointer can be anything - a pointer to data, to
> code, whatever, that implements whatever the GC might need to do precise
> collections. The value is generated by the template GCInfo(T) in object.d.
>

Having this template into object.d seems problematic to me. It is now quite hard to provide any custom GC implementation without messing with Druntime.

Providing a user created GC should be as easy as possible.

> Some observations:
>
> 1. if there are no pointers in the allocated data, the GCInfo(T) should
> be null. This enables a fast static check with no indirection for this
> most common case.
>
> 2. closure memory is allocated by calling _d_allocmemory. For now, it
> should just use the old conservative mark/sweep. Later, I can add a
> GCInfo(T) for it.
>
> 3. Many types will follow similar patterns:
>
> ptr .. int .. ptr .. int
>
> ptr .. ptr
>
> int .. ptr
>
> I suggest that specializations exist for these to avoid generating
> innumerable identical data structures or functions. In fact, if they are
> named with names like:
> scanpipi()
> scanpp()
> scanip()
>
> then the linker will automatically remove duplicates.
>

I think this is again solving an implementation issue by a language design decision. Ultimately the useless code bloat must be handled by the toolchain anyway.

> 4. Stack scanning remains imprecise, and should use the usual
> conservative method.
>
> 5. The "has pointers" bit array can, of course, be eliminated.
>
> 6. I suggest the GCInfo pointer be stored at the end of the allocated
> block, as then it won't affect the alignment of the allocated data.
>

This very swap unfriendly. Many pages will have to be unswapped/swapped back in the marking process, even if it is 100% useless for data that doesn't contains pointers.

Le 16/04/2012 09:09, Walter Bright a écrit :
>
> 4. GCInfo seems to be a better design.
>

This is unrelated. In fact, GCInfo could use getMembers . Precise GC and reflection are brother.

Le 16/04/2012 11:08, deadalnix a écrit :
> Le 16/04/2012 09:09, Walter Bright a écrit :
>>
>> 4. GCInfo seems to be a better design.
>>
>
> This is unrelated. In fact, GCInfo could use getMembers . Precise GC and
> reflection are brother.

Never mind, I thought you were talking about __traits, but you are talking about Runtime version of it.

We do agree.