profiling bug understood

[Stephen Weeks]

> The moral of the story, which is not bad any way, is that we will just  write
> our  own  profiling  startup and shutdown code.  This is pretty trivial and I
> have never been very happy with the versions in glibc  any  way.   I'll  hack
> something together tomorrow. 

Is there any reason this couldn't be written in SML as part of MLton's basis
library.  I'm thinking you could add a flag MLton.profile (like MLton.safe) and
make the appropriate calls to MLton.itimer.set when MLton.profile = true.  You
have access to timers, signals, arrays, files, and OS.Process.atExit by the end
of the basis library definition.  If there's anything else that's missing, we
should add it.

> I will also take this opportunity to change the
> bin size from 2 bytes to 4.  The 2 byte size REALLY SUCKS.  Since  the  clock
> runs  at  100  Hz,  it  only  takes 655.36 seconds, or a bit under 11 minutes
> before it might wrap.  I have seen cases where the run time  is  sufficiently
> concentrated  that  it did overflow some bins in 30 minutes.  This results in
> incorrect results.  You can detect that something happend if you  keep  track
> of the user+sys time and compare that to the total number of ticks.  Going to
> 4 bytes means this will never happen unless the run  takes  at  least  1  CPU
> year.

Sounds fine.  While we're at it, there's no need to call the file gmon.out
anymore, right?  We should probably change the name since it's a new format.