A benchmark, mostly GC

deadalnix deadalnix at gmail.com
Sun Dec 11 14:27:06 PST 2011


Le 11/12/2011 22:26, Timon Gehr a écrit :
> On 12/11/2011 10:13 PM, deadalnix wrote:
>> Le 11/12/2011 21:55, Timon Gehr a écrit :
>>> On 12/11/2011 07:02 PM, deadalnix wrote:
>>>> Le 11/12/2011 16:43, Dejan Lekic a écrit :
>>>>>
>>>>> It would be really great to implement a generational GC similar to the
>>>>> C4 mentioned in this presentation:
>>>>> http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection
>>>>>
>>>>>
>>>>> . There is a research-paper about C4 as well:
>>>>> http://dl.acm.org/citation.cfm?id=1993491 .
>>>>
>>>> This GC (like all compacting GC) require that the GC knows what is a
>>>> reference/pointer and what isn't.
>>>>
>>>> This is possible in D using the compile time reflexion to build a
>>>> runtime reflexion. But the standard lib is far away from that. This
>>>> will
>>>> also bloat the executable with reflexion's data, thing that some don't
>>>> want.
>>>
>>> The information has to be generated by the compiler, not by the library.
>>>
>>
>> This is not the way choosen by D. And the way choosen by D is, IMO,
>> supperior.
>>
>> D choosed to have compiler time reflexion, but no runtime reflexion
>> (compiler won't generate it). Given that, and the great capability of D
>> for generic programming, the best solution is to generate information at
>> using compile time reflexion using a lib, to get runtime reflexion.
>>
>> Many application do not want the bloat created by runtime reflexion.
>> This is up to the user to compile with such a lib or not.
>
> We are talking about supporting precise GC, not about custom runtime
> reflection. There is no way to get precise GC right without compiler
> support.

It is clearly possible by marking not movable what is possibly pointer 
in the stack and registers and some runtime reflexion used by the GC.


More information about the Digitalmars-d mailing list