Nick Kew wrote:
On Mon, 16 Feb 2009 08:06:11 +0100
Mladen Turk <[email protected]> wrote:
One thing I've proposed (but was vetoed) was the actual
malloc/free programmable replacement within the allocator.
Now the thing to consider is to make the allocator public
allowing to implement what ever system memory allocation
there is (eg, heap or virtualmemory on win32, shm, etc)
instead just relying on standard allocator implementation
which (I presume that 8K granulation was more or less
empirically determined) is fixed.
Can you point to that discussion?
Here was the patch
http://svn.apache.org/viewvc?view=rev&revision=647394
Browse the archive for objections ;)
Seems to me that if it
can be done without performance penalties, then making the
allocator into a public API should have potential to be the
solution to make everyone happy.
I'm not saying the the proposed API was perfect.
It only changed the internal allocator malloc/free.
The best thing would be to completely abstract the
allocator so that one can completely implement it's
own allocator.
The existing implementation would then change from:
mem = allocator_alloc(allocator, size)
to
mem = (*allocator->alloc)(allocator, size)
I don't think there will be any performance
penalties using that.
Regards
--
^(TM)
