big arrays [was Re: bug found]

[Matthew Fluet]

> The GC looks like it would be ok with no tests required.  I was assuming that
> the mutator never looks at the headers (except in object allocation).  Is that
> not true?

It is true that the mutator never looks at headers, except when allocating
an object (in which case, it constructs the header).

However, toData needs to be able to distinguish between arrays and
non-arrays based exclusively on a pointer to the first word of the object. 
(Using header followed by length, we need to distinguish between array and
non-array headers.)

GC_foreachPointerInObject requires you to be able to distinguish between
normal objects, stacks/conts, and arrays based on a pointer to the first
data word of the object (i.e., where the real object begins). 
Currently, GC_foreachPointerInObject distinguishes based on the object
header, but it could be more complicated than that.

This actually makes the whole problem a little clearer to me.  We have an
artificially low number of bits available for an array length, because, at
different times, we need to interpret both the header word and the array
length word as a header word that can distinguish between arrays and
non-arrays.  What we really want is to be able to distinguish between
normal objects, stacks/conts, and arrays from a pointer to the first data
word of the object and to be able to distinguish between object headers
and array lengths from a pointer to the word preceeding the first data
word of an object.

That would require something like:

Header word
                 mark
        31 30 29 28
normal   1  0  0
stack    1  1  0
cont     1  1  1
array    1  0  1

Length word

        31
         0


Along with
static inline word* GC_getHeaderp(pointer p) {
        word* q = (p - WORD_SIZE);
        if (*q & HIGH_BIT)
		return q;
	else
		return (q - WORD_SIZE);
}

and the obvious changes to is???Header functions.

I think that would allow us to do header followed by length, with arrays
of length <= valOf(Int.maxInt).