[mercury-users] Debugging 'memory leaks' (fwd)

[Ondrej Bojar]

Dear Peter,

sorry for too little detail. print_memusage prints the VmData entry from 
/proc/self/status (divided by MemTotal from /proc/meminfo). There are 
probably better ways of getting the information :-/

Thanks for GC_PRINT_STATS. The output indicates that during computation 
(and allocation of some structures), every once a while, gc increases 
the heap size:

...
Increasing heap size by 16777216 after 391396864 allocated bytes
Increasing heap size by 16777216 after 409847296 allocated bytes
...

Other lines talk about garbage collection and reclaimed space. Garbage 
collection happens spontaneously sometimes, and always when I call 
gc.garbage_collect. Nearly always, some or a lot of space is reclaimed, 
but the heapsize never sinks, as show in the truncated log below.

I will try using --boehm-gc-munmap as soon as I get a recent ROTD compiled.

Thanks!
   Ondrej.


...
Initiating full world-stop collection 2 after 615150536 allocd bytes
--> Marking for collection 2 after 615150536 allocd bytes
Collection 1 reclaimed 0 bytes ---> heapsize = 615202816 bytes
...
Increasing heap size by 16777216 after 419446880 allocated bytes
Initiating full world-stop collection 7 after 437491808 allocd bytes
--> Marking for collection 7 after 437491808 allocd bytes
Collection 6 reclaimed 404024736 bytes ---> heapsize = 1118519296 bytes
Increasing heap size by 16777216 after 133816304 allocated bytes
   (this was the last heap increase)
Initiating full world-stop collection 8 after 449146768 allocd bytes
--> Marking for collection 8 after 449146768 allocd bytes
Collection 7 reclaimed 432477104 bytes ---> heapsize = 1135296512 bytes
Initiating full world-stop collection 9 after 444412096 allocd bytes
--> Marking for collection 9 after 444412096 allocd bytes
Collection 8 reclaimed 444523968 bytes ---> heapsize = 1135296512 bytes
Increasing heap size by 16777216 after 11371616 allocated bytes
Initiating full world-stop collection 10 after 456480896 allocd bytes
--> Marking for collection 10 after 456480896 allocd bytes
Collection 9 reclaimed 439818208 bytes ---> heapsize = 1152073728 bytes
Initiating full world-stop collection 11 after 453791888 allocd bytes
--> Marking for collection 11 after 453791888 allocd bytes
Collection 10 reclaimed 453908160 bytes ---> heapsize = 1152073728 bytes
...
Initiating full world-stop collection 15 after 31552 allocd bytes
--> Marking for collection 15 after 31552 allocd bytes
Collection 14 reclaimed 75332272 bytes ---> heapsize = 1152073728 bytes
    (this was the very last garbage collection)



Peter Wang wrote:
> On 2008-03-27, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> Hi, all.
>>
>> My Mercury code is kind of greedy and does not seem to de-allocate all
>> it should. Parts of the code are in C but I use always
>> MR_GC_NEW/NEW_ARRAY to allocate. The main looks like this:
>>
>> main(!IO) :-
>>   do_something_big(!IO),
>>   print_memusage(!IO),
>>   gc.garbage_collect(!IO),
>>   print_memusage(!IO).
>>
>> The do_something_big(io::di, io::uo) contains a 'cached' call. From some
>> hardwired input files, it collects some statistics and saves them to a
>> cache (and say prints them to stdout). Next time when I run the program,
>> it just loads the cache and prints the statistics, so stdout looks
>> identical but the collection was not performed.
>>
>> There are two things I don't like:
>>
>> - memory usage as reported by the first print_memusage is drastically
>> different in the two runs (cached vs. not-yet-cached), do_something_big
>> allocates some temporary structures when doing the statistics but does
>> not release it properly, although nothing is passed back to main (except
>> for altered IO).
>> - print_memusage shows exactly the same amount of memory used before and
>> after garbage_collection in both runs, ie. what was left in the memory
>> still looks reachable for the garbage collector (or gc.garbage_collect
>> is just a NOOP).
> 
> How does print_memusage get its statistics?
> 
> You might try running with GC_PRINT_STATS environment variable set.
> Perhaps the output will help.
> 
> Or you could see if using munmap helps. Search for --boehm-gc-munmap in
> the user's guide, or --munmap in slightly older versions.
> 
> Peter
> 
> --------------------------------------------------------------------------
> mercury-users mailing list
> Post messages to:       mercury-users at csse.unimelb.edu.au
> Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
> Subscriptions:          mercury-users-request at csse.unimelb.edu.au
> --------------------------------------------------------------------------

-- 
Ondrej Bojar (mailto:obo at cuni.cz / bojar at ufal.mff.cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------