Ove Kaaven ovehk@ping.uio.no writes:
Not that much. Wine's allocator already implements the *features* of that allocator (boundary tags, bins), it just doesn't implement all the *strategies* used for selecting which free block to allocate memory from (though the only big things we lack there is "best fit" and "wilderness preservation", the latter of which Alexandre talked about).
Well, we do have (almost) best fit, that's the only reason for having multiple free lists. It's just that we probably need more bins sizes to make it really useful.
We just need to make sure Wine's free block selection routine uses the same strategies as this allocator, and we'd get exactly the same performance as that allocator, but without replacing the whole thing and sacrificing the compatibility we have or introducing new bugs.
Well, this depends how easy it is to plug the new allocator in; but if it doesn't require too many changes, it will certainly introduce less bugs than trying to tweak the existing code. Plus all the profiling work has been done already, which would have to be done on the Wine code.