----- Original Message ----
> From: Sean Kelly <[email protected]>
>
> On Aug 26, 2010, at 10:18 AM, Andrei Alexandrescu wrote:
>
> > Walter, Sean, could we arrange such that capacity of static arrays yields
>zero?
> >
> > Andrei
>
> It already does. I've just realized that the current length implementation
>can have some weird side-effects at times though:
>
> writeln(GC.sizeOf((new byte[2046]).ptr));
> writeln(GC.sizeOf((new byte[2047]).ptr));
>
> prints:
>
> 2048
> 0
>
> Because the length of large arrays is located at the beginning of the memory
>block, and this is placed by the runtime (I believe), the GC assumes that
>large
>arrays are all interior slices.
That is something I want to fix. My reasons for putting the length at the
front
were purely for shared arrays. The issue is, once you call gc_query on a
block,
it could change if another thread came along and extended it. This can be a
problem if the length is stored at the end of the block, because the end of the
block can move! Unshared arrays don't have this problem because they cannot be
changed from another thread.
There's a few ways we could fix this so the length is not stored at the
beginning. One is, of course, store the length outside the block :) Another
is, we could put a global lock on all shared appends to avoid the block
changing
underneath us. Another possibility is to store a lock bit for the block,
thereby preventing anything else from changing the size. This would only
happen
for shared arrays of course, unshared arrays wouldn't need any locking.
>
> Also:
>
> auto x = new byte[100];
> writeln(x.capacity);
> x = x[1 .. $];
> writeln(x.capacity);
>
> prints:
>
> 127
> 126
>
> Shouldn't the second capacity be 0, since it's a slice?
Slices can be appended to. The key is not where they start, but where they
end. If you think about it, it makes a lot of sense.
-Steve
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
