[Gc] Memory leak in GC_allochblk_nth

Boehm, Hans hans.boehm at hp.com
Mon Dec 1 16:54:33 PST 2008


> -----Original Message-----
> From:  Ivan Maidanski
> Sent: Tuesday, November 25, 2008 11:57 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Memory leak in GC_allochblk_nth
>
> Hi!
>
> My problem is as follows...
> My (demo/test) application allocates several large (>300K)
> atomic objects, drops them quickly and repeats this
> alocation/dropping cycle many times - as a result I observer
> memory leakage (together with the repeated GC warning about
> it) and, then, some time later, out of virtual memory. Naive
> removal of the code block around WARN("Repeated allocation of
> very large block...") (together with "size_avail =
> orig_avail;") doesn't help at all (even more it results in
> "unreasonable heap growth").
>
> So, there are several possible (and working) solutions: turn
> off all_interior_pointers mode and/or use "ignore_off_page"
> versions of GC_malloc[_atomic]() (or choose between normal
> and "ignore_off_page" versions dynamically). But these
> solutions require addition of "volatile" qualifier for
> pointers (to prevent compiler optimization) which is not
> acceptable to me.
"Volatile" is a bit ill-defined.  But it should be fine to just keep both volatile and non-volatile copies of the pointer to such a large object, accessing it through the non-volatile one, and making sure the GC can see the volatile one.  Thus this shouldn't incur substantial overhead.  You just want to adequately discourage the compiler from optimizing away the last pointer to the base of the object.
>
> My questions:
> 1. Is it possible to fix GC_allochblk_nth() to prevent memory
> leak for GC_malloc with all_interior_pointers mode on (even
> if it results in "unreasonable heap growth")?
Not that I know of.  This "leak" is normally just a consequence of allocating an object that is too large to fit between known "false pointers" that already "point" to unoccupied sections of the heap.  Some of these "false pointers" may be due to the collector not cleaning up after itself, and leaving values lying around that look like pointers.  By fixing these, you might be able to allocate somewhat larger objects before you run into the problem.

Switching to a 64-bit ABI should be a pretty complete fix.  This is really a dense address space issue.

> 2. What's the difference between "normal" and
> "ignore_off_page" versions of GC_malloc if
> all_interior_pointers mode if off? (and what's the difference
> between all_interior_pointers mode on and off for
> GC_malloc_ignore_off_page?)
Even with all_interior_pointers mode off, the collector still looks for interior pointers from the stack and registers,since those often result from compiler optimizations.  Pointers into ignore_off_page objects are ignored even if they originate from a register.

Hans
>
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list