[MLton] Re: Memory layout debugging

[Wesley W. Terpstra]

I've implemented it. Patch attached. It's pretty cool, I think. :-)
You use it with MLton.dot (filename, title, obj option). If you pass
SOME object, it traces starting only from that root. If you pass NONE,
it traces the entire heap. The dot output code adds 4k to the runtime
(and hence executable) size.

It costs dot about 230* the memory of the dumped core to render it.
I've had the best luck outputting svg files. dot seems to work well at
that. I suspect I'll have to give up on the cool html-style dot files
to reduce dot's memory footprint.

On Sun, Nov 2, 2008 at 4:40 PM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
> To make this picture easier to understand, it would be helpful if
> objects had their point of allocation or type marked. I know that
> -profile alloc is able to record the # of allocations at a point in
> the program. However, I also understand that there may be several
> points in the program which allocate a given objectType. What sort of
> sensible information could I provide based on the object type?

At the moment I just put the object type as a number below the object.
I would like to report something more useful here.

> The other question is how to get this information back to ML. I could
> just spew the graphviz data to stderr, but this seems crude. I could
> also allocate a C-side string that I keep growing as the dotfile
> grows, then convert this string to an ML-string inside the basis
> library. What's best?

I went with writing to a file specified by the user. Keeping it in RAM
wouldn't work because the dot code is much larger than the heap.

The output format I used isn't the greatest, but it's enough to play
around with. Enjoy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dot.patch
Type: text/x-patch
Size: 20605 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20081103/6773bf9b/dot-0001.bin