[gclist] Running out of memory with GC_malloc

[Boehm, Hans]

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.

Hans

-----Original Message-----
From: Fergus Henderson [mailto:fjh@cs.mu.oz.au]
Sent: Saturday, April 29, 2000 9:21 PM
To: John Palmieri
Cc: gclist@iecc.com
Subject: Re: [gclist] Running out of memory with GC_malloc


On 29-Apr-2000, John Palmieri <johnp@martianrock.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:
> 
> GC_expand_hp(1024*1024*5);
> 
> 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
GC_malloc().

(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 <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.