Re: [Gc] Memory leak in GC_allochblk_nth
ivmai at mail.ru
Tue Dec 2 04:25:16 PST 2008
"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?
> 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?
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?
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).
Anyhow, I think, this behavior should be clearly specified in gc.h.
More information about the Gc