View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2012
compiler support added for precise GC
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!
April 16, 2012
Re: compiler support added for precise GC
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.
April 16, 2012
Re: compiler support added for precise GC
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
April 16, 2012
Re: compiler support added for precise GC
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
April 16, 2012
Re: compiler support added for precise GC
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.
April 16, 2012
Re: compiler support added for precise GC
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
April 16, 2012
Re: compiler support added for precise GC
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.
April 16, 2012
Re: compiler support added for precise GC
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.
April 16, 2012
Re: compiler support added for precise GC
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.
April 16, 2012
Re: compiler support added for precise GC
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home