<div class="gmail_quote">On Wed, May 4, 2011 at 3:19 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wesley once wrote a patch that dumped the heap graph reachable from a<br>
given root<br></blockquote><div><br>Unfortunately, that program renders the entire memory heap. For Christof's problem with a multi-GB memory leak, it would just detonate your computer.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
It might not be too difficult to tweak the garbage collector to<br>
compute a histogram (indexed by object representation type) of the<br>
live heap.<br></blockquote><div><br>This would be quite easy I think. <br></div><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
One difficulty with associating fine-grained allocation information<br>
with objects is that the object header reserves 19 bits for the index<br>
into the object types table. 2^19 is (supposedly) more than<br>
sufficient for the number of different representations of objects<br>
within a single program, but it probably falls short of the number of<br>
different allocation sites in a large program.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>My proposal would then be:<br>1) Add an object type index -> textual type name table<br>2) Add a new field 'allocation site' that uses some of the spare bits in 64-bit object headers. <br>3) Add a table that maps allocation site index -> source file location<br>
4) Add a runtime option to increment counters on GC against these tables<br>5) Provide some mechanism to print out the live heap histogram information, broken <br><br></div></div></div>