This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GC and continuations



> > > But the fact stays the same --- when guile accumulates for example 40M, it
> > > stays that big forever (I supose; that was my question).
> 
> That is correct, try the same thing with emacs, once you have loaded in
> a 40M file and then closed the buffer emacs is big until you shut it down
> and start again (usually that won't be long because the bigger it is the
> slower it runs, depending on local hardware capabilities).

(Today is my day for picking on Telford...)

That's not true.

Start an Emacs:

    $ emacs &
    [2] 14962

Before visiting any files, check its size:

    $ ps ux 14962
    USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
    jimb     14962 19.7  7.5  6176  4784  p0 S    11:51   0:02 emacs 

Now visit /usr/bin/perl, or something big.  The size goes up:

    $ ps ux 14962
    USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
    jimb     14962  7.8  8.4  6724  5316  p0 S    11:51   0:03 emacs 

Now delete that buffer.  The size goes down, albiet not all the way:

    $ ps ux 14962
    USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
    jimb     14962  6.7  7.7  6268  4912  p0 S    11:51   0:03 emacs 
    $ 

This is because Emacs goes to a great deal of effort to not only
return storage to itself, via free, but to return storage to the
kernel, via sbrk.  Space for buffers isn't allocated with malloc; it's
allocated using a special allocator that allocates from a separate
arena.  When a buffer is deleted, this allocator actually compacts the
buffer arena, shifting all the other buffers down in memory, so that
all the free space is at the end, and then calls sbrk with a negative
argument to give the memory back to the kernel to allocate to other
processes.

At least, that's the way it used to work.  They may have refined it
since then, but clearly, it does still give memory back.

You'd think this was really cool, but given the way the two heaps
interact, it actually means that calls to malloc can result in buffers
being moved.  Which means you can't pass pointers to buffer text
directly to any external library routine (like regexp, Xlib, etc.)
because you can't be sure they won't call malloc and have the buffer
shifted out from under them while they're trying to tweak it.  Oops.

But: enough reminiscence.  I'm pretty sure Guile just uses malloc and
free; if they never return memory to the kernel, then Guile won't.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]