bug found

[Stephen Weeks]

> Note there is a trivial way to get bigger arrays, but it would make
> Array.length slightly more expensive: you just have a different header
> (using an extra word) for big ones.  The sub and update and all of those
> would not change (although the cost of the runtime check on subscript out of
> bounds would go up).  Not really ok because of the bounds check, but I'm
> trying to see if I can come up with something more clever.

Hmmm.  This gives me an idea.

The only thing we need to do is to distinguish between array lengths
and object headers.  So, if we make array lengths two words, the first
of which will always be all zero, and the second containing the
length, as it does now, we can have lengths up to 2G, which is the max
we can hope for with 32 bit ints anyways.  There is no additional cost
for bounds checking.  The only cost is an added word of space per
array.