GC improvement

[Stephen Weeks]

> I  did  a  quick  hack  changing  gc.h  to  use my wordAlign() definition and
> changing forward() in gc.c to  actually  test  to  make  sure  that  all  the
> alignments  were  satisfied  and  to  then  just loop moving words instead of
> calling memmove().  The result in a self compile was that GC  time  decreased
> by 27% on a Red Hat 6.2 machine.  Not huge, but definitely not bad.  The most

I'd say huge :-).  Very cool.  I see the same speedup.

Here is a normal self compile.
	MLton finished in 354.95 + 219.67 (38% GC)
	569.12user 5.55system 9:45.74elapsed 98%CPU

Here is with your hack.
	MLton finished in 359.66 + 161.64 (31% GC)
	512.76user 8.59system 9:00.89elapsed 96%CPU

So, 10% off overall self-compile time.

> extreme case is going to be  when  the  live  data  consists  of  many  small
> objects.  I don't know if this is the case with the self compile or not.

Probably.  There may be a few large arrays for hash tables, but most everything
is small.

> Any way, here are the changes to the two files.  I will probably do some more
> serious hacking on the gc, but if you agree that the relevant alignments  are
> all  true  in  the copy loop,

They're not all true, but "to" and "from" are word aligned.  "size" is not
because it is the number of bytes to copy, not the size of of the object.  In
the case of stacks, size is the number of bytes in use in the stack, which is
not (currently) word aligned.  What is true is that size + skip is word aligned.
Anyways, the fix to your code is to change

+ 			until (from == limit)
+ 				*to++ = *from++;

to 

+ 			until (from >= limit)
+ 				*to++ = *from++;

This may copy an extra three bytes for a stack, but who cares.  Those bytes will
never be looked at.