[Gc] Patch for MAX_HEAP_SECTS value

Boehm, Hans hans.boehm at hp.com
Fri Sep 18 20:56:09 PDT 2009


 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Monday, September 14, 2009 11:41 PM
> To: gc at napali.hpl.hp.com
> Subject: Re[3]: [Gc] Patch for MAX_HEAP_SECTS value
> 
> Hi!
> 
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > The patch looks fine.  But I don't think I fully understand 
> why it's needed, making me a bit concerned that something 
> else is wrong.
> >
> > What are the sizes of the heap sections when the old value 
> is too small?  The 256MB estimate for the old value may be 
> too high, but I don't immediately see why it should be too 
> high by that much.  Heap section sizes should initially grow 
> exponentially until they hit the maximum size, which should 
> happen after a relatively small number of expansions.  A few 
> old mark stacks are also likely to get added to the heap.  
> But I'd still be surprised if we had more than about 50 heap 
> segments that were smaller than the maximum size.
> >
> > Hans
> >
> > > The value hard-coded for MAX_HEAP_SECTS in case of 
> SMALL_CONFIG is 
> > > too small (the heap limit could be reached at
> > > 2 MiB) to pass test.c in some configurations (the heap size is 
> > > roughly 16 MiB observed), so I've increased 
> MAX_HEAP_SECTS value by 
> > > 2 (for SMALL_CONFIG).
> 
> The problem is in GC_scratch_alloc() which calls GET_MEM(16K) 
> (similar thing happens in backgraph.c). So, a possible 
> solution could be:
> - define GET_MEM_SCRATCH(n) which is same as GET_MEM for all 
> targets except for Win32/WinCE;
> - use GET_MEM_SCRATCH in GC_scratch_alloc() and backgraph.c;
> - define GET_MEM_SCRATCH(bytes) for Win32/WinCE as 
> VirtualAlloc(NULL, bytes, MEM_COMMIT | MEM_RESERVE | 
> GC_mem_top_down, PAGE_READWRITE) (unclear things:
> no GlobalAlloc?, no MEM_WRITE_WATCH needed?, GC_mem_top_down 
> is needed?, should WinCE case be the same as Win32?, no 
> result recording in GC_heap_bases[]?).
This is apparently sort of a Windows CE specific problem with GC_wince_get_mem.  I hadn't appreciated that.  GC_heap_bases is apparently needed for Windows CE also because of large address space reservation granularity, which doesn't apply for win32?  I'm not a Windows CE expert, and I didn't write this code ...

We apparently have similar issues with GC_our_memory, but that's only configured with USE_PROC_FOR_LIBRARIES, which is presumably rare.  Actually, GC_our_memory seems to have an array overflow problem, which I will fix
asap.  I put a patch in my tree.  (I don't think it's easily exploitable as a security hole, even if this path is enabled.)

It seems like the obvious patch here would be to use larger size for GC_our_memory and GC_heap_bases, rather than increasing GC_HEAP_SECTS?

Partial answer to other questions:
GC_mem_top_down used to be essential for 64-bit debugging on win32, so that stores of addresses to ints would actually fail.  I suspect that still applies.
> 
> Opinions?
> 
> PS. Another Q: Why do we add 1 (to bytes) for VirtualAlloc() 
> in GC_win32_get_mem?
It keeps the heap sections discontiguous, which prevents blocks from spanning regions which, based on the comment could result in bad VirtualProtect calls in some configurations.  It may be that this is unnecessary without MPROTECT_VDB.  I'm not sure.

Hans
> 
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list