Sorry about comment #32. I was trying to correct a spelling error in #31 but there doesn't appear to be an easy way to do that.

Eric, regarding Firefox memory usage, I can kind of explain that problem.  I believe that Firefox does have garbage collection for Java and perhaps Javascript.  However everything else, the image management, the TCP/IP management, the window and tab management, etc. seem to all be written in C++ and C.  So those will normally go through the C++: new()/delete() functions, or C: malloc()/free() functions.  These all end up on normal Linux systems using the "standard" GNU glibc memory management functions which in turn rely upon the standard Linux(UNIX) sbrk() and brk() system calls.

The Glibc memory management function system *is* robust (I think it is 90+ pages of code).  The problem is that it was not designed to handle situations of "run-for-days" allocating and deallocating many small memory fragments.  Once you allocate such memory (in C++ or C) its location has to remain fixed in the virtual memory address space.  Over time that means that the heap memory becomes increasingly fragmented (lots of little small holes) and total memory usage tends to creep up.  This isn't the same as a "memory leak" where you are losing track of the memory.  The glibc memory management system *knows* where all the small fragments are -- the problem is it can't relocate the in use fragments (defragment the heap) to turn all of the unused small fragments into a single large free fragment (preferably at the end of the virtual address space) which could then be returned to Linux (and shrink your VM memory requirements).  In contrast, I believe Java, and perhaps Javascript, are sufficiently object oriented that you can relocate objects and perform garbage collection thus preventing the problem of excessive memory fragmentation in their heaps.

In practice, if you watch what Firefox is doing on the System Monitor you may sometimes see VM shrink if you open a window, open lots of tabs in it and then close that window, particularly if you have opened all of those tabs sometime previously.  But if they are "new" URLs, then those records may get added to your history list (which may be at the end of Virtual Memory).  In this case you can delete the window and the memory will be returned to glibc pool but because the history records are locking up the end of the glibc pool, glibc will not return the  memory to Linux.  In practice you only see VM shrink at the very end of an normal "Quit" request when Firefox has closed all of the windows, closed the bookmarks file, closed the history file, closed all TCP/IP handles, i.e. freed up *all* of the memory in the glibc memory pool.  Only when all of the memory in the heap is completely free will the glibc memory allocator reunite it all as one big hunk of free memory and return it all to Linux (in practice this is done by issuing a brk() system call to lower the last physical address of the process heap).

The "right" way to make this problem better is to put (a) the history records; (b) the Bookmarks file; and (c) image files into separately managed heaps away from the glibc functions (so glibc is primarily handling smaller short term data storage requirements associated with the creation of tabs, windows, data being loaded into them, etc.).  I've seen messages indicating that at least some of the Firefox core developers seem to be aware of this (they may need to use the mmap() function under Linux to get separate heaps) but they generally consider that this is either hard (cough) or not worth doing (because its only a problem under Linux???) and doesn't make any difference when users should be upgrading their machines to support more memory anyway... :-( If you google my name + Firefox + memory + heap you can probably find multiple rants by me on this topic on /. and other BBS systems.

It might be possible to adjust the glibc() memory manager to better handle the behavior of Firefox (the code does have ways its behavior can be tuned) but I've never seen any messages about anyone attempting to do this.  If someone wants to play with it... you want to look at .../glibc/glibc-2.#/malloc/ (malloc.c, mtrace.c & arena.c).  You may be able to determine how your system is compiled with something along the lines of "strings /lib/libc.so.6 | egrep "MALLOC_|MMAP_").  Googling might turn up a tutorial or two on how to change the environment variables.

(All opinions are obviously my own...)

(Also, if we are going to start a discussion on Firefox memory allocation I'm sure there are other bugs better qualified for discussion of *that* problem.)