On 11/20/2011 09:40 AM, Paulo Pinto wrote:
Am 19.11.2011 21:49, schrieb Timon Gehr:
The fact that Nicks example works has no implications for the GC
implementation because the two types involved in his reinterpret-casting
don't have any indirections.
Furthermore:
int* a =...;
I meant
int* a = new int;
here, just in case anyone is wondering.
int b = cast(int)a;
int* c = cast(int*)b;
// assert(a == c); // not guaranteed!
The language allows the GC to move around heap data.
What kind of GC would be impossible to implement?
I am by no means a GC expert, but I was under the impression that D
could only make use of conservative GC because of the casting tricks.
D's GC could make use of any advanced GC algorithm I am aware of, it
just has to be implemented (the bottleneck is probably compiler
support). At the moment, the GC is conservative because the compiler
provides no runtime information about which pieces of memory are
pointers/references and which are not
What if Nick's example had inner pointers?
align(1) struct Foo
{
int x, y;
ubyte r, g, b, a;
char[16] ident;
uint[100] data;
Foo* next;
}
That is actually not a problem. Dereferencing an invalid pointer is
unrelated to GC issues. And if the pointer is always valid, then it does
not point to GC memory, therefore it can be ignored by the GC.
Is the GC smart enough to know that Foo.next will contain garbage after
the assignment with cast?
How can it know that it will contain garbage? Not every object in a D
program is necessarily GC heap allocated. But the GC does not have to
care anyway, as soon as unsafe casts are in play it is the
responsibility of the programmer to ensure correctness.
What about when I later assign a valid value to it?
That works as expected, because the type information is available.
