Dynamic array as stack and GC.BlkAttr.APPENDABLE

[Steven Schveighoffer via Digitalmars-d]

On 11/14/14 8:56 PM, IgorStepanov wrote:
> On Friday, 14 November 2014 at 23:49:00 UTC, ketmar via Digitalmars-d
> wrote:
>> On Fri, 14 Nov 2014 23:23:17 +0000
>> IgorStepanov via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>>> What does the NO_INTERIOR flag?
>> it stops GC to acknowledge pointers inside allocated area as anchors.
>> i.e. if there is no pointer to the head (first address) of allocated
>> memory, it is assumed to be garbage.
>>
>> this way we have much less "false pointers", and GC not doing
>> pointer->block conversions.
>>
>> for buckets we certainly has "head pointer" and can't have pointers to
>> bucket elements without "head pointer". so it's safe to tell GC that it
>> shouldn't do unnecessary work.
>
> In other words, if buckets array will contain only uint-s there is no
> reason to mark buckets with NO_INTERIOR?

In case ketmar's reply doesn't drive it home...

NO_INTERIOR means that the GC should NOT consider pointers to a block as 
valid references if those pointers don't point to the HEAD of the block. 
In other words, they point to the interior.

An example

int * x = new int;
*x = 5;
byte *b = cast(byte *)x;
b++; // b is now an interior pointer, yet x is not.

If we had marked x's block as NO_INTERIOR, we are fine as long as x 
remains. If we set x to null, there is a danger that the block is 
collected, and now b is dangling.

Now, this isn't a whole lot more efficient, you still have to look up 
what b points at and see that it has the flag set. BUT, where it DOES 
help is if you had some size_t somewhere on a stack, that happens to be 
the same value as b, the GC may think it's a pointer, but correctly not 
keep the block alive just for that "false pointer". The larger the 
block, the more helpful NO_INTERIOR is.

-Steve