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