Re[2]: [Gc]: unresolved problems

Ivan Maidanski ivmai at
Sat Sep 26 14:57:49 PDT 2009


Hans Boehm <Hans.Boehm at> wrote:
> On Sat, 26 Sep 2009, Ivan Maidanski wrote:
> > Hi!
> >
> > Hans -
> >
> > Could you resolve somehow the following problems: 1.
> >
> > ("MAX_HEAP_SECTS value" - I dropped the patch but how could the initial
> > problem be solved?)
> I think the right solution is to introduce another macro, say
> MAX_HEAP_MAPPINGS, set that to a larger value, and use it as the size of
> arrays that also include GC_scratch_alloc mappings or the like, like
> GC_heap_bases.  I'm concerned about a blanket increase of MAX_HEAP_SECTS,
> since it looks to me like that enlarges some of the arrays more than
> necessary on platforms like Linux.  And we currently size different arrays
> identically, even though one really needs to be much larger than the other.

This seems to be for the next release... May be, we should just double MAX_HEAP_SECTS for SMALL_CONFIG for now (may be on Win32/CE only)?

> >
> > 2.
> >
> > ("Unexpected heap growth").
> I'm a bit concerned that this really reflects a root scanning problem, and
> the collector on Windows CE may be scanning parts of the heap as though it
> were part of the root set.

Yes, someone observed it on WinCE, but I observe it on Win32 (as said in the referred post). I tried it again and got FAIL on 5th test.exe run. I tried to replace 12000000 (in check_heap_stats) to 13000000 or even to 14000000, but still fail sometimes.

Test compiled by MinGW: gcc -DALL_INTERIOR_POINTERS -DGC_THREADS -DTHREAD_LOCAL_ALLOC -DPARALLEL_MARK -Iinclude -Ilibatomic_ops-1.2\src tests\test.c *.c

> If, on close inspection, I'm wrong, then yes, we should increase the
> numbers.


More information about the Gc mailing list