On 4/16/2012 2:05 AM, deadalnix wrote:
> 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.

It's never going to be easy for anyone to just write their own GC, especially one that works better than one a lot of people have spent a lot of time on.

> 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.

We gotta work with what we have.

>> 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.

I think there's a misunderstanding. The GC allocates by powers of 2. So a 22 byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go at the end of that. That will not cause swapping.

As for data that has no pointers, something has to indicate that. Of course, another strategy is to allocate such data in separate pools. In fact, that might be an excellent idea, as such pools would never have to be read (i.e. swapped in, loaded into cache) during the mark/sweep process.

On 2012-04-16 11:00, Walter Bright wrote:
> 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.

If we can't relay on runtime reflection being there it's basically useless. It's like your idea that the GC shouldn't be optional. Then all library code needs to be written to work without the GC. It's the same thing with runtime reflection.

-- 
/Jacob Carlborg

Le 16/04/2012 11:25, Walter Bright a écrit :
> On 4/16/2012 2:05 AM, deadalnix wrote:
>> 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.
>
> It's never going to be easy for anyone to just write their own GC,
> especially one that works better than one a lot of people have spent a
> lot of time on.
>

I don't think this is easy. But Different GC have different impact on the program. For instance, oracle's JVM provide you 4 different GC, that you can choose with different configuration parameters.

Some are made to achieve maximum throughput, others to achieve low pause. None is better that the other, it depends on the application. For a user interface, you'll chose the low pause GC, but for a backend processing application, you may prefer the maximum throughput.

>>
>> 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.
>
> I think there's a misunderstanding. The GC allocates by powers of 2. So
> a 22 byte struct will be allocated in a 32 byte block, and the GCInfo
> pointer can go at the end of that. That will not cause swapping.
>
> As for data that has no pointers, something has to indicate that. Of
> course, another strategy is to allocate such data in separate pools. In
> fact, that might be an excellent idea, as such pools would never have to
> be read (i.e. swapped in, loaded into cache) during the mark/sweep process.

That is exactly what I meant. Metadata about the block shouldn't be stored anywhere near the block, because it will behave horribly wrong when swap come into play. Metadata must be read and written when GC does its job, but the block itself doesn't require it.

Le 16/04/2012 13:24, Jacob Carlborg a écrit :
> On 2012-04-16 11:00, Walter Bright wrote:
>> 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.
>
> If we can't relay on runtime reflection being there it's basically
> useless. It's like your idea that the GC shouldn't be optional. Then all
> library code needs to be written to work without the GC. It's the same
> thing with runtime reflection.
>

This is a lib issue. phobos should provide a standard way to do compiletime -> runtime reflection so each lib doesn't need to provide its own way every time.

On Sun, 15 Apr 2012 22:24:56 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> 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 conflicts with the array runtime's use of the end of the block to store the block's 'used' length.  But it may not be an issue.

Note that the 16-byte block is going to get mighty small (only 12 bytes, possibly 11 if it's an appendable block).

I also suggest that you look into changing the way structs are allocated if you haven't already.  Right now, they are allocated by creating a new array of size 1.  While this is convenient in terms of avoiding a new function, it means all struct allocations are arrays, and as such will be typed as arrays, with appendable semantics and with GCInfo of an array.

-Steve

Steven Schveighoffer:

> I also suggest that you look into changing the way structs are allocated if you haven't already.  Right now, they are allocated by creating a new array of size 1.  While this is convenient in terms of avoiding a new function, it means all struct allocations are arrays, and as such will be typed as arrays, with appendable semantics and with GCInfo of an array.

+2

Bye,
bearophile

On 4/15/2012 10:24 PM, 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.

Excellent!!  Maybe I'll get started on this soon.

On 4/15/2012 7:29 PM, Walter Bright wrote:
> 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.

Another possibility is to just emit a bit mask:

0	no pointers
101	ptr .. int .. ptr
1011	ptr .. ptr .. int .. ptr
>0xFFFF	a pointer to a function that does the marking

This has the advantage of almost never needing to resort to the indirect function call.

Le 16/04/2012 18:32, Walter Bright a écrit :
> On 4/15/2012 7:29 PM, Walter Bright wrote:
>> 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.
>
> Another possibility is to just emit a bit mask:
>
> 0 no pointers
> 101 ptr .. int .. ptr
> 1011 ptr .. ptr .. int .. ptr
>  >0xFFFF a pointer to a function that does the marking
>
> This has the advantage of almost never needing to resort to the indirect
> function call.

As long as it fit in a pointer, I see no reason why it can't be done.

On 16-04-2012 18:32, Walter Bright wrote:
> On 4/15/2012 7:29 PM, Walter Bright wrote:
>> 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.
>
> Another possibility is to just emit a bit mask:

This is, in fact, what most production GCs do (e.g. Mono's SGen). It's widely considered a good technique.

>
> 0 no pointers
> 101 ptr .. int .. ptr
> 1011 ptr .. ptr .. int .. ptr
>  >0xFFFF a pointer to a function that does the marking
>
> This has the advantage of almost never needing to resort to the indirect
> function call.

-- 
- Alex