[m-dev.] question about new memory profiling

[Peter Wang]

On 2011-04-01, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> On 28-Mar-2011, Peter Wang <novalazy at gmail.com> wrote:
> > I have a prototype of this working for low-level C grades so far.
> 
> That's great.
> 
> > 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.
> 
> How much code is there that hand-allocates heap cells? My guess is that
> there are probably less than a hundred, in which case converting them all
> by hand to the new system should not too tedious. The constant structures
> they refer to can be put in non-duplicated foreign_code pragmas.
> 
> > We could retain the type string argument, for existing memprof
> > functionality, but simply accept "unknown" when it comes to summarising
> > the live heap structures.
> 
> Or you could treat a NULL pointer as meaning "unknown". If the fraction
> of memory allocate by "unknown" is low enough, noone will care.

I have a solution now: MR_tag_offset_incr_hp_msg et al continue to take
a type string argument.  For generated code, we pass NULL and it does
nothing.  In hand-written code, the programmer can write a string
literal; the allocation site structure is updated at runtime to point to
the string, so the type is no longer "unknown".

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
--------------------------------------------------------------------------