[gclist] Running out of memory with GC_malloc
Mon, 1 May 2000 09:49:15 -0700
To expand on this slightly:
The default behavior of the collector is to start with a very small heap,
and to expand as necessary. At least if you build with -DLARGE_CONFIG, you
should run out of address space on a 32 bit machine before you run into any
real heap size limitations.
GC_expand_hp is a way to force it to start with a larger heap. If you are
running out of memory, it's not a solution.
From: Fergus Henderson [mailto:firstname.lastname@example.org]
Sent: Saturday, April 29, 2000 9:21 PM
To: John Palmieri
Subject: Re: [gclist] Running out of memory with GC_malloc
On 29-Apr-2000, John Palmieri <email@example.com> wrote:
> I am having a probelm with the BDW garbage collector. I had been
> creating massive amounts of C++ objects causing my heap to grow beyond
> its allocated size. I fixed this by adding the line:
> This worked until I started to load PNG graphic images using GC_malloc.
For large bitmaps, and other objects containing lots of semi-random
bits but no pointers, you should use GC_malloc_atomic() rather than
(If you have objects that contain lots of semi-random data plus a few
pointers, you could also use GC_malloc_explicitly_typed().)
Fergus Henderson <firstname.lastname@example.org> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger email@example.com | -- the last words of T. S. Garp.