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

[Ralph Becket]

Okay,

Problem no. 1: when I try to compile with 

  EXTRA_GRADEFLAGS = --gc none --memory-profiling

the compilation aborts with

  ml --grade asm_fast.gc --memory-profiling --gc none         -o compress
Mercury/
  os/compress_init.o \
        Mercury/os/binary_io.o Mercury/os/compress.o Mercury/os/constant.o
Mercu
ry/os/ctable.o
  /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?

Problem no. 2: when I compile with

  EXTRA_GRADEFLAGS = --memory-profiling

and use either mprof or io__report_full_memory_stats//0 I get

  $ ./compress.exe infile outfile

  Memory profile by procedure
           Cells          Words  Procedure label
         2/22.2%       20/37.0%  mercury__tree234__set3_4_1
         3/33.3%       18/33.3%  mercury__tree234__set2_4_1
         4/44.4%       16/29.6%  mercury__tree234__set_4_1

  Memory profile by type
           Cells          Words  Procedure label
         9/100.0%       54/100.0%  tree234:tree234/2

  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
  Memory profile by procedure
         2/22.2%       20/37.0%  mercury__tree234__set3_4_1
         3/33.3%       18/33.3%  mercury__tree234__set2_4_1
         4/44.4%       16/29.6%  mercury__tree234__set_4_1

  Memory profile by type
         9/100.0%       54/100.0%  tree234:tree234/2
  Overall memory usage:+       9        9 cells, +      54       54 words
  ]

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

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.
When I try adding --low-level-debug to EXTRA_GRADEFLAGS, compilation aborts
with

  c2init: invalid option `--low-level-debug'

Help!

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

Cheers,

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