W3C home > Mailing lists > Public > html-tidy@w3.org > April to June 2001

RE: SourceForge Project Approved

From: Richard A. O'Keefe <ok@atlas.otago.ac.nz>
Date: Wed, 30 May 2001 11:33:01 +1200 (NZST)
Message-Id: <200105292333.LAA468034@atlas.otago.ac.nz>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 April 2012 06:13:45 GMT