[m-dev.] question about new memory profiling

Peter Wang novalazy at gmail.com
Mon Mar 28 13:43:16 AEDT 2011


Hi,

I'm working on an enhancement to the memprof grade which goes like this.
For each object we allocate an additional word (plus roundup) to
indicate its origin (the procedure label which allocated the object).
At points of interest, the program can force a GC and produce a summary
of where the live objects on the heap were allocated.  I have this
working.

We can get a more detailed summary by making the compiler generate a
data structure for each unique allocation site, like this:

    struct MR_AllocId_Struct {
	MR_Code	    *proc;
	const char  *filename;
	int	    line_number;
	const char  *type_msg;
    };

The extra word is then used to point to instances of these structures;
there is a static array of them per C module.  During module
initialisation the elements of the array are entered into a hash table.
I have a prototype of this working for low-level C grades so far.

The existing memprof grade works by passing two extra arguments like
this:

    MR_tag_incr_hp_msg(dest, tag, count, MR_PROC_LABEL, "sometype")

In generated code, the last two arguments would be replaced by a pointer
one of the structures generated for the allocation site.  The same
information is still available.

    MR_tag_incr_hp_msg(dest, tag, count, &MR_alloc_site_array[42]);

The question now is how to handle allocations in hand-written C code.
The last argument needs to be something like MR_PROC_LABEL: easy to
write, and expand out to something appropriate.

The least worst idea I've had so far is to treat an entire foreign_proc
as a single allocation site, and ignore the object type ("unknown").
Then I can generate an MR_AllocId_Struct per foreign_proc, and #define
a macro which expands out to the address of the structure.  This is
still a step backwards, due to missing the object type.

We could retain the type string argument, for existing memprof
functionality, but simply accept "unknown" when it comes to summarising
the live heap structures.

Any comments would be appreciated.

Peter
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list