[m-dev.] Still having problems with memory profiling

[Fergus Henderson]

On 30-Sep-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> Okay,
> 
> Problem no. 1: when I try to compile with 
> 
>   EXTRA_GRADEFLAGS = --gc none --memory-profiling
> 
> the compilation aborts with
> 
>   /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: cannot open
> -lmer_std:
>   No such file or directory
>   collect2: ld returned 1 exit status
>   make: *** [compress] Error 1
> 
> Not sure what's going on here - any guesses?

The library has not been installed in that grade.
Try just using `--memory-profiling' without `--gc none'
(the results should be pretty much the same, unless
you are calling any of the all-solutions predicates).
Or do

	mmake install_grades LIBGRADES=asm_fast.memprof

in from the top-level directory of the source distribution
to install that grade of the library.
(The name `asm_fast.memprof' can be obtained by doing `mmc --grade \
asm_fast.gc --memory-profiling --gc none --output-grade-string'.)

> Problem no. 2: when I compile with
> 
>   EXTRA_GRADEFLAGS = --memory-profiling
> 
> and use either mprof or io__report_full_memory_stats//0 I get
...
>   Overall memory usage:        9 cells,       54 words
> 
> which suggests that no memory allocation is happening after initialisation
> (I'm not using any of the predicates that are missed by memory profiling
> except one call to io__command_line_arguments//1).  HOWEVER, when I use
> io__report_stats I get
> 
>   $ ./compress.exe infile outfile
>   [Time: +2.924s, 2.924s, D Stack: 0.035k, ND Stack: 0.023k,
>   #GCs: 7, Heap used since last GC: 818.992k, Total used: 7308.000k

You must be allocating some memory that is not tracked by the
memory profiler.

> Now I am allocating a single 69001 int array, which comes to about 28Kbytes.
> The rest of the program absolutely *should not* be doing any allocation - 
> there's no higher order stuff in there and there are no type constructors
> with arguments other than io__result which should be optimised away since
> I'm compiling with
> 
>   EXTRA_MCFLAGS = -O 6 --intermodule-optimization

Are you using any floating point?
Boxing of floating point values is one of the things that
the memory profiler does not track.

> I'm just a tad concerned about what's going on here.  Could it be a bad
> interaction with the Windows environment (I'm using W2K...)?  The problem
> I'm trying to track down is that if I compile with
> 
>   EXTRA_GRADEFLAGS = --gc none
> 
> then I get
> 
>   $ ./compress.exe infile outfile
>   *** Mercury runtime: caught segmentation violation ***
>   You can get a stack dump by using `--low-level-debug'
>   exiting from signal handler
> 
> which smells like a memory error to me.

That smells to me like a code generation bug in the Mercury compiler.
Please send a bug report to mercury-bugs at cs.mu.oz.au.

> When I try adding --low-level-debug to EXTRA_GRADEFLAGS, compilation aborts
> with
> 
>   c2init: invalid option `--low-level-debug'
> 
> Help!

You would need to add it to EXTRA_MGNUCFLAGS and EXTRA_MLFLAGS
rather than EXTRA_GRADEFLAGS.
You would also need to install versions of the Mercury runtime and
standard library compiled in that grade.

But if I were you, I wouldn't bother.
>From the Mercury User's Guide:

 | ``--low-level-debug''
 | 	Enables various low-level debugging stuff that was in the distant
 | 	past used to debug the Mercury compiler's low-level code
 | 	generation.  This option is not likely to be useful to anyone
 | 	except the Mercury implementors.

Emphasis on the last sentence.

In fact, this option is not likely to be that useful to the Mercury
implementors either.  To debug problems like this, I generally
just compile with --c-debug and then use gdb.

> Aside: for time critical code sections it might be useful to have a higher-
> order predicate that runs its argument with GC turned off.

Features for controlling the GC could be easily implemented by using
the C interface to access the various facilities in boehm_gc/gc.h,
in particular the `GC_dont_gc' variable and the functions
GC_gcollect(), GC_enable_incremental(), GC_collect_a_little(),
and GC_try_to_collect().  Probably they should go in a new library
module called `gc'.  Patches welcome.

Cheers,
	Fergus.

-- 
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.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------