[bmalloc] Merging of XLargeRanges can leak the upper range
authorggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 3 Aug 2016 18:43:15 +0000 (18:43 +0000)
committerggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 3 Aug 2016 18:43:15 +0000 (18:43 +0000)
commit62b29fda068b90fefebabf9101e35d2e3fec49ef
treef3270a47c77ab4c7ff46a46adb8c3305554bc8c8
parent3612c33110f5e92fde9f92f4bfcd7a2e4a68636f
[bmalloc] Merging of XLargeRanges can leak the upper range
https://bugs.webkit.org/show_bug.cgi?id=160403

Reviewed by Michael Saboff.

* bmalloc/Heap.cpp:
(bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
Recorded physical size is a performance optimization. It is not the
truth. So it might be zero even if a range contains physical pages.

Instead, iterate each range in the map unconditionally.

The map can shrink when we release the lock, so we must clamp our
iterator each time through the loop.

The map can grow when we release the lock, but we don't care because
growth restarts the scavenger from the beginning.

* bmalloc/XLargeMap.cpp:
(bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.

* bmalloc/XLargeMap.h:
(bmalloc::XLargeMap::ranges): Added direct access for the sake of
scavengeLargeObjects. (This violates our naming conventions -- I'll do
a rename in a follow-up patch.)

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@204091 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/bmalloc/ChangeLog
Source/bmalloc/bmalloc/Heap.cpp
Source/bmalloc/bmalloc/XLargeMap.cpp
Source/bmalloc/bmalloc/XLargeMap.h