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.
