<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I have written storage management and caching systems. There are a small set of truly different types of storage needs across all common types of software applications when you factor the space. It is possible to find a common supporting general memory/cache model with two primary subtypes of storage and a small set of storage/cache management primitives that can be mixed and matched to cover different needs. The storage subsystem can be designed to be adaptive to actual usage patterns. In this way different memory needs can be met at a much higher and more flexible level and with far greater performance and efficiency than attempting to satisfy all these types of needs using clib and equivalents.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>- samantha</DIV><DIV><BR><DIV><DIV>On May 3, 2006, at 2:47 PM, Robert Bradbury wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><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><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">extropy-chat mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:extropy-chat@lists.extropy.org">extropy-chat@lists.extropy.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://lists.extropy.org/mailman/listinfo.cgi/extropy-chat">http://lists.extropy.org/mailman/listinfo.cgi/extropy-chat</A></DIV> </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>