compiler support added for precise GC

[deadalnix]

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.