|
From: Philippe W. <phi...@sk...> - 2011-11-01 21:32:14
|
3 improvements were done in commit r12202 (see bug 250065), and I am not fully satisfied of the behaviour of the 1st improvement. So, ideas to improve this are welcome. The first improvement consists in having big blocks released in priority. After some time, an application doing a mix of small blocks and big blocks malloc/free might end up with the free list volume almost fully used by the small blocks : the "free list for big blocks to release in priority" will only contain the big blocks very recently free-d but only till there is a new malloc : a new malloc will trigger the cleanup and release first the big blocks. It looks like an "non-absolute priority" for releasing big blocks would be better than the current "release big blocks in absolute priority first". I thought to some approaches to improve this. One easy solution I implemented is to have a "speed" factor in releasing big blocks: each time a big block is put in the free list, small blocks corresponding to a certain percentage of the big block size are queued to be released before this big block. I am wondering if a solution which somewhat better guarantees that recent freed big blocks are not directly released would not be better. I was thinking to something like the below (not implemented) : ensure the last N big blocks freed (up to a maximum of X % of the free list volume) are released after the small blocks that were freed before. A third solution (also not implemented) would be to "shrink" the big freed blocks : when cleaning up a big block (i.e. removing it from the free list), the big block would be splitted in two: a small part (e.g. the first 8Kb) would be queued to be released with the small blocks. the remaining part would be physically cleaned up. (this is based on the assumption that a dangling pointer will most of the time be de-referenced at the beginning of the block). Any thought/feedback/other ideas about the above ? Thanks |