[Gc] RE: GC_gcollect and memory usage increase

Boehm, Hans hans.boehm at hp.com
Wed Nov 29 15:56:13 PST 2006


I'm not sure I fully understand the questions.

GC_MALLOC_UNCOLLECTABLE memory is returned to the available part of the
heap and reused only if you explicitly call GC_FREE.  It is scanned by
the collector in order to determine whether it refers to GC_MALLOCed
memory.

Most applications would end up calling GC_MALLOC_UNCOLLECTABLE rarely.

In the default configuration, neither GC_MALLOC nor
GC_MALLOC_UNCOLLECTABLE memory is returned to the OS.  It is just reused
within the process.  (That behavior is somewhat controllable with
-DGC_USE_MUNMAP.)  I believe the default is largely the same as most
malloc/new implementations.

You should not normally call GC_gcollect() at all.  GC_MALLOC calls will
do that when appropriate.

GC_invoke_finalizers() should only be called if GC_finalize_on_demand is
set.  If you do nontrivial things in finalizers, it is safer to do so,
since finalizers can otherwise be called during any allocation, and the
thread may be holding locks that they need.  But this is not the default
in current GC versions.

The last log you sent me still looks rather strange, e.g.

Immediately reclaimed -42480 bytes in heap of size 144072704 bytes
73728 (atomic) + 1312696 (composite) collectable bytes in use
Finalize + initiate sweep took 0 + 0 msecs
Complete collection took 203 msecs
Increasing heap size by 16777216 after 9929220 allocated bytes
Increasing heap size by 16777216 after 29979960 allocated bytes
Increasing heap size by 16777216 after 47386008 allocated bytes
Increasing heap size by 16777216 after 64783496 allocated bytes
Increasing heap size by 16777216 after 82239408 allocated bytes
Increasing heap size by 16777216 after 99258716 allocated bytes
Increasing heap size by 16777216 after 116602120 allocated bytes
Increasing heap size by 16777216 after 133944636 allocated bytes
Increasing heap size by 16777216 after 151271368 allocated bytes
Increasing heap size by 16777216 after 168588356 allocated bytes
Initiating full world-stop collection 53 after 169803904 allocd bytes
1531904 bytes in heap blacklisted for interior pointers
--> Marking for collection 53 after 169803904 allocd bytes + 64463012
wasted bytes
Collection 52 reclaimed 1482160 bytes ---> heapsize = 311844864 bytes
World-stopped marking took 469 msecs
Bytes recovered before sweep - f.l. count = -86704
Immediately reclaimed 8338768 bytes in heap of size 311844864 bytes
258048 (atomic) + 2068600 (composite) collectable bytes in use

It would be interesting to see GC_dump() output at the call the
GC_expand_hp_inner() that corresponds to one of the first "Increasing
heap ..." messages, as well as the call stack at that point.  Given that
it found very little live memory in the heap, and it's only allocated 10
MB out of a 144MB heap, I'm not sure why the allocation requests cannot
be satisfied without heap expansion.  You may be allocating very large
objects, and there may not be enough room between black-listed heap
sections.  Or you may be seeing some weird fragmentation issues,
possibly aggravated by the fact that nearly everything is uncollectable
and hence the collector runs less frequently to coalesce objects.

Hans

> -----Original Message-----
> From: Simon Tsai [mailto:mtsai at adobe.com] 
> Sent: Wednesday, November 29, 2006 3:06 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: RE: GC_gcollect and memory usage increase
> 
> I trace the gc library and found out I need turn on 
> GC_OPERATOR_NEW_ARRAY flag in my application (c++). I need 
> call GC_FREE for GC_MALLOC. One of my applications will run 
> ok. But I have another application; it keeps allocating 
> memory with GC_MALLOC_UNCOLLECTABLE and free memory with 
> GC_FREE. It also calls GC_MALLOC. From my trace, the 
> GC_MALLOC_UNCOLLECTABLE can accumulate a few GBytes. The 
> GC_MALLOC may only have 100 Mbytes. When my application calls 
> GC_gcollect() &
> GC_invoke_finalizers() , the memory starts to jump. 
> Questions:
> 1. Does gc library really free UNCOLLECTABLE memory? Or it 
> just keeps the memory in library for reuse? 
> 2. When does gc library free UNCOLLECTABLE memory?
> 3. Do I call GC_gcollect and GC_invoke_finalizers at the same 
> time? Or I just need call GC_gcollect every few minutes?
> 
> 
> simon
> 



More information about the Gc mailing list