[m-dev.] Still having problems with memory profiling
fjh at cs.mu.OZ.AU
Fri Oct 1 02:51:17 AEST 1999
On 30-Sep-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> 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
> 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).
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
> 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
> c2init: invalid option `--low-level-debug'
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:
| 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.
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 188.8.131.52 | -- 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
More information about the developers