[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] [commit f372dae] Don't call OS_free_pages after G

From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] [commit f372dae] Don't call OS_free_pages after GC flip. We don't resize the heap and we will be reusing it.
Date: Sat, 8 Oct 2011 19:58:43 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1

   Date: Sat, 8 Oct 2011 12:26:14 -0700
   From: Joe Marshall <address@hidden>

   On Thu, Oct 6, 2011 at 6:47 PM, Taylor R Campbell <address@hidden> wrote:

   > For now, perhaps there should be a command-line option to toggle
   > freeing of pages.

   I like the idea of an option one can set, but maybe it should be a
   primitive instead of a flag?

An option would be more convenient for me, but I don't care much, and
it could easily be both.

As an aside, it might also be worthwhile to allocate all virtual
addresses up to a given maximum address (say, some function of what
getrlimit(RLIMIT_AS) says, or a command-line option), but initialize
heap_alloc_limit to something small, on boot.  Then, after each GC, if
there are n words in use, set heap_alloc_limit to min(heap_max_limit,
k * (Free - heap_start)), where k is some constant ratio or infinity.
If the new heap_alloc_limit is lower than the old one, OS_free_pages
all the pages that are newly beyond heap_alloc_limit.

That way, we don't hog much more physical memory than we need, we get
the old behaviour with k = infinity, and we don't call OS_free_pages
unless the working set has probably shrunk.

But I don't have any Copious Spare Time^TM to implement or test this.
And someone who does would probably have the time to research real
heap expansion and contraction GC policies and show with mathematical
models and experimental heap usage traces that this is a bogus idea.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]