On 2015-02-26 12:07, Steven Schveighoffer wrote:
> On 2/26/15 11:57 AM, captaindet wrote:
>> On 2015-02-26 10:07, Steven Schveighoffer wrote:
>>> Static data I believe is always scanned conservatively because no
>>> type information is stored for it ever, even on allocation (i.e.
>>> program startup).
>>
>> ouh, the confusion goes on... are you saying that
>>
>> {
>> // will be all scanned by GC for
>> // potential pointers into GC managed memory:
>> void[16] buffer0 = void;
>> ubyte[16] buffer1;
>> uint[4] buffer3;
>
> Yes, all 3 are stack based. This is not static data, which would be like uint[4] at module level. Those are also treated as scannable, as the entire stack of every thread is scanned.
>
>> // 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.
>
> -Steve

got it, finally! thanks to everyone for their help.

/det

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?

And is 'new int[N]' better in this regard because it never keeps objects alive?

Ali

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