limit check bug

[Henry Cejtin]

You can't use
    bytesAllocated > limit - frontier
because of LIMIT_SLOP, but you could use
    bytesAllocated + LIMIT_SLOP > limit + LIMIT_SLOP - frontier
assuming  that  we  do not allow either addition to overflow (by now allowing
one to allocate within LIMIT_SLOP of max int or unsigned and by not  allowing
the end of a semispace to get within LIMIT_SLOP of the end of addressability.

The `5 line fix' that I thought I had for big-memory machines is running into
similar  problems  here.   The  point  is  that the amount of memory you have
really can't be assumed to fit in a signed integer.  The whole sysinfo() call
is  clearly  completely  busted here.  On Rico's machines, with 4 gig of RAM,
you get negative numbers.

The right thing to do is to use sysconf(_SC_PHYS_PAGES) to get the number  of
pages  of physical memory, and to then truncate it to 4 gig minus epsilon (or
2 gig minus epsilon if we have to have it fit in  a  signed  integer).   This
doesn't  solve  the  swap problem.  Also, and more importantly, the sysconf()
call returns the actual amount of memory on the machine, not the amount  left
after  the  kernel.  Thus RAM slop would have to be adjusted, and by how much
really depends on how big the kernel is.  Not good.