strange real timings partly explained

[Stephen Weeks]

> > I was looking at the heap, but you are right, the stack is also relevant.
> > Does the GC know enough to do the alignment?  I didn't think it knew about
> > doubles, just pointer vs. non-pointer.
> 
> The heap doesn't know anything about doubles.  But, I think this is
> another place where RCPS could really help.  Tune the representation so
> that all doubles in an object are aligned mod 8 iff the beginning of the
> object is aligned mod 8.  Now we just need one bit of the object header to
> tell the GC whether or not it needs to align the object mod 8.  

Sounds reasonable to me.

>  The
> initial heap allocation of the object would also need to be tweaked,
> although there are subtlties there -- at compile time, we know what kind
> of object we're allocating, so we can include or exclude the frontier
> alignment check;  but, we can't arbitrarily roll the frontier forward if
> we need alignment, because the last limit check won't have taken that into
> account.  On the other hand, maybe we can do that -- we just over-estimate
> the size of an object taking into account the possible padding needed for
> the alignment and use that as the limit check size.

Yeah, this is easy, and we do something similar already.  In the compile time
computation of object sizes used for calculating the bytes needed along a path,
we can simply conservatively overestimate the "size" of objects with doubles by
adding 4.