Anand Palaniswamy writes:
> [EMAIL PROTECTED] (Joseph H. Buehler) writes:
>
> > [EMAIL PROTECTED] (Anand Palaniswamy) writes:
> >
> > > Another bad side effect of this limitation is that the famous "return
> > > memory to OS" bug can not be implemented on Linux (ie, there is no
> > > heap "shrinking").
> >
> > Are you sure about that? I use GNU emacs a lot and just tried an
> > experiment on a machine running RedHat because I have observed address
> > space shrinking on other UNIX's. Sure enough, the "ps" command under
> > RedHat reports that the emacs process size increases when it reads a
> > big file, but decreases back to what it was when I kill the buffer. I
> > don't mean the resident size, either, but the overall process address
> > space size.
>
> It is possible to unmap memory and return it to the OS on Linux. I am
> sure Emacs does that. The classic VM garbage collector can not do
> that. It wants to keep the memory mapped (so it can always be sure
> that the heap is contiguous -- unmmapping might lead to someone else
> stealing the part you just unmapped). The trick classic VM uses on
> Solaris and on Windows is to keep the heap mapped but not have any
> swap committed to it (which is slightly different from completely
> unmapping it).
>
> Emacs can probably deal with discontiguous heaps. (Infact I wouldn't
> be surprised if there is a special heap for large files).
Of course, you *could* think about always having contiguous heaps with
a momentary hiccup when you allocate a new larger area and then unmap the
previous pages after you've blitted things over. COW ZFOD pages may help; it's
something we should check out more thorougly.
Steve
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]