[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: Joe Marshall
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: Thu, 6 Oct 2011 08:15:34 -0700

On Wed, Oct 5, 2011 at 7:50 PM, Taylor R Campbell <address@hidden> wrote:
>   Date: Wed, 5 Oct 2011 17:24:28 -0700
>   From: Joe Marshall <address@hidden>
>   as you can see, it makes a big difference at the larger heap sizes.
> Contrariwise, if I have six Scheme processes that have not freed their
> unused pages and the OS is constantly swapping, then the whole world
> gets much, much slower, especially at larger heap sizes.  That's why I
> put it in there in the first place.

In theory, yes, but not in practice.  Go ahead and measure it.

>                      (it is linear in the number of pages and I suspect
>   that the implementation provides guarantees of zeroing out the physical
>   pages).
> It's not supposed to guarantee zeroing.  Maybe I misunderstood Linux's
> MADV_DONTNEED -- which would not be surprising, because on Linux it is
> a destructive operation whereas everywhere else it is non-destructive
> (and not useful for this purpose).

It was only a suspicion, but whatever is causing linear effect is quite real.
There is the obvious linearity involving iterating over the freed pages.
I was guessing that that effect was negligible and that something
more substantial was going on.

I've included a graph comparing the total GC time for Scheme
compiling itself under varying sizes of heap.  One line shows
the cost before my change and the other one shows after.


Attachment: t.png
Description: PNG image

reply via email to

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