[Gc] [Fwd: [Mono-dev] [PATCH] Cause libgc to return some unusedmemory to the system]

Boehm, Hans hans.boehm at hp.com
Tue Sep 8 14:58:19 PDT 2009


> From: Ivan Maidanski
> Sent: Tuesday, September 08, 2009 12:58 PM
> 
> Hi!
> 
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > ...
> > I think it's simpler to do what the collector should 
> already do:  Remap the "unmapped" pages with no permission, 
> so that that the kernel can replace them with zero-filled 
> pages, and they no longer need actual physical memory or disk 
> space.  This means we can remap the blocks when they're 
> needed again.  And we don't have to worry about the kernel 
> mapping a new heap section or a newly loaded dynamic library 
> into a hole in the middle of an old heap section.  There are 
> no doubt other design options, but I'm not sure they really 
> improve matters.
> 
> BTW. My old Q: Should we add check for out-of-memory (in 
> GC_remap) when we try to remap the blocks when they're needed again?
> 
I'm not sure we usefully can on the Posix side.  The memory probably isn't really going to be used until the newly unprotected pages are written.  Thus we would probably end up seeing a SIGSEGV unless we actually touched newly allocated memory in GC_remap.  But we don't currently do that for newly allocated memory.  And doing so would have negative performance implications, since we would force allocation of pages that might otherwise never be needed.

According to Florian's earlier message, things even seem to be unclear in overcommit_memory=2 mode.

On the Windows side, it might make more sense to try to recover.  That would require some work in allchblk.c to deal with GC_remap failures.

Hans


More information about the Gc mailing list