[MLton-devel] experimental release of source-level profiling

Matthew Fluet fluet@CS.Cornell.EDU
Tue, 21 Jan 2003 17:10:44 -0500 (EST)

> Don't work on it too hard, unless it was a general bug with
> GCStateVolatile that needs fixed.  I'm working on another solution
> that avoids the use of currentSource entirely.

There was a general bug in the way GCStateVolatile was being handled.
Interestingly, failing to update the memory location only occured during
the Machine IL main function (the old initGlobals).  Because this function
executes once and linearly (for the most part; just one heap check/gc and
array inits) and does nothing but object (and array) allocations, I forgoe
fancy liveness analysis (which is used for other functions to improve
register allocation) at the expense of a slightly poorer register
allocation.  But, the functionality of volatile memory was being
implemented by the liveness analysis.  I fixed this my ensuring that
volatile memory locations are ejected before use (i.e., can't have been
cached) and removed (and committed) after defs.  I'll check that in
shortly.  It does fix the anomalous GC_arrayAllocate stack counts in

This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
MLton-devel mailing list