[Gc] heapsize == blocks_in_use_bytes * 40
Hans.Boehm at hp.com
Tue Oct 10 20:13:33 PDT 2006
On Tue, 10 Oct 2006, Adam Megacz wrote:
> Hi everyone,
> I've been hunting down a memory consumption problem, and it appears
> that the GC is asking for ~40 times as much memory from the OS as the
> app is actually using. Have I interpreted this log (see below)
> correctly? Any suggestions on the next step for figuring out why this
You really want to put a breakpoint in GC_expand_hp_inner and try
to understand from the stack trace why the heap is growing. You
want to ignore the initial "reasonable" heap expansions, and look
at one of the last ones. If your application allocates and drops
very large arrays, this sort of thing can happen due to fragmentation.
(-DUSE_MUNMAP may be a workaround.)
> The GC reports the heapsize (which I interpret to mean the quantity of
> memory allocated from the OS) to be 160MB, yet the "bytes=" line
> (which I interpret to mean the amount of memory allocated by the
> application) as around 4.5mb. I don't see too much in the
> blacklisting section that worries me.
The root set size also affects the heap size. But it shouldn't be
by nearly that much.
> This is a gcj 4.2 app on Win32 with some native libraries written in C
> linked as a JNI DLL.
> Also, I just want to confirm something: the GC will never scan for
> pointers in a block of heap memory that it did not allocate itself,
> correct? In other words, if C code invokes the libc malloc(), that
> memory will never be scanned for pointers, correct?
Under win32, that's not 100% correct. Recent versions of the collector
try to make that true, but there doesn't seem to be a really reliable
way to distinguish malloced memory from statically allocated variables.
The GC uses heuristic to exclude most malloc'ed memory. If that's
a problem, GC_malloc_atomic_uncollectable may be a solution.
More information about the Gc