[phobos] phobos commit, revision 1930

[Steve Schveighoffer]

----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> 
> 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