[m-dev.] for review: memory profiling [2/2]

[Fergus Henderson]

On 05-Dec-1997, Zoltan Somogyi <zs at cs.mu.oz.au> wrote:
> 
> I don't like the fact that countfile can stand for different sorts of files.
> It would seem more logical to have a different option for each kind of file
> content, and for options such as --profile-memory-words to select which
> option's value is used.

True.  But a bit harder to implement.
I'll have another look at it.

> > -#define create1(w1)	(					\
> > -				hp_alloc(1),			\
> > -				MR_hp[-1] = (Word) (w1),		\
> > -				debugcr1(MR_hp[-1], MR_hp),		\
> > -				/* return */ (Word) (MR_hp - 1)	\
> > -			)
> > +#define create1(w1)						\
> > +	(							\
> > +		hp_alloc(1),					\
> > +		MR_hp[-1] = (Word) (w1),			\
> > +		debugcr1(MR_hp[-1], MR_hp),			\
> > +		/* return */ (Word) (MR_hp - 1)			\
> > +	)
> 
> I think this macro and its ilk can now be safely deleted.

They're still used by list_cons() in mercury_tags.h.
We can delete them eventually, but that can be a separate change.

> > +typedef	struct MR_memprof_counter
> > +{
> > +	MR_dword	cells_at_period_start;		/* ? what for? */
> > +	MR_dword	words_at_period_start;		/* ? what for? */
> > +	MR_dword	cells_since_period_start;
> > +	MR_dword	words_since_period_start;
> > +} MR_memprof_counter;
> 
> I thought the "what for" was obvious: you want to know both the number of cells
> allocated by e.g. a procedure in the whole of the run, as well since the last
> report. For this you need two pairs of counters. With the arrangement above,
> you need to increment only one pair at each allocation.

The thing that wasn't clear was what a "period" was.  I've added the following
documentation:

	** We keep track of how much allocation occurs in each "period".
	** A period ends (and a new period begins) at each call to
	** report_stats or report_full_memory_stats in library/benchmarking.m.
	** We also keep track of the total allocation over all periods.

> > +#include	"mercury_imp.h"	/* we need libmer_globals.h for Windows DLLs *
> 
> What is libmer_globals.h?

>From Makefile.DLLs:

# We need to use macros to access global data:
# the user of the DLL must refer to `bar' as `(*__imp_bar)'.
# This rule creates a pair of files `foo_dll.h' and `foo_globals.h'
# which contains macros for doing this.

I've changed the comment to refer to libmer_dll.h rather than
libmer_globals.h, since that is what mercury_imp.h includes.
I've also added a little bit more documentation to the Mmakefile
and to mercury_imp.h.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.