[Gc] GC_allochblk_nth bug

Roger Osborn roger.osborn at linguamatics.com
Mon Mar 3 03:41:31 PST 2008

Bruce Hoult wrote:
> On Mon, Mar 3, 2008 at 2:19 PM, Romano Tenca <rotenca at gmail.com> wrote:
>> I have a segmentation fault if i add these lines to gctest soon after
>>  GC_INIT()
>>      GC_expand_hp(1024*1024*5);
>>      void *r = GC_MALLOC(2147483647-1024);
> Does anyone else think it's just fundamentally a bad idea to use such
> a large portion of the address space for a conservative garbage
> collector's heap?
> _______________________________________________

We have a program that's grown into being in that position on Windows.   
It does seem to lead to very high page fault rates as you approach the 
point of memory exhaustion, but that's probably inevitable given our 
pattern of allocations. I think the GC FAQ documentation mentions 
somewhere that it behaves acceptably in this area for some applications, 
and not others. So far we've considered the convenience makes it worth 
having, and we do try and assist by using GC_MALLOC_ATOMIC where 

In fact GC doesn't get the whole address space in our case, because some 
of our code uses GC and some the traditional Windows memory management 
(especially that code which is in third party libraries). We have found 
(by dumping Windows heaps) that GC often can't get a large chunk (up to 
400-500Mb) of the address space because one of the heaps has reserved 
(but not committed) that region of the address space already. This can 
lead to the program giving up prematurely because the "wrong" memory 
manager has the remaining space.  Wonder if anyone here has worked round 
that problem, e.g. by finding away of letting GC manage everything?  
I've done that sort of plumbing in Debug build mode using 
_CrtSetAllocHook in the past, but don't know if it's even possible in 
Release mode.



More information about the Gc mailing list