[Gc] RAM enough but out of virtual memory?
Hans.Boehm at hp.com
Tue Jul 19 22:04:37 PDT 2005
Presumably this was a double precision floating point array?
I expect it's the low order 32 bits that are causing the problem,
since they are essentially random bit patterns.
Another solution is to move to 64-bit hardware :-) .
On Tue, 19 Jul 2005, Zhang Le wrote:
> On 7/18/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> > You are running out of virtual address space. Most of the
> > allocated memory is never touched. Thus the amount of
> > physical memory is largely irrelevant. You could probably
> > get things to run slightly longer by using -DUSE_MMAP, which
> > might give you another 2GB of address space. But that's not
> > the real problem here.
> > If you see lines like
> > Section 22 from 0xad4f000 to 0xb54f000 1520/2048 blacklisted
> > Section 23 from 0xb59f000 to 0xbd9f000 1554/2048 blacklisted
> > Section 24 from 0xbdef000 to 0xc5ef000 1568/2048 blacklisted
> > in the GC_DUMP_REGULARLY log, that means that more than 3/4
> > of newly allocated memory was unusable because the collector
> > found "pointers" to it before it was allocated, i.e. there
> > are known false references into it. These numbers are
> > MUCH higher than normal.
> My program does allocate many large chunks of array for float point
> computing using GC_MALLOC. Since I'm new to GC, I planed to first get
> GC_MALLOC work (assume it's safer), then move to the *more advanced*
> GC_MALLOC_ATOMIC. Unfortunately I'm wrong here:-(
> After switching to GC_MALLOC_ATOMIC for large array, I observed the
> vram is almost equal to res-ram, and my program can finish in a
> reasonable time without crash. No more problem.
> Many thanks for this hint and your help!
> Zhang Le
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc