Ingo Weinhold 40cd019ea0 * Renamed VMAddressSpace::ResizeArea{Head,Tail}() to ShrinkArea{Head,Tail}()
to clarify that they never enlarge the area.
* Reimplemented VMKernelAddressSpace. It is somewhat inspired by Bonwick's
  vmem resource allocator (though we have different requirements):
  - We consider the complete address space to be divided into contiguous
    ranges of type free, reserved, or area, each range being represented by
    a VMKernelAddressRange object.
  - The range objects are managed in an AVL tree and a doubly linked list
    (the latter only for faster iteration) sorted by address. This provides
    O(log(n)) lookup, insertion and removal.
  - For each power of two size we maintain a list of free ranges of at least
    that size. Thus for the most common case of B_ANY*_ADDRESS area
    allocation, we find a free range in constant time (the rest of the
    processing being O(log(n))) with a rather good fit. This should also
    help avoiding address space fragmentation.
  While the new implementation should be faster, particularly with an
  increasing number of areas, I couldn't measure any difference in the -j2
  haiku build. From a cursory test the -j8 build hasn't tangibly benefitted
  either.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34528 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-12-06 17:18:04 +00:00
..
2009-11-27 21:10:08 +00:00
2009-11-16 01:07:40 +00:00