[Gc] Problem with Blacklist
Thu, 30 Oct 2003 14:06:25 -0800
I suspect that too much of the heap is blacklisted. To verify that,
call GC_dump() sometime shortly before the failure. It will generate
lots of output with a 120MB heap. But one piece of that will be a list
of the individual heap sections and some info on how much of each is blacklisted.
Assuming this is the case, various partial solutions are possible to reduce
the number of blacklisted pages:
1) Build the collector with -DLARGE_CONFIG. This probably won't help much, but
it's definitely a good idea for heaps that size.
2) Supply some type/object layout information to the collector, especially
if you are allocating objects containing "random" data, e.g. compressed data.
It's usually easiest to use GC_MALLOC_ATOMIC where appropriate. This is
probably the most important, and may eliminate the problem completely.
3) Allocate large objects with the ...ignore_off_page primitives. Make sure
that you keep pointers to the beginnings of such objects. This will help only
if it's still possible to allocate smaller objects without running into
4) If possible for your application, turn off GC_all_interior_pointers.
5) Check the GC_dump() output to make sure that graphics memory is not traced.
(There are some hooks in 6.3alpha2 to deal with that potential problem if you
run into it.)
5) Switch to a 64-bit machine. (Very effective but not always feasible :-) .)
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]On
> Behalf Of Francois Bronsard
> Sent: Thursday, October 30, 2003 1:01 PM
> To: email@example.com
> Subject: [Gc] Problem with Blacklist
> Hello everyone,
> I have a strange problem with the black list data structure
> within GC. I've
> allocated so far about 120Meg of data (_heapsize is roughly
> 120Meg), but now
> as I'm trying to allocate another 75K, GC gets into a loop in which it
> allocates itself more memory (about 8Meg), then as it tries
> to use it to
> satisfy the allocation request, it checks if that memory is
> blacklisted and
> decide that the whole new block is blacklisted, then it
> repeat the loop
> until the complete virtual memory has been exhausted. Then
> the program
> stops with "no memory available".
> I'm using GC version 6.2, running on a PC with Windows XP
> Pro, compiled with
> Visual Studio C++ version 6.0 with 500+Meg of RAM. I've set
> GC_free_space_divisor is 3.
> Any suggestion to either fix the problem or at least narrow
> it down to find
> the source of the problem?
> Thanks in advance,
> Francois Bronsard
> Gc mailing list