[MLton-user] Profiling the live heap?

[Wesley W. Terpstra]

On Wed, May 4, 2011 at 3:19 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:

> Wesley once wrote a patch that dumped the heap graph reachable from a
> given root
>

Unfortunately, that program renders the entire memory heap. For Christof's
problem with a multi-GB memory leak, it would just detonate your computer.

It might not be too difficult to tweak the garbage collector to
> compute a histogram (indexed by object representation type) of the
> live heap.
>

This would be quite easy I think.

One difficulty with associating fine-grained allocation information
> with objects is that the object header reserves 19 bits for the index
> into the object types table.  2^19 is (supposedly) more than
> sufficient for the number of different representations of objects
> within a single program, but it probably falls short of the number of
> different allocation sites in a large program.
>

Note, however, than on a 64-bit machine we have 32 otherwise wasted bits in
the object header. Also, allocation sites != allocated type, due to
polymorphism. So the object type might not be what you want.

Does MLton currently combine types with identical structure into a single
structure? I suspect it does not, as (if i recall correctly) it sometimes
uses the object header to distinguish alternative datatype constructors. If
it does combine types, can this be turned off? I am imaging an optional
output table which records the same type name you would see in a MLton error
message for each object type.

My proposal would then be:
1) Add an object type index -> textual type name table
2) Add a new field 'allocation site' that uses some of the spare bits in
64-bit object headers.
3) Add a table that maps allocation site index -> source file location
4) Add a runtime option to increment counters on GC against these tables
5) Provide some mechanism to print out the live heap histogram information,
broken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20110504/65a56d2d/attachment.htm