<br><div><span class="gmail_quote">On 5/3/06, <b class="gmail_sendername">Samantha Atkins</b> <<a href="mailto:sjatkins@mac.com">sjatkins@mac.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Allocate large blocks using the underlying system/libc calls.  Write alloc, free, etc. substitutes and any more specialized calls you might desire  that<br>suballocate from these large blocks with sufficient additional bookkeeping, tagging and such to more efficiently clean up garbage and compact the heap.   This sort of thing has been written many times.  Its main drawback is the larger memory increment when the current large blocks cannot satisfy a request.   But with compacting of the heap large blocks themselves may be released if memory needs go down significantly enough.
</blockquote><div><br>I understand that Samantha.<br><br>It is a somewhat non-trivial problem because each type of memory (say history records vs. large images vs. garbage collected memory [Javascript???]) requires different memory management strategies.  There seems to be 32+ types of *alloc() calls (png_malloc(), GC_malloc(), JS_malloc(), etc.) in the source for Mozilla. I'm not sure what subset is used by Firefox.  What I am seeing suggests that they knew this would be useful but may not have yet taken steps to optimize it.
<br></div><br>Robert<br><br></div><br>