[Gc] RAM enough but out of virtual memory?

Hans Boehm 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 :-) .


Hans

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
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>


More information about the Gc mailing list