[Patch] mt_allocator: spare mem & fix alignment problems

Dhruv Matani dhruvbird@gmx.net
Fri Mar 26 12:08:00 GMT 2004


On Fri, 2004-03-26 at 17:04, Paolo Carlini wrote:
> Stefan Olsson wrote:
> 
> > This has been on my todolist as well. Nice work Paolo!
> 
> Thanks Stefan.
> 
> Overall, I like the project that you started and is a joy contributing
> a bit to it.
> 
> Currently, the biggest problem is memory usage: in my test is some 2
> times that of pool_allocator, in some (not-totally-pathological) cases
> even 10 (!) times: container_benchmark.cc and insert.cc (for list, in
> particular) are two good examples, respectively.
> 
> In my opinion, we need to fix that before proposing it for prime time.

I have mentioned the flaw about the per-type pool. That would contribute
to reducing the total memory usage in real-apps. However, in these
test-cases, it is instantiated for but one single type, so it wouldn't
make any difference.

Also, something like reusing memory from another larger bin could have
been one option except for the fact that:

1. The nodes are not address sorted.
2. Consider even say a node of 128-bytes, which is actually
(128+4)-bytes. If and when we want to splice it into 2 nodes of size
64-bytes, it can not be done, because the total requirement would be
64+4+64+4 bytes.

> 
> Any idea is *much* appreciated!

Even I had thought about this issue and even brought it up, but failed
to get any idea, because the thing is that the allocator does not manage
the nodes together. ie: Nodes from each allocated page together or
something like that, so it becomes next to impossible to ever give the
memory back to the OS. Thus, we even find it difficult to find nodes
close to each other.



Another couple of issues that are pending would be:

1. The use of the div instruction on every call of deallocate to
calculate the nodes to be removed. This is quite a high latency
instruction, but I don't know how much the performance is affected.

2. The algorithm for giving back nodes to the global pool. Instead of
clipping out one node at a time, why not splice out a whole bunch of
nodes, and put them all in at one shot? Just a thought. I can prepare a
patch for this one if needed.


-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html



More information about the Libstdc++ mailing list