Re: [Gc]: unresolved problems
ivmai at mail.ru
Sat Sep 26 14:57:49 PDT 2009
Hans Boehm <Hans.Boehm at hp.com> wrote:
> On Sat, 26 Sep 2009, Ivan Maidanski wrote:
> > Hi!
> > Hans -
> > Could you resolve somehow the following problems: 1.
> > https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3241
> > ("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.
> > https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3169
> > ("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
More information about the Gc