[MLton-user] Profiling the live heap?

[Wesley W. Terpstra]

On Thu, May 5, 2011 at 3:32 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:

> although a slight variation on
> this proposal would be to add the allocation site index to the object
> type, inducing a distinct object type for every allocation site and
> simply use more bits for the object type index with 64-bit headers.
> (The advantage of this is that "small" programs that don't have more
> than 2^19 representation types and allocation sites could still be
> profiled under 32-bits.)
>

I don't think this will work. Currently MLton uses object types to
differentiate alternative datatypes. Under your proposal this would either
not be possible or would inflate the cases considerably.

ie:
datatype foobar = FOO of x | BAR of y
val a = FOO 2
val b = FOO 3
val c = FOO 4
val d = BAR 5

Now when it comes time for a case statement to decide if something is FOO or
BAR it will have three cases for FOO. (I realize that in this particular
case there are so few cases that pointer tagging is used instead)

Still, as long as MLton uses the structure type tag this way, abusing the
field further with call site information will be no fun.

1 is a bit more difficult, because one would need to thread the
> front-end type all the way through the computation.


You've convinced me that the type info wouldn't be useful anyway since MLton
combines types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20110505/a32a37cb/attachment.html