Question to GC experts: NO_SCAN for a part of the block

[Steven Schveighoffer via Digitalmars-d]

On Monday, 5 June 2017 at 23:30:00 UTC, Stanislav Blinov wrote:
> On Monday, 5 June 2017 at 13:11:25 UTC, Steven Schveighoffer 
> wrote:
>
>> adding a range marks it as having pointers to scan, AND stores 
>> a reference to that array, so it won't be GC collected (nor 
>> will anything it points to). The intention is for it to be 
>> used on non-GC memory, like C malloc'd memory, where it 
>> doesn't matter that the GC is pointing at it.
>>
>
> Huh?
>
> https://dlang.org/phobos/core_memory.html#.GC.addRange :
>
>> Note that p[0 .. sz] is treated as an opaque range of memory 
>> assumed to be suitably managed by the caller. In particular, 
>> if p points into a GC-managed memory block, addRange does not 
>> mark this block as live.
>
> Is that paragraph wrong?

No I am wrong. I assumed that because the gc is part of the 
static space it's metadata would also be scanned. But the data is 
allocated using c malloc, so it's not scanned. This makes any 
partial insertion using addrange more dangerous actually because 
you have to take care to keep a pointer to that block somewhere

>
>> I would say that you are better off allocating 2 arrays -- one 
>> with NO_SCAN where you put your non-pointer-containing data, 
>> and one without the flag to put your other data. This is 
>> similar to your "selective" function, but instead of 
>> allocating 1 array, with a tuple of slices into it, just 
>> allocate 2 arrays and return the tuple of those 2 arrays.
>
> Then it's just the obvious() function. The whole point of the 
> exercise is to make one GC allocation instead of N :) But still 
> GC, so as not to put additional responsibility on the caller.

No, 2 allocations instead of N.

-Steve