[MLton-user] Problem with Timer.checkCPUTimer on Sparc
Sun, 2 Nov 2003 21:18:24 -0800
> Note that gc time is 170 usec & usr time is 140 usec. But that is impossible,
> since usr time *includes* gc time, according to the SML doc at
> So it seems like my code took negative time. ??? Is this a bug?
> Did I make a mistake?
The Basis spec doesn't make it clear to me whether system time spent
during garbage collection should be allocated to usr or sys. Right
now, MLton gets the usr and sys values from a call to getrusage. This
has the effect of allocating system time spent during garbage
collection to sys. To allocate the system time to usr would require
extra bookkeeping to keep track of the system time spent in gc and to
subtract it off from sys and add it to usr. That seems odd to me.
I'll ask around to see what other SML implementors think.
So, with the current MLton implementation, usr + sys should always be
greater than or equal to gc, but usr alone might not be.
Another possible explanation for the anomaly is that a GC occurred
between the call to Timer.checkCPUTimer and the call to
Timer.checkGCTime. I don't think this is likely, since only C calls
are going on so I don't see where MLton might insert a limit check.
But it is possible. You might reverse the order of the calls and see
if you still see the anomaly to rule out this explanation. You could
also use the (nonportable) MLton.Rusage.rusage function to make a
single C call that gets all the values with a single C call.
Other than that, I looked through the MLton sources and don't see any
errors. If you want to have a look for yourself, here are the
defines the Timer structure implemented with MLtonRusage.rusage
_imports from rusage.c
defines MLton_Rusage_ru and accessor functions
maintains gcState.ru_gc, which is used by by MLton_Rusage_ru