d future or plans for d3

Vladimir Panteleev vladimir at thecybershadow.net
Sun Dec 18 16:00:15 PST 2011


On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
> On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
>>> On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
>>>> On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr 
>>>> wrote:
>>>>> You are right. I have had in mind a generational GC that 
>>>>> uses a
>>>>> copying collector for the nursery as this is what most
>>>>> state-of-the-art VM GCs do.
>>>> These changes are too invasive for the language at this 
>>>> point, I
>>>> believe. We need to work with what we have.
>>>
>>> I disagree. Code that relies on other semantics would just 
>>> have to use
>>> conservative GC.
>>
>> Please elaborate on how you would hypothetically change D to 
>> accustom
>> such changes. I am having trouble imagining such an 
>> implementation that
>> would not have a considerable impact on D's performance.
>
> If you have an union
>
> union X{
>    int  x;
>    int* y;
> }
>
> The compiler would just lay out x and y sequentially instead of 
> at the same memory location. Alternatively, it could add a tag 
> to each union.
>
> In case of passing GC memory to C functions, I would prefer to 
> just disallow the C code to capture the reference, and to 
> disable GC while the C function runs. (disabling and enabling 
> GC is just a matter of modifying a counter somewhere, that 
> should not visibly impact performance.) If C code was to 
> capture a reference to the memory then it would probably take 
> ownership anyway, which would necessitate to allocate the 
> memory with malloc even with conservative GC.
>
> I am not sure what to do about void[] though.

OK... but what about the "generational GC that uses a copying 
collector for the nursery"?


More information about the Digitalmars-d mailing list