[m-rev.] for review: memory attribution profiling

[Julien Fischer]

On Thu, 21 Apr 2011, Peter Wang wrote:

> Branches: main
>
> Implement a new form of memory profiling, which tells the user what memory
> is being retained during a program run.  This is done by allocating an extra
> word before each cell, which is used to "attribute" the cell to an
> allocation site.  The attribution, or "allocation id", is an address to an
> MR_AllocSiteInfo structure generated by the Mercury compiler, giving the
> procedure, filename and line number of the allocation, and the type
> constructor and arity of the cell that it allocates.
>
> The user must manually instrument the program with calls to
> `benchmarking.report_memory_attribution', which forces a GC and summarises
> the live objects on the heap using the attributions.  The mprof tool is
> extended with a new mode to parse and present that data.
>
> Objects which are unattributed (e.g. by hand-written C code which hasn't
> been updated) are still accounted for, but show up in profiles as "unknown".
>
> Currently this profiling mode only works in conjunction wtih the Boehm

s/wtih/with/

> garbage collector, though in principle it can work with any memory allocator
> for which we can access a list of the live objects.  Since term size
> profiling relies on the same technique of using an extra word per memory
> cell, the two profiling modes are incompatible.
>
> The output from `mprof -s' looks like this:
>
> ------ [1] some label ------
>   cells            words         cumul  procedure / type (location)
>   14150            38872                total
>
> *   1949/ 13.8%      4872/ 12.5%  12.5%  <predicate `parser.parse_rest/7' mode 0>
>     975/  6.9%      1950/  5.0%         list.list/1 (parser.m:502)
>     487/  3.4%      1948/  5.0%         term.term/1 (parser.m:501)
>     487/  3.4%       974/  2.5%         term.const/0 (parser.m:501)
>
> *   1424/ 10.1%      4272/ 11.0%  23.5%  <predicate `parser.parse_simple_term_2/6' mode 0>
>     708/  5.0%      2832/  7.3%         term.term/1 (parser.m:643)
>     708/  5.0%      1416/  3.6%         term.const/0 (parser.m:643)
> ...
>
>
> boehm_gc/alloc.c:
> boehm_gc/include/gc.h:
> boehm_gc/misc.c:
> boehm_gc/reclaim.c:
> 	Add a callback function to be called for every live object after a GC.
>
> 	Add a function to write out the GC_size_map array.

We should try to push these changes upstream.

...

> diff --git a/library/benchmarking.m b/library/benchmarking.m
> index b2bd1ab..78dc8bb 100644
> --- a/library/benchmarking.m
> +++ b/library/benchmarking.m
> @@ -42,6 +42,19 @@
>     %
> :- impure pred report_full_memory_stats is det.
>
> +    % report_memory_attribution(Label, !IO) is a procedure intended for use in
> +    % profiling the memory usage by a program. On `memprof.gc' grades it has

s/On/In/

> +    % the side-effect of forcing a garbage collection and reporting a summary
> +    % of the objects on the heap to a data file. See ``Using mprof -s for
> +    % profiling memory retention'' in the Mercury User's Guide. The label is
> +    % for your reference.
> +    %
> +    % On other grades this procedure does nothing.
> +    %
> +:- pred report_memory_attribution(string::in, io::di, io::uo) is det.
> +
> +:- impure pred report_memory_attribution(string::in) is det.

Looks fine otherwise (modulo the changes to the user's guide mentioned
in my other review).

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