Re: [Gc] Patch for MAX_HEAP_SECTS value
ivmai at mail.ru
Mon Sep 14 23:41:27 PDT 2009
"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.
> > 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?).
PS. Another Q: Why do we add 1 (to bytes) for VirtualAlloc() in GC_win32_get_mem?
More information about the Gc