[Top][All Lists]

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

Re: Memory again

From: Stefan Monnier
Subject: Re: Memory again
Date: Tue, 06 Dec 2011 15:25:59 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

>> Still, the point in any case is that if the buffer is 60MB, then killing
>> it will return those 60MB to the kernel, but it won't return to the
>> kernel the memory allocated for Lisp objects such as interval nodes
>> (used for text-properties), cons cells, strings, etc...
> ??? Don't we free interval nodes that point into a buffer that is
> killed?  Why would we need to keep them around?

They should be put on the free list, but whether or not they're returned
to the malloc library depends on whether or not block of those elements
is fully free.  I.e. like with most other Lisp data types.

I think we could fairly easily change the code so that interval objects
are not managed by the GC but my malloc instead.

> Anyway, the theory behind this experiment is that inserting lots of
> text in small chunks causes massive reallocations, one each for every
> time you fill the gap, and this fragmentation of the memory, which
> then makes it impossible to release more than the last 60MB.

I doubt that's what happens.  I think instead that the extra memory is
what is used by the various text properties we add.  It is true that
Emacs makes request from malloc in "10KB" chunks for Lisp data, so any
malloc fragment smaller than that can only be used for things like
vectors I guess, but it doesn't seem sufficient to explain the effect
we're seeing.


reply via email to

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