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