[extropy-chat] Optimal computer configurations [Was: Commentary: Does Karl Schroeder's opinion reallymatter?]

Robert Bradbury robert.bradbury at gmail.com
Mon May 1 23:02:55 UTC 2006


Firefox from my brief research simply seems to be doing C/C++ allocs & frees
of the memory meaning that it is relying on glibc to handle the heap.  I
think the problem is that they just seem to be grabbing more over time
without paying attention to how they manage it (so you've got history table
entries, bookmarks, stored scripts, gmail records (or any other "dynamic"
web information) all interleaved in the heap.  So even if you free up all of
the big image allocations in the heap the glibc routines still aren't going
to give that space back to the O.S. (in Unix/Linux you have to issue a brk()
call to decrease the last physical data address of the process).  The
library has code in it to do that (I checked) but I doubt it is ever called
because you never completely "free" the space at the high end of the heap.
So the heap gets paged which means over time performance goes through the
floor as more paging has to be done to scan the heap every time you allocate
or deallocate from the heap or run a garbage collection on it.

One time after I'd run Firefox up to about 250-300MB of resident working set
(probably 150+ tabs) I told it to simply "Quit" -- it did exit cleanly after
*25* minutes on a machine that was doing nothing else of significance.  I
watched the performance on vmstat over that period and it was almost all
swap-ins of unchanged heap pages during that time as it attempted to merge
all of the pieces of heap memory being freed into one large chunk before
exiting.  It used virtually no CPU during this period -- it was all page
faults and waiting for the pages to be swapped in.  Its a combination of
poor memory management in Firefox with poor VM management in Linux.  (One
needs a VM system which is intelligent enough to recognize heap thrashing
and try to manage it reasonably -- which isn't trivial.)

I could be wrong but I think Firefox is only single threaded in the
communications area, not in the page format & display area.  You shouldn't
*have* "processor-intensive tabs" -- thats an indication of "foreign" code
being run on your machine and I would suggest people are taking very large
risks if they allow sites to do that on a general basis (which is why I
generally block Javascript).

Robert

On 5/1/06, Alfio Puglisi <alfio.puglisi at gmail.com> wrote:
>
> On 5/1/06, Samantha Atkins <sjatkins at mac.com> wrote:
> >
> > Ah.  Does Firefox have its on memory management internally or does it
> > just depend on raw request to the platform alloc routines that it
> > then chains together.  From the description i would guess the
> > latter.
>
> The latter, and AFAIK it doesn't free the memory used by the images in
> a tab when you close it, so the memory usage grows and grows. It's
> also single-threaded, and a processor-intensive tab can effectively
> hang the others for quite a while.
>
> Alfio
>
> _______________________________________________
> extropy-chat mailing list
> extropy-chat at lists.extropy.org
> http://lists.extropy.org/mailman/listinfo.cgi/extropy-chat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.extropy.org/pipermail/extropy-chat/attachments/20060501/5b2a8b52/attachment.html>


More information about the extropy-chat mailing list