- From: Richard A. O'Keefe <ok@atlas.otago.ac.nz>
- Date: Wed, 30 May 2001 11:33:01 +1200 (NZST)
- To: Valeri.Atamaniouk@nokia.com, html-tidy@w3.org, ok@atlas.otago.ac.nz
Valeri.Atamaniouk@nokia.com wrote: [recommending the idea of releasing an entire memory zone on an exception]. I replied to the effect that this is no new idea, I've been doing it for years and it's in Knuth's Stanford GraphBase. Valeri.Atamaniouk@nokia.com wrote next: But that means that you deprecate functions like CheckNodeIntegrity -> because if you detected problems with tree you can not release memory. That is a very strange view, and not in accord with the facts. If you have an arena/zone/storage pool mechanism of your own, so that you call the host operating system to grab large chunks (GETMAIN, malloc(), whatever) and then run your own suballocator within it, nothing whatsoever prevents your suballocator having its own myfree(). Actually you don't have to preallocate a big blocks. You may just maintain the list of allocated blocks to release it on demand. Nobody said anything about *pre*allocating before. Big blocks, however, are important. By asking the system allocator for big blocks (much much bigger than "typical" objects) and then running your own special purpose allocator within those blocks, you can obtain substantial time and space savings. You also have the benefit that if you leave a little "shim" at each end, off-by-one errors are less likely to trample on system allocator data. Mind you, techniques that were developed for 1 "MIP" machines may no longer be necessary on 1.4GHz machines. On the other hand, the Tidy library should be usable in phones, so maybe they are.
Received on Tuesday, 29 May 2001 19:33:18 UTC