d future or plans for d3

[Timon Gehr]

On 12/19/2011 01:00 AM, Vladimir Panteleev wrote:
> 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"?

I think we should attempt an implementation, find out where the main 
performance issues lie and then find a suitable set of trade-offs.