[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.
--
~jrm
t.png
Description: PNG image