[Gc] Memory leak in GC_allochblk_nth
hans.boehm at hp.com
Wed Dec 3 17:29:31 PST 2008
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Tuesday, December 02, 2008 4:25 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Memory leak in GC_allochblk_nth
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > > -----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 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.
> But, please say, could this "normal" behavior of GC (you are
> talking of) result in a memory (GC_get_heap_size value is
> around 2GB) overflow (with a 32-bit ABI) for an application
> (running in all_interior_poiners mode on (and using normal
> GC_malloc_atomic (for 300K arrays holding screen images)))
> those GC_get_heap_size value floats around 10MB (and is never
> above 30MB at peaks) if all_interior_poiners mode turned off
> or if ignore_off_page allocations are used instead, or if
> another collector (without blacklisting) is used?
Possibly. It might be interesting to look at a GC_dump snapshot and the gc log. If the heap is growing over time, collections just aren't reclaiming much, and the heap consists primarily of those 300K objects, then I suspect this is somewhat unavoidable. You are presumably allocating images with GC_MALLOC_ATOMIC or the like? With that, you'll of course get lots of spurious "pointers" in the images themselves, especially if they're compressed.
> > Switching to a 64-bit ABI should be a pretty complete fix.
> This is really a dense address space issue.
> I agree (but I can't test my above sample/demo app in 64-bit
> mode for now (due to external 32-bit 3rd-party DLLs used)).
> > > 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.
> Some points to refine:
> 1. Pointers into the first 256 bytes of ignore_off_page
> objects are always guaranteed to be recognized if they
> originate from a register/stack. Right?
Correct. Really it's pointers to the first heap chunk, but we don't want to export its real value.
> 2. If an application always keeps base pointers (without
> "volatile") for all allocated objects then it should be
> always safe to turn all_interior_pointers mode off
> (regardless of compilation optimization level). Right?
Yes. That's the idea. Or if it explicitly registers offsets that it uses.
> 3. If "even with all_interior_pointers mode off, the
> collector still looks for interior pointers from the stack
> and registers" is true then a tail byte should be always
> added regardless of all_interior_pointers (unless
> DONT_ADD_BYTE_AT_END is defined).
I believe it currently does not do that. We effectively assume that compiler-generated derived pointers will point to inside the object. We do make assumptions about the compiler not hiding pointers.
> Anyhow, I think, this behavior should be clearly specified in gc.h.
> > Hans
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc