profiling

[Matthew Fluet]

> > Here's the vision: data is really an int array.
> 
> I don't think it's a good idea to move the profile counter array into
> SML space.  If you do, then profiling really affects program behavior
> because we have to gc the array.  

It's harder than I realized.  I forgot that arrays (and hence 'a array ref
ref's) aren't globalized, so getting a "GC invariant" address for the
counter array mutated by the timer handler isn't easy.

> signature MLTON_PROFILE =
>    sig
>       val profile: bool
> 
>       structure Data:
> 	 sig
> 	    type t
> 
> 	    val equals: t * t -> bool
> 	    val free: t -> unit
> 	    val malloc: unit -> t
> 	    val reset: t -> unit
> 	    val write: t * string -> unit
> 	 end
>       
>       val current: unit -> Data.t
>       val setCurrent: Data.t -> unit
>    end
> 
> Actually, equals and current could be implemented at SML level if the
> basis library put a wrapper around the raw profile array and were
> responsible for the initialization and writing at exit of the
> "mlmon.out" main profile array.  I have no problems with that.

I don't understand the last paragraph.  equals should correspond to
identity, not to contents, since the contents of current are likely to be
changing all the time.  So, assuming  type t = Word.word, then equals
certainly can be done in SML; I guess current could be done with a nullary
FFI that simply fetches from a static location used by the profiler.