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

[Matthew Fluet]

> 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
wc-scanStream.



-------------------------------------------------------
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.
www.ictp.com/training/sourceforge.asp
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel