if i understand correctly, static arrays are exempt from GC scanning for memory pointers
 http://dlang.org/garbage.html : "Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data."


but there is also a warning for void arrays

http://dlang.org/arrays.html : The garbage collector "will scan void[] arrays for pointers, since such an array may have been implicitly converted from an array of pointers or an array of elements that contain pointers."


does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays?

(because sometimes the docs also mean static arrays even if just "type[]" is written.)

thanks!

ps: this is for 32bit apps

On Thursday, 26 February 2015 at 01:15:37 UTC, captaindet wrote:
> pointers to static data."

Keep in mind that this is pointers TO static data - that is, if the object itself is static, it is not to be collected.

static int[5] foo = [1,2,3,4,5]; // foo will never be collected, even if there are no pointers to it


But, the static array itself will be scanned:

static Object[2] objects;

The objects stored in there won't be garbage collected because this array is still scanned.


So

> does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays?

Both of those will be scanned for pointers.

On 2015-02-25 19:24, Adam D. Ruppe wrote:
>> does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays?
>
> Both of those will be scanned for pointers.

thanks, adam,

so i should always use

struct Stuff2Do{
    static ubyte[1024*1024] buffer4speed = void; // even if untyped at this point

    // more
}

to avoid that the GC is scanning my buffer for pointers?

You don't have to do all that, if it is typed ubyte[] instead of void[], it shouldn't be scanned at all anyway.

On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn wrote: [...]
> struct Stuff2Do{
>     static ubyte[1024*1024] buffer4speed = void; // even if untyped at this point
> 
>     // more
> }
[...]

Tangential note: be careful with putting a large static array inside a struct. Structs are passed by value, which means that if you didn't allocate that struct on the heap and you pass it around to various functions, you will overflow your stack very quickly -- every function call that passes the struct will consume 1MB of stack space. Many OSes do not allocate that much space for the runtime stack.


T

-- 
Real Programmers use "cat > a.out".

On Wed, 25 Feb 2015 20:20:37 -0600, captaindet wrote:

> On 2015-02-25 19:24, Adam D. Ruppe wrote:
>>> does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays?
>>
>> Both of those will be scanned for pointers.
> 
> thanks, adam,
> 
> so i should always use
> 
> struct Stuff2Do{
>      static ubyte[1024*1024] buffer4speed = void; // even if untyped at
>      this point
> 
>      // more
> }
> 
> to avoid that the GC is scanning my buffer for pointers?

compiler is clever enough to not mark `ubyte` arrays as GC ranges.

On 2015-02-25 20:45, H. S. Teoh via Digitalmars-d-learn wrote:
> On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn wrote:
> [...]
>> struct Stuff2Do{
>>      static ubyte[1024*1024] buffer4speed = void; // even if untyped at this point
>>
>>      // more
>> }
> [...]
>
> Tangential note: be careful with putting a large static array inside a
> struct. Structs are passed by value, which means that if you didn't
> allocate that struct on the heap and you pass it around to various
> functions, you will overflow your stack very quickly -- every function
> call that passes the struct will consume 1MB of stack space. Many OSes
> do not allocate that much space for the runtime stack.
>
>
> T
 this is why i tried to get away with a 'static' static array, which only exists once for all Stuff2Do structs. but as it seems, i'll rather need on the order of 512MB buffer, so i will probably go with c.stdlib.malloc

/det

On 2/25/15 8:15 PM, captaindet wrote:
> if i understand correctly, static arrays are exempt from GC scanning for
> memory pointers
>
> http://dlang.org/garbage.html : "Pointers in D can be broadly divided
> into two categories: Those that point to garbage collected memory, and
> those that do not. Examples of the latter are pointers created by calls
> to C's malloc(), pointers received from C library routines, pointers to
> static data."
>
>
> but there is also a warning for void arrays
>
> http://dlang.org/arrays.html : The garbage collector "will scan void[]
> arrays for pointers, since such an array may have been implicitly
> converted from an array of pointers or an array of elements that contain
> pointers."
>
>
> does this warning only apply to dynamic void[] arrays but not to static
> void[CTconstant] arrays?
>
> (because sometimes the docs also mean static arrays even if just
> "type[]" is written.)
>
> thanks!
>
> ps: this is for 32bit apps

Somewhat missing in this disscusion is:

the GC does not know what an array's type currently is, it only knows what it was when it was allocated. So for instance:

ubyte[] arr = cast(ubyte[])(new void[100]); // scanned for pointers
void[] arr = new ubyte[100]; // not scanned for pointers.

In fact, the GC has no idea of type at all. It just knows about memory blocks, and whether those blocks are flagged as having pointers or not having pointers. The call to new is what tells the GC "hm.. this is a type that may contain pointers, set that flag!"

Static data I believe is always scanned conservatively because no type information is stored for it ever, even on allocation (i.e. program startup).

-Steve

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;
        // will not be scanned by GC for pointers:
    void[] buffer4 = cast(void[])(new ubyte[16]);
    uint[] buffer5 = cast(uint[])(new ubyte[16]);
}

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