static void arrays under garbage control?

[Steven Schveighoffer via Digitalmars-d-learn]

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