[Gc] Atomic page-sized blocks
hans.boehm at hp.com
Thu Feb 26 15:35:57 PST 2004
The collector blacklisting mechanism "allocates" such objects and drops them.
This normally happens if the collector discovered an identifiable false pointer
to the page, causing the allocator to avoid it, and the allocator repeatedly
scanned that page while trying find a suitable one. In this case the page is
allocated as pointerfree and dropped to avoid the performance cost of the
allocator repeatedly considering it for allocation.
The good news: Odds are that this isn't really costing you much, at least on Linux.
These are pages that were probably never touched. Hence they should have no actual
memory or disk space associated with them. They will cost you address space, but in
most cases that's cheap.
The bad news: Having 10% to 20% in this category is really too high. You should
also be able to see this in the blacklist statistics produced by GC_dump(). If it's
easy to make more use of GC_MALLOC_ATOMIC, that should help. If you are dealing
with a large heap, you should also make sure that the collector was built with
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of David Jones
> Sent: Thursday, February 26, 2004 2:08 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Atomic page-sized blocks
> In order to debug memory use in my application, I am
> traversing the collected
> heap (using GC_apply_to_all_blocks()) and testing each object using
> I am coming across several objects allocated pointer-free,
> each 4096 bytes
> long, my page size. I cannot find where in my application I
> am allocating
> them - I am using the debug versions of GC_malloc_*() and all
> my other
> objects are tracing back properly.
> Does the collector use zeroed pages interally for some
> reason, say, awaiting
> redeployment for future allocations? Strange that they are
> marked, though.
> Is GC_is_marked() reliable for objects bigger than a page?
> I am seeing 10-20% of my heap space taken by these objects,
> so I am interested
> in tracking them down.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc