[Gc] [Fwd: [Mono-dev] [PATCH] Cause libgc to return some unused
memory to the system]
hans.boehm at hp.com
Tue Sep 8 11:45:18 PDT 2009
If I understand this patch corectly, then it behaves as follows:
- When it is decided to "really unmap" a page, the pages is revmoved from the GC data structures, as though that section of memory no longer exists.
- However the memory remains part of GC_heap_sects, the list of all heap segments.
When the memory is remapped, it will be added again as a new heap section, causing GC_heap_sects to contain overlapping sections.
At a minimum, I think this will eventually cause the collector to fail as it allocates too many distinct heap sections. I also suspect that some of the debugging code will fail when it's turned on, since pieces of the heap will appear to be missing.
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.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Dick Porter
> Sent: Monday, September 07, 2009 3:51 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] [Fwd: [Mono-dev] [PATCH] Cause libgc to return
> some unused memory to the system]
> Hi all
> I developed a patch to libgc so that when USE_MUNMAP is
> defined, then memory really is freed back to the system.
> This was developed against the version in mono's svn, but
> should be easily applied to the upstream sources.
> The only response I had from the mono-devel list was to ask
> why the libgc upstream developers hadn't already done this.
> Is there a good reason I'm missing why the libgc free list
> isn't actually freed, just remapped with no permissions? My
> patch only frees chunks larger than
> 4096 bytes to try and avoid fragmentation; other than that I
> can't think of anything obvious.
> I've attached the mail I sent to mono-devel, which includes
> the small patch.
> - Dick Porter
More information about the Gc