On 2/26/15 2:28 PM, Ali Çehreli wrote:
On 02/26/2015 10:07 AM, Steven Schveighoffer wrote:
>> // will not be scanned by GC for pointers:
>> void[] buffer4 = cast(void[])(new ubyte[16]);
>> uint[] buffer5 = cast(uint[])(new ubyte[16]);
>
> Correct, since they are allocated as ubyte[]. uint[] also would not be
> scanned.
I've been under the impression that current GC being imprecise, even an
unfortunate bit-pattern in an int would keep otherwise dead objects
alive. Is that still true for a single int?
It depends on where the int is, not whether it's an int or not. An int
on the stack will be scanned as if it were a pointer, because the GC
does not know the type for those bits.
An int on the heap will be scanned if it is in a block marked as having
pointers.
And is 'new int[N]' better in this regard because it never keeps objects
alive?
Correct, at the point you allocate new int[N], the type system is aware
that the block will NOT contain pointers, so the GC is informed of this.
Now, if you said new int[][N], the block contains pointers, as each
element has a pointer and length. But the lengths will ALSO be scanned
even though they aren't pointers.
This is a heuristic for the scanner. It's very blunt, but it's better
than completely imprecise :)
A truly precise scanner would be informed not only of the block bit
patterns (which bits are alive, which are pointers, etc), but also of
the stack frame and static data bit patterns. Such a scanner would be
better at avoiding leaked memory, but possibly perform worse, since it
may spend extra time parsing type data when the entire block is all
pointers, etc. It also requires more metadata, and can affect cache
coherency. I'll put forth right now, I am NOT the person to ask about
this in any detail :)
-Steve
