bmalloc: Renamed LargeChunk => Chunk
[WebKit-https.git] / Source / bmalloc / ChangeLog
index b071244..401f45d 100644 (file)
+2016-03-25  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Renamed LargeChunk => Chunk
+        https://bugs.webkit.org/show_bug.cgi?id=155894
+
+        Reviewed by Michael Saboff.
+
+        A Chunk can contain both small and large objects now.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocate):
+        * bmalloc/BoundaryTag.h:
+        (bmalloc::BoundaryTag::isFree):
+        * bmalloc/Chunk.h: Copied from Source/bmalloc/bmalloc/LargeChunk.h.
+        (bmalloc::Chunk::pages):
+        (bmalloc::Chunk::begin):
+        (bmalloc::Chunk::end):
+        (bmalloc::Chunk::Chunk):
+        (bmalloc::Chunk::get):
+        (bmalloc::Chunk::beginTag):
+        (bmalloc::Chunk::endTag):
+        (bmalloc::Chunk::offset):
+        (bmalloc::Chunk::object):
+        (bmalloc::Chunk::page):
+        (bmalloc::Chunk::line):
+        (bmalloc::SmallLine::begin):
+        (bmalloc::SmallPage::begin):
+        (bmalloc::SmallPage::end):
+        (bmalloc::Object::Object):
+        (bmalloc::Object::begin):
+        (bmalloc::LargeChunk::pages): Deleted.
+        (bmalloc::LargeChunk::begin): Deleted.
+        (bmalloc::LargeChunk::end): Deleted.
+        (bmalloc::LargeChunk::LargeChunk): Deleted.
+        (bmalloc::LargeChunk::get): Deleted.
+        (bmalloc::LargeChunk::beginTag): Deleted.
+        (bmalloc::LargeChunk::endTag): Deleted.
+        (bmalloc::LargeChunk::offset): Deleted.
+        (bmalloc::LargeChunk::object): Deleted.
+        (bmalloc::LargeChunk::page): Deleted.
+        (bmalloc::LargeChunk::line): Deleted.
+        * bmalloc/Deallocator.cpp:
+        * bmalloc/FreeList.cpp:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateLarge):
+        * bmalloc/LargeChunk.h: Removed.
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::LargeObject):
+        (bmalloc::LargeObject::merge):
+        (bmalloc::LargeObject::split):
+        * bmalloc/Object.h:
+        (bmalloc::Object::chunk):
+        * bmalloc/ObjectType.cpp:
+        * bmalloc/Sizes.h:
+        * bmalloc/SmallAllocator.h: Removed.
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::VMHeap):
+        (bmalloc::VMHeap::allocateChunk):
+        (bmalloc::VMHeap::allocateLargeChunk): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateLargeObject):
+        (bmalloc::VMHeap::deallocateLargeObject):
+        * bmalloc/Zone.cpp:
+        (bmalloc::enumerator):
+        * bmalloc/Zone.h:
+        (bmalloc::Zone::chunks):
+        (bmalloc::Zone::addChunk):
+        (bmalloc::Zone::largeChunks): Deleted.
+        (bmalloc::Zone::addLargeChunk): Deleted.
+
+2016-03-24  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: small and large objects should share memory
+        https://bugs.webkit.org/show_bug.cgi?id=155866
+
+        Reviewed by Andreas Kling.
+
+        This patch cuts our VM footprint in half. (VM footprint usually doesn't
+        matter, but on iOS there's an artificial VM limit around 700MB, and if
+        you hit it you jetsam / crash.)
+
+        It's also a step toward honoring the hardware page size at runtime,
+        which will reduce memory usage on iOS.
+
+        This patch is a small improvement in peak memory usage because it allows
+        small and large objects to recycle each other's memory. The tradeoff is
+        that we require more metadata, which causes more memory usage after
+        shrinking down from peak memory usage. In the end, we have some memory
+        wins and some losses, and a small win in the mean on our standard memory
+        benchmarks.
+
+        * bmalloc.xcodeproj/project.pbxproj: Removed SuperChunk.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Adopt a new Heap API for shrinking
+        large objects because it's a little more complicated than it used to be.
+
+        Don't check for equality in the XLarge case because we don't do it in
+        other cases, and it's unlikely that we'll be called for no reason.
+
+        * bmalloc/BumpAllocator.h:
+        (bmalloc::BumpAllocator::allocate): Don't ASSERT isSmall because that's
+        an old concept from when small and large objects were in distinct memory
+        regions.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::deallocateSlowCase): Large objects are not
+        segregated anymore.
+
+        (bmalloc::Deallocator::deallocateLarge): Deleted.
+
+        * bmalloc/Deallocator.h:
+        (bmalloc::Deallocator::deallocateFastCase): Don't ASSERT isSmall(). See
+        above.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::scavengeSmallPage):
+        (bmalloc::Heap::scavengeSmallPages): New helpers for returning cached
+        small pages to the large object heap.
+
+        (bmalloc::Heap::allocateSmallPage): Allocate small pages from the large
+        object heap. This is how we accomplish sharing.
+
+        (bmalloc::Heap::deallocateSmallLine): Handle large objects since we can
+        encounter them on this code path now.
+
+        (bmalloc::Heap::splitAndAllocate): Fixed a bug where we would sometimes
+        not split even though we could.
+
+        Allocating a large object also requires ref'ing its small line so that
+        we can alias memory between small and large objects.
+
+        (bmalloc::Heap::allocateLarge): Return cached small pages before
+        allocating a large object that would fit in a cached small page. This
+        allows some large allocations to reuse small object memory.
+
+        (bmalloc::Heap::shrinkLarge): New helper.
+
+        (bmalloc::Heap::deallocateLarge): Deleted.
+
+        * bmalloc/Heap.h:
+
+        * bmalloc/LargeChunk.h:
+        (bmalloc::LargeChunk::pageBegin):
+        (bmalloc::LargeChunk::pageEnd):
+        (bmalloc::LargeChunk::lines):
+        (bmalloc::LargeChunk::pages):
+        (bmalloc::LargeChunk::begin):
+        (bmalloc::LargeChunk::end):
+        (bmalloc::LargeChunk::LargeChunk):
+        (bmalloc::LargeChunk::get):
+        (bmalloc::LargeChunk::endTag):
+        (bmalloc::LargeChunk::offset):
+        (bmalloc::LargeChunk::object):
+        (bmalloc::LargeChunk::page):
+        (bmalloc::LargeChunk::line):
+        (bmalloc::SmallLine::begin):
+        (bmalloc::SmallLine::end):
+        (bmalloc::SmallPage::begin):
+        (bmalloc::SmallPage::end):
+        (bmalloc::Object::Object):
+        (bmalloc::Object::begin):
+        (bmalloc::Object::pageBegin):
+        (bmalloc::Object::line):
+        (bmalloc::Object::page): I merged all the SmallChunk metadata and code
+        into LargeChunk. Now we use a single class to track both small and large
+        metadata, so we can share memory between small and large objects.
+
+        I'm going to rename this class to Chunk in a follow-up patch.
+
+        * bmalloc/Object.h:
+        (bmalloc::Object::chunk): Updated for LargeChunk transition.
+
+        * bmalloc/ObjectType.cpp:
+        (bmalloc::objectType):
+        * bmalloc/ObjectType.h:
+        (bmalloc::isXLarge):
+        (bmalloc::isSmall): Deleted. The difference between small and large
+        objects is now stored in metadata and is not a property of their
+        virtual address range.
+
+        * bmalloc/SegregatedFreeList.h: One more entry because we cover all of
+        what used to be the super chunk in a large chunk now.
+
+        * bmalloc/Sizes.h: Removed bit masking helpers because we don't use
+        address masks to distinguish small vs large object type anymore.
+
+        * bmalloc/SmallChunk.h: Removed.
+
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::SmallPage): Store object type per page because any
+        given page can be used for large objects or small objects.
+
+        * bmalloc/SuperChunk.h: Removed.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::VMHeap):
+        (bmalloc::VMHeap::allocateLargeChunk):
+        (bmalloc::VMHeap::allocateSmallChunk): Deleted.
+        (bmalloc::VMHeap::allocateSuperChunk): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateLargeObject):
+        (bmalloc::VMHeap::deallocateLargeObject):
+        (bmalloc::VMHeap::allocateSmallPage): Deleted.
+        (bmalloc::VMHeap::deallocateSmallPage): Deleted. Removed super chunk and
+        small chunk support.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::enumerator):
+        * bmalloc/Zone.h:
+        (bmalloc::Zone::largeChunks):
+        (bmalloc::Zone::addLargeChunk):
+        (bmalloc::Zone::superChunks): Deleted.
+        (bmalloc::Zone::addSuperChunk): Deleted. Removed super chunk and
+        small chunk support.
+
+2016-03-23  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Added an Object helper class
+        https://bugs.webkit.org/show_bug.cgi?id=155818
+
+        Reviewed by Gavin Barraclough.
+
+        Object is an abstraction that breaks out a void* into its component
+        metadata pointers.
+
+        This is slightly faster than recomputing them, and it enables a future
+        patch in which Object will tell us whether it is small or large.
+
+        * bmalloc.xcodeproj/project.pbxproj: Added to the project.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Use Object to compute size.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::processObjectLog):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::deallocateSmallLine):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::derefSmallLine): Use Object to deallocate.
+
+        * bmalloc/Object.h: Added.
+        (bmalloc::Object::Object):
+        (bmalloc::Object::chunk):
+        (bmalloc::Object::line):
+        (bmalloc::Object::page): Helper class to break out a void* into its
+        component metadata pointers.
+
+        * bmalloc/SmallChunk.h:
+        (bmalloc::SmallChunk::SmallChunk): SmallPage::get doesn't exist anymore
+        so we use our new helper functions instead.
+
+        (bmalloc::SmallChunk::offset):
+        (bmalloc::SmallChunk::object):
+        (bmalloc::SmallChunk::page):
+        (bmalloc::SmallChunk::line):
+        (bmalloc::SmallLine::begin):
+        (bmalloc::SmallLine::end):
+        (bmalloc::SmallPage::begin): New helpers that operate on the data
+        stored in Object.
+
+        (bmalloc::SmallLine::get): Deleted.
+        (bmalloc::SmallPage::get): Deleted.
+
+        * bmalloc/SmallLine.h:
+        (bmalloc::SmallLine::refCount): Added a default ref value for convenience.
+
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::SmallPage):
+
+2016-03-23  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: process the object log before asking for new memory
+        https://bugs.webkit.org/show_bug.cgi?id=155801
+
+        Reviewed by Gavin Barraclough.
+
+        This is a step toward merging large and small objects: In future, if we
+        have large objects in the log, we need to process them right away to
+        avoid pushing up peak memory use.
+
+        But it also appears to be a speedup and memory use improvement now.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::refillAllocatorSlowCase):
+        (bmalloc::Allocator::allocateLarge): Process the log before asking for
+        more memory.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::processObjectLog):
+        (bmalloc::Deallocator::deallocateSlowCase):
+        * bmalloc/Deallocator.h: Provide a public API for processing the object log.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallPage): Pop fragmented pages from the front
+        instead of from the back. This resolves a regression on tree_churn
+        --parallel. Popping from the front gives us the oldest pages. The oldest
+        pages have had the most time to accumulate free lines. They are therefore
+        the least fragmented on average.
+
+        * bmalloc/List.h:
+        (bmalloc::List::popFront):
+        (bmalloc::List::insertAfter): New API to pop from front.
+
+2016-03-22  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: use a log scale for large-ish size classes
+        https://bugs.webkit.org/show_bug.cgi?id=155770
+
+        Reviewed by Michael Saboff.
+
+        At larger sizes, precise allocation sizes don't save much memory -- and
+        they can cost memory when objects of distinct size classes can't
+        allocate together.
+
+        This is a small savings up to our current allocation limits, and it may
+        enable changing those limits in the long term.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::log2): We use this to compute large-ish size classes.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator): Iterate by size class instead of by
+        object size so we can change object size limits without breaking stuff.
+
+        (bmalloc::Allocator::scavenge): Ditto.
+
+        (bmalloc::Allocator::allocateLogSizeClass): New helper function for
+        allocating based on log size classes.
+
+        (bmalloc::Allocator::allocateSlowCase): Account for extra size class
+        possibilities.
+
+        * bmalloc/Allocator.h:
+        (bmalloc::Allocator::allocateFastCase): We only handle up to 512b on
+        the fastest fast path now.
+
+        * bmalloc/BumpAllocator.h:
+        (bmalloc::BumpAllocator::validate): Deleted. I noticed that this function
+        had been refactored not to do anything anymore.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::initializeLineMetadata): Iterate by size class. (See
+        Allocator::Allocator.)
+
+        * bmalloc/Heap.h: Use the sizeClassCount constant instead of hard coding
+        things.
+
+        * bmalloc/Sizes.h:
+        (bmalloc::Sizes::maskSizeClass):
+        (bmalloc::Sizes::maskObjectSize):
+        (bmalloc::Sizes::logSizeClass):
+        (bmalloc::Sizes::logObjectSize):
+        (bmalloc::Sizes::sizeClass):
+        (bmalloc::Sizes::objectSize): Separate size class calculation between
+        simple size classes that can be computed with a mask and are 8-byte-precise
+        and complex size classes that require more math and are less precise.
+
+        * bmalloc/SmallLine.h:
+        (bmalloc::SmallLine::ref):
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::SmallPage):
+        (bmalloc::SmallPage::ref):
+        (bmalloc::SmallPage::deref): Cleaned up some ASSERTs that triggered
+        while working on this patch.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::statistics):
+        (bmalloc::zoneSize):
+        (bmalloc::Zone::Zone):
+        (bmalloc::size): Deleted. Renamed these symbols to work around an lldb
+        bug that makes it impossible to print out variables named 'size' -- which
+        can be a problem when working on malloc.
+
+2016-03-22  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: shrink largeMax
+        https://bugs.webkit.org/show_bug.cgi?id=155759
+
+        Reviewed by Michael Saboff.
+
+        If a largeChunk contains N bytes and we allocate objects of size
+        N / 2 + 8 bytes, then we waste 50% of physical memory at peak.
+
+        This patch sets largeMax to N / 2, reducing maximum waste to 25%.
+
+        * bmalloc/BoundaryTag.h:
+        * bmalloc/LargeChunk.h:
+        (bmalloc::LargeChunk::LargeChunk):
+        * bmalloc/SegregatedFreeList.cpp:
+        (bmalloc::SegregatedFreeList::SegregatedFreeList):
+        (bmalloc::SegregatedFreeList::insert): Honor largeMax vs largeObjectMax.
+
+        * bmalloc/Sizes.h: Distinguish between the largest thing we can store
+        in a free list (largeObjectMax) and the largest thing we're willing to
+        allocate (largeMax).
+
+2016-03-20  Dan Bernstein  <mitz@apple.com>
+
+        [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
+        https://bugs.webkit.org/show_bug.cgi?id=155707
+        <rdar://problem/24980691>
+
+        Reviewed by Darin Adler.
+
+        * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
+          component of MACOSX_DEPLOYMENT_TARGET.
+        * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
+          TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.
+
+2016-03-20  Dan Bernstein  <mitz@apple.com>
+
+        Update build settings
+
+        Rubber-stamped by Andy Estes.
+
+        * Configurations/DebugRelease.xcconfig:
+
+2016-03-14  Geoffrey Garen  <ggaren@apple.com>
+
+        Unreviewed, rolling out r197955.
+
+        I decided to go in another direction
+
+        Reverted changeset:
+
+        "bmalloc: Rename SmallPage to SmallRun"
+        https://bugs.webkit.org/show_bug.cgi?id=155320
+        http://trac.webkit.org/changeset/197955
+
+2016-03-10  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Rename SmallPage to SmallRun
+        https://bugs.webkit.org/show_bug.cgi?id=155320
+
+        Reviewed by Alex Christensen.
+
+        A page is a fixed-size set of lines.
+
+        A run is an variable-sized set of lines.
+
+        We want to start using runs because:
+
+            (a) we want to support varying the hardware page size by OS;
+
+            (b) we want to support allocations larger than our current page size.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::initializeSmallRunMetadata):
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::scavengeSmallRuns):
+        (bmalloc::Heap::allocateSmallBumpRanges):
+        (bmalloc::Heap::allocateSmallRun):
+        (bmalloc::Heap::deallocateSmallLine):
+        (bmalloc::Heap::initializeLineMetadata): Deleted.
+        (bmalloc::Heap::scavengeSmallPages): Deleted.
+        (bmalloc::Heap::allocateSmallPage): Deleted.
+        * bmalloc/Heap.h:
+        * bmalloc/LineMetadata.h:
+        * bmalloc/SmallChunk.h:
+        (bmalloc::SmallChunk::begin):
+        (bmalloc::SmallChunk::end):
+        (bmalloc::SmallChunk::lines):
+        (bmalloc::SmallChunk::runs):
+        (bmalloc::SmallChunk::SmallChunk):
+        (bmalloc::SmallLine::end):
+        (bmalloc::SmallRun::get):
+        (bmalloc::SmallRun::begin):
+        (bmalloc::SmallRun::end):
+        (bmalloc::SmallChunk::pages): Deleted.
+        (bmalloc::SmallPage::get): Deleted.
+        (bmalloc::SmallPage::begin): Deleted.
+        (bmalloc::SmallPage::end): Deleted.
+        * bmalloc/SmallPage.h: Removed.
+        * bmalloc/SmallRun.h: Copied from Source/bmalloc/bmalloc/SmallPage.h.
+        (bmalloc::SmallRun::SmallRun):
+        (bmalloc::SmallRun::ref):
+        (bmalloc::SmallRun::deref):
+        (bmalloc::SmallPage::SmallPage): Deleted.
+        (bmalloc::SmallPage::ref): Deleted.
+        (bmalloc::SmallPage::deref): Deleted.
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk):
+        (bmalloc::VMHeap::allocateLargeChunk):
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateSmallRun):
+        (bmalloc::VMHeap::allocateLargeObject):
+        (bmalloc::VMHeap::deallocateSmallRun):
+        (bmalloc::VMHeap::deallocateLargeObject):
+        (bmalloc::VMHeap::allocateSmallPage): Deleted.
+        (bmalloc::VMHeap::deallocateSmallPage): Deleted.
+
+2016-03-08  Geoffrey Garen  <ggaren@apple.com>
+
+        Unreviewed, rolling in r197722.
+        https://bugs.webkit.org/show_bug.cgi?id=155171
+
+        The right calculation for our static_assert is actually:
+
+            sizeof(SmallChunk) % vmPageSize + 2 * smallMax <= vmPageSize
+
+        instead of:
+
+            sizeof(SmallChunk) % vmPageSize + smallMax <= vmPageSize
+
+        smallMax is not enough because line metadata might require us to begin
+        allocation at an offset as large as smallMax, so we need 2 * smallMax.
+
+        Once correct, this static_assert fires, and we fix it by increasing
+        the alignment of SmallChunk.
+
+        Restored changeset:
+
+        "bmalloc: Use List<T> instead of Vector<T> in some places"
+        https://bugs.webkit.org/show_bug.cgi?id=155150
+        http://trac.webkit.org/changeset/197722
+
+2016-03-08  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r197722.
+        https://bugs.webkit.org/show_bug.cgi?id=155171
+
+        This change caused 800+ JSC test failures (Requested by
+        ryanhaddad on #webkit).
+
+        Reverted changeset:
+
+        "bmalloc: Use List<T> instead of Vector<T> in some places"
+        https://bugs.webkit.org/show_bug.cgi?id=155150
+        http://trac.webkit.org/changeset/197722
+
+2016-03-07  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Use List<T> instead of Vector<T> in some places
+        https://bugs.webkit.org/show_bug.cgi?id=155150
+
+        Reviewed by Andreas Kling.
+
+        Vector<T> is expensive when you want a lot of them because our minimum
+        allocation size is the system page size.
+
+        * bmalloc.xcodeproj/project.pbxproj: Added a List<T> class.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavengeSmallPages):
+        (bmalloc::Heap::allocateSmallPage): Use the List<T> API. No need to check
+        for stale entries anymore because List<T> supports O(1) eager removal
+        and we remove eagerly now.
+
+        (bmalloc::Heap::deallocateSmallLine): Remove eagerly. This simplifies
+        the allocation code and it is also required for correctness since we
+        only have enough metadata to be in one list at a time.
+
+        * bmalloc/Heap.h: List!
+
+        * bmalloc/SmallChunk.h: Made this assert a little more precise since this
+        patch triggered the old version in a benign way.
+
+        (bmalloc::SmallChunk::SmallChunk): This code moved to the SmallPage
+        constructor.
+
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::SmallPage): Accomodate the List<T> data structure.
+        This is a net memory savings on Mac for heaps smaller than ~128MB and on
+        iOS for heaps smaller than ~512MB. The maximum memory saved is 512kB on
+        Mac and 2MB on iOS. For larger heaps, there's a memory cost of 0.4% on
+        Mac and 0.1% on iOS.
+
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateSmallPage): Use List<T> API.
+
+2016-03-03  Geoffrey Garen  <ggaren@apple.com>
+
+        Unreviewed, rolling in r197174.
+        https://bugs.webkit.org/show_bug.cgi?id=154762
+
+        The right calculation for alignment is actually:
+
+            vmAlignment - getpagesize() + vmSize
+
+        instead of:
+
+            vmAlignment - vmPageSize + vmSize
+
+        The vmPageSize might be larger than getpagesize().
+
+        Restored changeset:
+
+        "bmalloc: Added a fast XLarge allocator"
+        https://bugs.webkit.org/show_bug.cgi?id=154720
+        http://trac.webkit.org/changeset/197174
+
+2016-02-26  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r197174.
+        https://bugs.webkit.org/show_bug.cgi?id=154762
+
+        This change caused LayoutTests to crash on iOS simulator
+        (Requested by ryanhaddad on #webkit).
+
+        Reverted changeset:
+
+        "bmalloc: Added a fast XLarge allocator"
+        https://bugs.webkit.org/show_bug.cgi?id=154720
+        http://trac.webkit.org/changeset/197174
+
+2016-02-25  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Added a fast XLarge allocator
+        https://bugs.webkit.org/show_bug.cgi?id=154720
+
+        Reviewed by Andreas Kling.
+
+        This is a big speedup for XLarge allocations because it avoids mmap
+        and page fault churn. It also enables future design changes to handle
+        a smaller size range on the fast path.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::roundUpToMultipleOf):
+        (bmalloc::roundDownToMultipleOf): Added a non-constant round down.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::tryAllocate): XLarge no longer requires the caller
+        to align things.
+
+        (bmalloc::Allocator::allocate): Tweaked the alignment calculation for
+        clarity. When alignment and largeAlignment are equal, no adjustment
+        is necessary since all allocations guarantee largeAlignment.
+
+        (bmalloc::Allocator::reallocate): Updated for interface change.
+
+        Note that the new interface fixes some concurrency bugs. The old code
+        kept an iterator into the XLarge allocator across lock drop and acquisition,
+        which is not cool.
+
+        (bmalloc::Allocator::allocateXLarge): XLarge no longer requires the caller
+        to align things.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavengeXLargeObjects): Added scavenging for XLarge.
+
+        (bmalloc::Heap::allocateXLarge):
+
+        (bmalloc::Heap::splitAndAllocate): Split XLarge objects to xLargeAlignment.
+
+        (bmalloc::Heap::tryAllocateXLarge):
+        (bmalloc::Heap::xLargeSize):
+        (bmalloc::Heap::shrinkXLarge):
+        (bmalloc::Heap::deallocateXLarge): Allocate from our map before going
+        to the OS.
+
+        (bmalloc::Heap::findXLarge): Deleted.
+
+        * bmalloc/Heap.h:
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::split):
+
+        * bmalloc/ObjectType.h:
+        (bmalloc::isXLarge): Give XLarge objects an explicit alignment for clarity.
+
+        * bmalloc/Range.h:
+        (bmalloc::Range::size):
+        (bmalloc::Range::operator!):
+        (bmalloc::Range::operator bool):
+        (bmalloc::Range::operator<):
+        (bmalloc::canMerge):
+        (bmalloc::merge): Some helpers that were useful in writing this patch.
+
+        * bmalloc/Sizes.h:
+
+        * bmalloc/SortedVector.h: Added.
+        (bmalloc::SortedVector::Bucket::Bucket):
+        (bmalloc::SortedVector::Bucket::operator<):
+        (bmalloc::SortedVector::iterator::iterator):
+        (bmalloc::SortedVector::iterator::operator++):
+        (bmalloc::SortedVector::iterator::operator!=):
+        (bmalloc::SortedVector::iterator::operator*):
+        (bmalloc::SortedVector::iterator::operator->):
+        (bmalloc::SortedVector::iterator::skipDeletedBuckets):
+        (bmalloc::SortedVector::begin):
+        (bmalloc::SortedVector::end):
+        (bmalloc::SortedVector<T>::insert):
+        (bmalloc::SortedVector<T>::find):
+        (bmalloc::SortedVector<T>::get):
+        (bmalloc::SortedVector<T>::take):
+        (bmalloc::SortedVector<T>::shrinkToFit): A simple abstraction for keeping
+        a sorted vector. Insertion is average amortized log(n) because we keep
+        deleted buckets that we can reuse.
+
+        This is better than a tree because we get better locality, less memory
+        use, and simpler code. Also, trees require a node memory allocator, and
+        implementing a memory allocator in a memory allocator is no fun.
+
+        Arguably we should use a hash table instead. But that's more code, and
+        sorted vector has other nice properties that we might want to take
+        adavantage of in the future.
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate): Fixed an inaccuracy in the alignment calculation
+        here. This code was sort of trying to enforce the alignment that the
+        XLarge allocator enforces -- but it's better to enforce that alignment
+        there.
+
+        The right calculation is:
+
+            vmAlignment - vmPageSize + vmSize
+
+        because the worst case is when you are aligned to 0 + vmPageSize, and
+        you must walk forward vmAlignment - vmPageSize to reach the next
+        vmAlignment.
+
+        (bmalloc::tryVMExtend): Deleted. No need to go back to the OS for VM
+        since we manage our own.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateLargeChunk): Updated for clarity. When we
+        grow the large heap we know that grown region is where the next allocation
+        will take place, so we return it directly instead of pushing it to the
+        free list.
+
+        This fixes a subtle bug where an overly conservative aligned allocation
+        algorithm can fail to allocate at all when it grows the heap.
+
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateLargeObject): Ditto.
+        (bmalloc::VMHeap::allocateLargeObject): Ditto.
+
+        * bmalloc/VMState.h:
+        (bmalloc::merge): Added a helper.
+
+        * bmalloc/Vector.h:
+        (bmalloc::Vector::begin):
+        (bmalloc::Vector::end):
+        (bmalloc::Vector::size):
+        (bmalloc::Vector::capacity):
+        (bmalloc::Vector::last):
+        (bmalloc::Vector::pop):
+        (bmalloc::Vector<T>::push):
+        (bmalloc::Vector<T>::pop):
+        (bmalloc::Vector<T>::shrink): Use a proper iterator API to play nice
+        with std algorithms.
+
+        (bmalloc::Vector<T>::insert): New function required by SortedVector.
+
+        (bmalloc::Vector<T>::reallocateBuffer):
+        (bmalloc::Vector<T>::shrinkCapacity): Allow for shrinking back all the way
+        to 0 because that's what shrinkToFit wants.
+        (bmalloc::Vector<T>::growCapacity):
+        (bmalloc::Vector<T>::shrinkToFit):
+
+        * bmalloc/XLargeMap.cpp: Added. Helper data structure for managing XLarge
+        objects. We have enough granularity in our metadata to represent any
+        kind of address range.
+
+        We store free ranges in a flat vector because most programs have very
+        few individual free XLarge ranges. (They usually merge.)
+
+        We store allocated ranges in a sorted vector because programs might
+        allocate lots of XLarge ranges. For example, if the XLarge minimum is
+        128kB, and you have a 1GB process, that's 8192 ranges. Linear scan would
+        examine 8192 items but binary search only 13.
+
+        Empirically, this is 1.5X faster than our current large allocator if you
+        modify MallocBench/big to allocate XLarge objects and not to initialize
+        objects and you allocate 128kB-256kB objects in a 1GB address space.
+
+        (bmalloc::XLargeMap::takeFree): Be careful about overflow in this function
+        because we support super huge pointers, alignments, and sizes.
+
+        (bmalloc::XLargeMap::addFree): Merge eagerly on free because the cost
+        of missing an XLarge opportunity is catastrophic. Also, I discovered
+        by experiment that any allocator that doesn't merge eagerly can create
+        lots of subtle opportunities for snowballing fragmentation, as
+        fragmentation in range A forces you to chop up range B, and so on.
+
+        We allocate "first fit" (allocating the lowest address) because someone
+        wrote a paper once that said that it's the best algorithm to combat
+        fragmentation (even though worst case fragmentation is unavoidable
+        regardless of algorithm).
+
+        (bmalloc::XLargeMap::addAllocated):
+        (bmalloc::XLargeMap::getAllocated):
+        (bmalloc::XLargeMap::takeAllocated):
+        (bmalloc::XLargeMap::shrinkToFit):
+        (bmalloc::XLargeMap::takePhysical):
+        (bmalloc::XLargeMap::addVirtual):
+        * bmalloc/XLargeMap.h: Added.
+        (bmalloc::XLargeMap::Allocation::operator<):
+
+        * bmalloc/XLargeRange.h: Added.
+        (bmalloc::XLargeRange::XLargeRange):
+        (bmalloc::XLargeRange::vmState):
+        (bmalloc::XLargeRange::setVMState):
+        (bmalloc::canMerge):
+        (bmalloc::merge):
+        (bmalloc::XLargeRange::split): Helper for tracking VMState in a range.
+
+2016-02-23  Dan Bernstein  <mitz@apple.com>
+
+        [Xcode] Linker errors display mangled names, but no longer should
+        https://bugs.webkit.org/show_bug.cgi?id=154632
+
+        Reviewed by Sam Weinig.
+
+        * Configurations/Base.xcconfig: Stop setting LINKER_DISPLAYS_MANGLED_NAMES to YES.
+
+2016-02-22  Konstantin Tokarev  <annulen@yandex.ru>
+
+        Fixed compilation of bmalloc with GCC 4.8 after r196873.
+        https://bugs.webkit.org/show_bug.cgi?id=154534
+
+        Reviewed by Mark Lam.
+
+        See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382.
+
+        * bmalloc/LargeChunk.h:
+        * bmalloc/SmallChunk.h:
+
+2016-02-21  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Don't use a whole page for metadata
+        https://bugs.webkit.org/show_bug.cgi?id=154510
+
+        Reviewed by Andreas Kling.
+
+        (1) Don't round up metadata to a page boundary. This saves 1.5% dirty
+        memory on iOS and 0.2% on Mac. It also enables a future patch to allocate
+        smaller chunks without wasting memory.
+
+        (2) Initialize metadata lazily. This saves dirty memory when the program
+        allocates primarily small or large objects (but not both), leaving some
+        metadata uninitialized.
+
+        * bmalloc.xcodeproj/project.pbxproj: Medium objects are gone now.
+
+        * bmalloc/BumpAllocator.h:
+        (bmalloc::BumpAllocator::refill): Added an ASSERT to help debug a bug
+        I cause while working on this patch.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallBumpRanges): Ditto.
+
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::allocateLarge): Updated for interface change.
+
+        * bmalloc/LargeChunk.h: Changed the boundaryTagCount calculation to
+        a static_assert.
+
+        Don't round up to page boundary. (See above.)
+
+        (bmalloc::LargeChunk::LargeChunk): Moved code here from LargeChunk::init.
+        A constructor is a more natural / automatic way to do this initialization.
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::init): Deleted. Moved to LargeChunk.
+
+        * bmalloc/Sizes.h: Chagned largeChunkMetadataSize to a simpler constant
+        because metadata size no longer varies by page size.
+
+        * bmalloc/SmallChunk.h:
+        (bmalloc::SmallChunk::begin):
+        (bmalloc::SmallChunk::end):
+        (bmalloc::SmallChunk::lines):
+        (bmalloc::SmallChunk::pages): Use std::array to make begin/end
+        calculations easier.
+
+        (bmalloc::SmallChunk::SmallChunk): Treat our metadata like a series
+        of allocated objects. We used to avoid trampling our metadata by
+        starting object memory at the next page. Now we share the first page
+        between metadata and objects, and we account for metadata explicitly.
+
+        * bmalloc/SuperChunk.h:
+        (bmalloc::SuperChunk::SuperChunk):
+        (bmalloc::SuperChunk::smallChunk):
+        (bmalloc::SuperChunk::largeChunk):
+        (bmalloc::SuperChunk::create): Deleted. Don't eagerly run the SmallChunk
+        and LargeChunk constructors. We'll run them lazily as needed.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::VMHeap):
+        (bmalloc::VMHeap::allocateSmallChunk):
+        (bmalloc::VMHeap::allocateLargeChunk):
+        (bmalloc::VMHeap::allocateSuperChunk):
+        (bmalloc::VMHeap::grow): Deleted. Track small and large chunks explicitly
+        so we can initialize them lazily.
+
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateSmallPage):
+        (bmalloc::VMHeap::allocateLargeObject): Specify whether we're allocating
+        a small or large chunk since we don't allocate both at once anymore.
+
+2016-02-20  Mark Lam  <mark.lam@apple.com>
+
+        Use of inlined asm statements causes problems for -std=c99 builds.
+        https://bugs.webkit.org/show_bug.cgi?id=154507
+
+        Reviewed by Dan Bernstein.
+
+        * bmalloc/BAssert.h:
+
+2016-02-19  Joonghun Park  <jh718.park@samsung.com>
+
+        Unreviewed. Fix debug build error since r196847
+
+        Fix gcc build warning appeared as below
+        by removing BASSERT(refCount <= maxRefCount).
+        error: comparison is always true due to limited range of data type
+        [-Werror=type-limits]
+
+        * bmalloc/SmallLine.h:
+        (bmalloc::SmallLine::ref): Deleted.
+
+2016-02-19  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Chunk, Page, and Line don't need to be class templates
+        https://bugs.webkit.org/show_bug.cgi?id=154480
+
+        Reviewed by Gavin Barraclough.
+
+        We needed class templates to distinguish between small and medium,
+        but medium is gone now.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Chunk.h: Removed.
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::initializeLineMetadata):
+        (bmalloc::Heap::allocateSmallBumpRanges):
+        * bmalloc/Heap.h:
+        * bmalloc/Line.h: Removed.
+        * bmalloc/Page.h: Removed.
+        * bmalloc/Sizes.h:
+        * bmalloc/SmallChunk.h: Replaced with Source/bmalloc/bmalloc/Chunk.h.
+        (bmalloc::SmallChunk::begin):
+        (bmalloc::SmallChunk::end):
+        (bmalloc::SmallChunk::lines):
+        (bmalloc::SmallChunk::pages):
+        (bmalloc::SmallChunk::get):
+        (bmalloc::SmallLine::get):
+        (bmalloc::SmallLine::begin):
+        (bmalloc::SmallLine::end):
+        (bmalloc::SmallPage::get):
+        (bmalloc::SmallPage::begin):
+        (bmalloc::SmallPage::end):
+        (bmalloc::Chunk::begin): Deleted.
+        (bmalloc::Chunk::end): Deleted.
+        (bmalloc::Chunk::lines): Deleted.
+        (bmalloc::Chunk::pages): Deleted.
+        * bmalloc/SmallLine.h: Replaced with Source/bmalloc/bmalloc/Line.h.
+        (bmalloc::SmallLine::ref):
+        (bmalloc::SmallLine::deref):
+        (bmalloc::Line<Traits>::begin): Deleted.
+        (bmalloc::Line<Traits>::end): Deleted.
+        (bmalloc::Line<Traits>::ref): Deleted.
+        (bmalloc::Line<Traits>::deref): Deleted.
+        * bmalloc/SmallPage.h: Replaced with Source/bmalloc/bmalloc/Page.h.
+        (bmalloc::SmallPage::hasFreeLines):
+        (bmalloc::SmallPage::setHasFreeLines):
+        (bmalloc::SmallPage::ref):
+        (bmalloc::SmallPage::deref):
+        (bmalloc::Page::hasFreeLines): Deleted.
+        (bmalloc::Page::setHasFreeLines): Deleted.
+        (bmalloc::Page<Traits>::ref): Deleted.
+        (bmalloc::Page<Traits>::deref): Deleted.
+        * bmalloc/SmallTraits.h: Removed.
+
+2016-02-18  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Remove the concept of medium objects
+        https://bugs.webkit.org/show_bug.cgi?id=154436
+
+        Reviewed by Sam Weinig.
+
+        There's no need to distinguish medium objects from small: Small object
+        metadata works naturally for both as long as we allow an object to
+        span more than two small lines. (We already allow an object to span
+        more than one small line.)
+
+        This change reduces memory use because it eliminates the 1kB line size,
+        so we don't have to hold down 1kB lines for individual 264+ byte objects.
+
+        1kB lines were always a bit of a compromise. The main point of bump
+        allocation is to take advantage of cache lines. Cache lines are usually
+        64 bytes, so line sizes above 256 bytes are a bit of a stretch.
+
+        This change speeds up small object benchmarks because it eliminates the
+        branch to detect medium objects in deallocation log processing.
+
+        This change reduces virtual memory use from worst cast 4X to worst case
+        2X because the medium chunk is gone. iOS cares about virtual memory use
+        and terminates apps above ~1GB, so this change gives us more breathing room.
+
+        This change slows down medium benchmarks a bit because we end up doing
+        more work to recycle fragmented medium objects. Overall, the tradeoff
+        seems justified, since we have a net speedup and a memory use savings.
+
+        * bmalloc.xcodeproj/project.pbxproj: Removed all the medium files. We
+        can simplify even further in a follow-up patch, removing the base class
+        templates for Chunk, Page, and Line as well.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::scavenge):
+        (bmalloc::Allocator::refillAllocatorSlowCase):
+        (bmalloc::Allocator::refillAllocator):
+        (bmalloc::Allocator::allocateSlowCase): Medium is gone. Small max is the
+        new medium max.
+
+        * bmalloc/Allocator.h:
+        (bmalloc::Allocator::allocateFastCase): Ditto.
+
+        * bmalloc/BumpAllocator.h:
+        (bmalloc::BumpAllocator::validate):
+        (bmalloc::BumpAllocator::allocate): No more medium.
+
+        * bmalloc/Chunk.h: No more medium.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::processObjectLog): No check for medium. This is
+        a speedup.
+
+        (bmalloc::Deallocator::deallocateSlowCase): No more medium.
+
+        * bmalloc/Deallocator.h:
+        (bmalloc::Deallocator::deallocateFastCase): Ditto.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::initializeLineMetadata): The algorithm here changed from
+        iterating each line to iterating each object. This helps us accomodate
+        objects that might span more than two lines -- i.e., all objects between
+        (512 bytes, 1024 bytes].
+
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::scavengeSmallPages):
+        (bmalloc::Heap::scavengeLargeObjects): Medium is gone.
+
+        (bmalloc::Heap::allocateSmallBumpRanges): Allow for lines that allocate
+        zero objects. This happens when an object spans more than two lines --
+        the middle lines allocate zero objects.
+
+        Also set the "has free lines" bit to false if we consume the last free
+        line. This needs to be a bit now because not all pages agree on their
+        maximum refcount anymore, so we need an explicit signal for the transition
+        from maximum to maximum - 1.
+
+        (bmalloc::Heap::allocateSmallPage): This code didn't change; I just removed
+        the medium code.
+
+        (bmalloc::Heap::deallocateSmallLine): Changed the algorithm to check
+        hasFreeLines. See allocateSmallBumpRanges.
+
+        (bmalloc::Heap::scavengeMediumPages): Deleted.
+        (bmalloc::Heap::allocateMediumBumpRanges): Deleted.
+        (bmalloc::Heap::allocateMediumPage): Deleted.
+        (bmalloc::Heap::deallocateMediumLine): Deleted.
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::derefMediumLine): Deleted.
+
+        * bmalloc/LargeChunk.h:
+        (bmalloc::LargeChunk::get):
+        (bmalloc::LargeChunk::endTag):
+        * bmalloc/Line.h: No more medium.
+
+        * bmalloc/MediumChunk.h: Removed.
+        * bmalloc/MediumLine.h: Removed.
+        * bmalloc/MediumPage.h: Removed.
+        * bmalloc/MediumTraits.h: Removed.
+
+        * bmalloc/ObjectType.cpp:
+        (bmalloc::objectType):
+        * bmalloc/ObjectType.h:
+        (bmalloc::isSmall):
+        (bmalloc::isXLarge):
+        (bmalloc::isSmallOrMedium): Deleted.
+        (bmalloc::isMedium): Deleted. No more medium.
+
+        * bmalloc/Page.h:
+        (bmalloc::Page::sizeClass):
+        (bmalloc::Page::setSizeClass):
+        (bmalloc::Page::hasFreeLines):
+        (bmalloc::Page::setHasFreeLines): Add the free lines bit. You get better
+        codegen if you make it the low bit, since ref / deref can then add / sub
+        2. So do that.
+
+        * bmalloc/Sizes.h:
+        (bmalloc::Sizes::sizeClass): Expand the small size class to include the
+        medium size class.
+
+        * bmalloc/SuperChunk.h:
+        (bmalloc::SuperChunk::SuperChunk):
+        (bmalloc::SuperChunk::smallChunk):
+        (bmalloc::SuperChunk::largeChunk):
+        (bmalloc::SuperChunk::mediumChunk): Deleted. No more medium.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::grow):
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateSmallPage): Set the has free lines bit before
+        returning a Page to the Heap since this is the correct default state
+        when we first allocate a page.
+
+        (bmalloc::VMHeap::allocateMediumPage): Deleted.
+        (bmalloc::VMHeap::deallocateMediumPage): Deleted.
+
+2016-02-19  Michael Saboff  <msaboff@apple.com>
+
+        bmalloc: Unify VMHeap and Heap LargeObjects free lists to reduce fragmentation
+        https://bugs.webkit.org/show_bug.cgi?id=154192
+
+        Reviewed by Geoffrey Garen.
+
+        Change the operation of Heap and VMHeap LargeObject free lists.
+        Renamed Owner to VMState to track the state of each LargeObject.
+            Physical - The pages have been allocated.
+            Virtual - The pages have not been allocated.
+            Mixed - The object contains a mixture of Physical and Virtual pages.
+        VMState uses one bit each for Physical and Virtual to simplify merging states
+        when merging two adjacent blocks.  This change enforces the rule that objects in
+        the Heap free list must have have the Physical bit set in their VMState while objects
+        in the VMHeap free list must have the Physical bit clear.  Thie means that the Heap
+        can have LargeObjects in Physical or Mixed VMState, but the VMHeap's free list can
+        only contain Virtual LargeObjects.
+        
+        In both Heap::allocateLarge(), we now allocate physical pages if the LargeObject we
+        pull from the free list has any Virtual pages before we possilby split the 
+        object.  When we merge objects, the result might be made up of Mixed page allocations.
+        When allocating a Mixed LargeObject, we need to allocate memory for them as well.
+        The scavenger deallocates both Physical and Mixed LargeObjects, placing them back into
+        the VMHeap's free list.
+
+        When we allocate or deallocate Mixed LargeObjects, there are pages that within these
+        objects that will be redundantly modified.  It would require additional metadata to
+        eliminate this redundancy.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/BoundaryTag.h:
+        (bmalloc::BoundaryTag::vmState): New helper.
+        (bmalloc::BoundaryTag::setVMState): New helper.
+        (bmalloc::BoundaryTag::owner): Deleted.
+        (bmalloc::BoundaryTag::setOwner): Deleted.
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::splitAndAllocate): New helpers.
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::vmState): New helper.
+        (bmalloc::LargeObject::setVMState): New helper.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::splitAndAllocate): New helpers.
+        (bmalloc::Heap::allocateLarge): 
+        (bmalloc::Heap::deallocatePhysicalPages): Refactored from VMHeap::deallocateLargeObjectMemory.
+
+        * bmalloc/FreeList.cpp:
+        (bmalloc::FreeList::takeGreedy):
+        (bmalloc::FreeList::take):
+        (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
+        * bmalloc/FreeList.h:
+        (bmalloc::FreeList::FreeList):
+        (bmalloc::FreeList::push):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::scavengeLargeObjects):
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::isValidAndFree):
+        (bmalloc::LargeObject::validateSelf):
+        * bmalloc/SegregatedFreeList.cpp:
+        (bmalloc::SegregatedFreeList::SegregatedFreeList): Changed to initialize our required Physical state.
+        * bmalloc/SegregatedFreeList.h:
+        (bmalloc::SegregatedFreeList::SegregatedFreeList):
+        (bmalloc::SegregatedFreeList::insert):
+        (bmalloc::SegregatedFreeList::takeGreedy):
+        (bmalloc::SegregatedFreeList::take):
+        Replaced Owner parameters and checks with VMState::HasPhysical.
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::prevCanMerge): Removed owner from tests.
+        (bmalloc::LargeObject::nextCanMerge): Removed owner from tests.
+        (bmalloc::LargeObject::merge): Removed owner from tests.  Updated to merge VMStates andset the
+        VMState after the merge.
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::owner): Deleted.
+        (bmalloc::LargeObject::setOwner): Deleted.
+
+        * bmalloc/Owner.h: Removed.
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmAllocatePhysicalPagesSloppy): Changed to round begin down to eliminate the left to right
+        allocation constraint.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::grow): Large space managed like small or medium as a vector of LargeChunks.
+        (bmalloc::VMHeap::VMHeap): Changed to initialize our required Physical state.
+
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateLargeObject): These no longer allocate memory.
+        (bmalloc::VMHeap::deallocateLargeObject): Removed setOwner.  Now we set the VMState after any merges.
+
+        * bmalloc/VMState.h: Copied from Source/bmalloc/bmalloc/Owner.h.
+        (bmalloc::VMState::VMState):
+        (bmalloc::VMState::hasPhysical):
+        (bmalloc::VMState::hasVirtual):
+        (bmalloc::VMState::merge):
+        (bmalloc::VMState::operator ==):
+        (bmalloc::VMState::operator unsigned):
+        New class with various helpers.
+
+2016-02-12  Michael Saboff  <msaboff@apple.com>
+
+        BASSERTs added in r196421 are causing debug test failures
+        https://bugs.webkit.org/show_bug.cgi?id=154113
+
+        Reviewed by Geoffrey Garen.
+
+        In VMHeap::deallocateLargeObject(), we drop the lock to deallocate the physical pages.
+        If the scavenger thread is running at the same time a synchronous call to scavenge()
+        comes in, we could call VMHeap::deallocateLargeObject() for an adjacent object while the
+        lock in the other thread is dropped.  We fix this by checking for adjacent objects we
+        can merge with and loop if we have one.
+
+        * bmalloc/FreeList.h:
+        (bmalloc::FreeList::push): Added BASSERT to catch adding unmerged free objects
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateLarge): Changed to use nextCanMerge().
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::prevCanMerge): Repurposed prevIsAllocated.
+        (bmalloc::LargeObject::nextCanMerge): Repurposed nextIsAllocated.
+        (bmalloc::LargeObject::prevIsAllocated): Deleted.
+        (bmalloc::LargeObject::nextIsAllocated): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateLargeObject): Moved adding the extra object back to the free list
+        to after we set the object we'll return as being allocated.
+        (bmalloc::VMHeap::deallocateLargeObject):
+
+2016-02-12  Mark Lam  <mark.lam@apple.com>
+
+        Make BCRASH() use breakpoint traps too for non-debug OS(DARWIN).
+        https://bugs.webkit.org/show_bug.cgi?id=154184
+
+        Reviewed by Saam Barati.
+
+        This makes it behave consistently with WTFCrash().
+
+        * bmalloc/BAssert.h:
+        * bmalloc/BPlatform.h:
+
+2016-02-11  Michael Saboff  <msaboff@apple.com>
+
+        Unreviewed build fix after r196421.
+
+        Removed BASSERTs that are firing to eliminate Debug build crashes.  I'll debug locally and
+        enable or alter after the issue is understood.
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::merge): Removed BASSERTs that are firing.
+
+2016-02-11  Michael Saboff  <msaboff@apple.com>
+
+        bmalloc: large aligned allocations will put 1 or 2 free object on free list without merging with free neighbors
+        https://bugs.webkit.org/show_bug.cgi?id=154091
+
+        Reviewed by Geoffrey Garen.
+
+        If we split off any unused free object in the aligned version of Heap::allocateLarge(), we merge them with
+        free neighbors before putting them back on the free list.  Added helpers to verify that when we
+        add LargeObjects to the free list their neighbors are allocated.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateLarge): Deleted private helper version and rolled it into the two the
+        two public versions of allocateLarge().
+        * bmalloc/Heap.h:
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::prevIsAllocated): New helper.
+        (bmalloc::LargeObject::nextIsAllocated): New helper.
+        (bmalloc::LargeObject::merge): Check that the merge object has allocated neighbors.
+
+2016-02-05  Saam barati  <sbarati@apple.com>
+
+        bmalloc: largeMax calculation is wrong on iOS
+        https://bugs.webkit.org/show_bug.cgi?id=153923
+
+        Reviewed by Mark Lam.
+
+        Our number for largeMax was larger than what we had
+        space to actually allocate inside the LargeChunk. This made 
+        it so that we would allocate a large object for something
+        that really should be extra large. Previously:
+        largeMax + sizeof(LargeChunk) > 1MB
+        which meant that when we would grow() to accommodate an allocation
+        of a particular size inside a LargeObject despite the fact that
+        the allocation size would be too large to actually fit in the LargeObject.
+        This would manifest when we had an allocation size in the range:
+        1MB - sizeof(LargeChunk) < allocation size < largeMax
+
+        We fix this bug by being precise in our calculation of largeMax
+        instead of just assuming largeChunkSize * 99/100 is enough
+        space for the metadata.
+
+        * bmalloc/LargeChunk.h:
+        (bmalloc::LargeChunk::get):
+        * bmalloc/Sizes.h:
+
+2016-01-31  Dan Bernstein  <mitz@apple.com>
+
+        [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
+        https://bugs.webkit.org/show_bug.cgi?id=153729
+
+        Reviewed by Sam Weinig.
+
+        After r141700, HAVE_HEADER_DETECTION_H is no longer used.
+
+        * Configurations/Base.xcconfig:
+
+2015-12-19  Dan Bernstein  <mitz@apple.com>
+
+        [Mac] WebKit contains dead source code for OS X Mavericks and earlier
+        https://bugs.webkit.org/show_bug.cgi?id=152462
+
+        Reviewed by Alexey Proskuryakov.
+
+        * Configurations/DebugRelease.xcconfig: Removed definition of MACOSX_DEPLOYMENT_TARGET for
+          OS X 10.9.
+
+2015-12-03  Anders Carlsson  <andersca@apple.com>
+
+        Remove Objective-C GC support
+        https://bugs.webkit.org/show_bug.cgi?id=151819
+        rdar://problem/23746991
+
+        Reviewed by Dan Bernstein.
+
+        * Configurations/Base.xcconfig:
+
+2015-12-03  Michael Saboff  <msaboff@apple.com>
+
+        bmalloc: extra large allocations could be more efficient
+        https://bugs.webkit.org/show_bug.cgi?id=151817
+
+        Reviewed by Geoffrey Garen.
+
+        Reduced the super chunk size from 4MB to 2MB.
+
+        Added path to reallocate() of an extra large object to see if we can extend the allocation.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate):
+        * bmalloc/SegregatedFreeList.h:
+        * bmalloc/Sizes.h:
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate):
+        (bmalloc::tryVMExtend):
+        (bmalloc::vmAllocate):
+
+2015-11-11  Akos Kiss  <akiss@inf.u-szeged.hu>
+
+        bmalloc: Add libdl dependency
+        https://bugs.webkit.org/show_bug.cgi?id=151140
+
+        Reviewed by Csaba Osztrogonác.
+
+        Make sure that the linker links libdl and finds the references to
+        dlopen, dlsym and dlclose in Environment.cpp.
+
+        * CMakeLists.txt:
+
+2015-11-02  Andy Estes  <aestes@apple.com>
+
+        [Cocoa] Add tvOS and watchOS to SUPPORTED_PLATFORMS
+        https://bugs.webkit.org/show_bug.cgi?id=150819
+
+        Reviewed by Dan Bernstein.
+
+        This tells Xcode to include these platforms in its Devices dropdown, making it possible to build in the IDE.
+
+        * Configurations/Base.xcconfig:
+
+2015-11-01  Philip Chimento  <philip.chimento@gmail.com>
+
+        [GTK] Fix combinations of PLATFORM(GTK) and OS(DARWIN)
+        https://bugs.webkit.org/show_bug.cgi?id=144560
+
+        Reviewed by Darin Adler.
+
+        * PlatformGTK.cmake: Added. This adds Zone.cpp to the PlatformGTK
+        build, on Darwin only. Since there was previously nothing for the
+        build system to do that was specific to the GTK platform in
+        bmalloc, we need to create this file.
+
+2015-10-29  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: AsyncTask should handle destruction
+        https://bugs.webkit.org/show_bug.cgi?id=150648
+
+        Reviewed by Mark Lam.
+
+        So we can use it in more places.
+
+        * bmalloc/AsyncTask.h: Use std::thread instead of pthread because it
+        should be more portable.
+
+        (bmalloc::Function>::AsyncTask): Renamed Signaled to RunRequested for
+        clarity. Added an ExitRequested state.
+
+        (bmalloc::Function>::~AsyncTask): Wait for our child thread to exit
+        before destroying ourselves because our child thread will modify our
+        data (and might modify our client's data). Note that we only need to
+        wait for the last child thread since any prior child thread, having
+        reached the Exited condition, is guaranteed not to read or write any
+        data.
+
+        (bmalloc::Function>::run):
+        (bmalloc::Function>::runSlowCase): Updated for interface changes. Also
+        changed to use our WebKit style for condition signal: Hold the lock
+        during the signal and always notify all. Technically, neither is necessary,
+        but it is easier to understand the code this way, and harder to make
+        mistakes.
+
+        (bmalloc::Function>::threadEntryPoint):
+        (bmalloc::Function>::threadRunLoop): Handle the new ExitRequested state.
+        Technically, this state has no meaningful difference from the Exited
+        state, but it is nice to be explicit.
+
+        (bmalloc::Function>::join): Deleted.
+        (bmalloc::Function>::pthreadEntryPoint): Deleted.
+        (bmalloc::Function>::entryPoint): Deleted.
+
+2015-10-15  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: per-thread cache data structure should be smaller
+        https://bugs.webkit.org/show_bug.cgi?id=150218
+
+        Reviewed by Andreas Kling.
+
+        Reduce the number of entries in the range cache because it's really
+        big, and the bigness only helps in cases of serious fragmentation, and
+        it only saves us a little bit of lock acquisition time.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::scavenge):
+        (bmalloc::Allocator::refillAllocatorSlowCase):
+        (bmalloc::Allocator::refillAllocator):
+        (bmalloc::Allocator::allocateLarge):
+        (bmalloc::Allocator::allocateSlowCase):
+        (bmalloc::Allocator::allocateBumpRangeSlowCase): Deleted.
+        (bmalloc::Allocator::allocateBumpRange): Deleted.
+        * bmalloc/Allocator.h: Pass through the empty allocator and the range
+        cache when refilling, and refill both. Otherwise, we always immediately
+        pop the last item in the range cache, wasting that slot of capacity.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallBumpRanges):
+        (bmalloc::Heap::allocateMediumBumpRanges): Account for the fact that
+        the range cache is no longer big enough to guarantee that it can hold
+        all the ranges in a page.
+
+        (bmalloc::Heap::refillSmallBumpRangeCache): Deleted.
+        (bmalloc::Heap::refillMediumBumpRangeCache): Deleted.
+
+        * bmalloc/Heap.h: Move VMHeap to the end of the object because it
+        contains a lot of unused / wasted space, and we want to pack our data
+        together in memory.
+
+        * bmalloc/Sizes.h: Make the range cache smaller.
+
+2015-10-13  Chris Dumez  <cdumez@apple.com>
+
+        Avoid useless copies in range-loops that are using 'auto'
+        https://bugs.webkit.org/show_bug.cgi?id=150091
+
+        Reviewed by Sam Weinig.
+
+        Avoid useless copies in range-loops that are using 'auto'. Also use
+        'auto*' instead of 'auto' when range values are pointers for clarity.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::processObjectLog):
+
+2015-10-12  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Don't ASSERT that all syscalls succeed
+        https://bugs.webkit.org/show_bug.cgi?id=150047
+        <rdar://problem/22649531>
+
+        Reviewed by Mark Lam.
+
+        madvise can fail due to VM behaviors outside of our control:
+        copy-on-write, fork, mprotect, and other stuff.
+
+        Older darwin kernels sometimes return this error value, and new kernels
+        might again in future.
+
+        We haven't gained much from this ASSERT so far, so let's remove it.
+
+        Perhaps in future we can come up with a scheme that makes madvise
+        never fail, or that responds to failure.
+
+        * bmalloc/Syscall.h:
+
+2015-10-10  Dan Bernstein  <mitz@apple.com>
+
+        [iOS] Remove project support for iOS 8
+        https://bugs.webkit.org/show_bug.cgi?id=149993
+
+        Reviewed by Alexey Proskuryakov.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/bmalloc.xcconfig:
+        * Configurations/mbmalloc.xcconfig:
+
+2015-08-31  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Implement bmalloc::isASanEnabled for generic Unix
+        https://bugs.webkit.org/show_bug.cgi?id=148623
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc/BPlatform.h: Add BOS_UNIX to detect whether the OS is a Unix.
+        * bmalloc/Environment.cpp:
+        (bmalloc::isASanEnabled): Implement a runtime check that should work on any Unix.
+
+2015-08-19  Geoffrey Garen  <ggaren@apple.com>
+
+        Crash @ bmalloc::Environment::computeIsBmallocEnabled
+        https://bugs.webkit.org/show_bug.cgi?id=148183
+
+        Reviewed by NOBODY Michael Saboff.
+
+        CrashTracer says we have some crashes beneath computeIsBmallocEnabled
+        dereferencing null in strstr. We null check getenv but not
+        _dyld_get_image_name, so deduction indicates that _dyld_get_image_name
+        must be returning null. _dyld_get_image_name isn't really documented,
+        so let's assume it can return null.
+
+        * bmalloc/Environment.cpp:
+        (bmalloc::isASanEnabled): Check _dyld_get_image_name's return value for
+        null because we can't prove it won't be null.
+
+2015-07-24  Geoffrey Garen  <ggaren@apple.com>
+
+        vmmap crash at JavaScriptCore: 0x31cd12f6 (the JavaScript malloc zone enumerator)
+        https://bugs.webkit.org/show_bug.cgi?id=147274
+
+        Reviewed by Anders Carlsson.
+
+        It's not really clear why vmmap sometimes fails to read the target
+        process, but we can avoid a crash when it does. This is useful because
+        you'll still get all the non-bmalloc data out of the target process,
+        and bmalloc might not even be relevant to your investigation.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::remoteRead): Check for failure.
+
+2015-07-24  Geoffrey Garen  <ggaren@apple.com>
+
+        JavaScriptCore bmalloc should not register its malloc zone more than once
+        https://bugs.webkit.org/show_bug.cgi?id=147273
+
+        Reviewed by Andreas Kling.
+
+        This was a goof: The Zone constructor, by virtue of running automatically,
+        was registering a Zone inside the analysis process.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::remoteRead): Clarify that the pointer is remote.
+
+        (bmalloc::enumerator):
+        (bmalloc::Zone::Zone):
+        * bmalloc/Zone.h: Separate the normal constructor and the remote constructor.
+        The remote constructor skips zone registration since its goal is not
+        to register a zone in the current process or do any allocation but rather
+        to mirror the bytes of the zone from the target process.
+
+2015-07-23  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Shrink the super chunk size (again)
+        https://bugs.webkit.org/show_bug.cgi?id=147240
+
+        Reviewed by Andreas Kling.
+
+        Shrinking to 8MB reduced VM exhaustion crashes but did not eliminate them.
+        Let's try 4MB.
+
+        (My previous comment was that the maximum fast object was 2MB. But it
+        was 4MB! Now it's 2MB for realsies.)
+
+        * bmalloc/Sizes.h:
+
+2015-07-03  Dan Bernstein  <mitz@apple.com>
+
+        [Xcode] Update some build settings as recommended by Xcode 7
+        https://bugs.webkit.org/show_bug.cgi?id=146597
+
+        Reviewed by Sam Weinig.
+
+        * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE, GCC_NO_COMMON_BLOCKS,
+        and ENABLE_STRICT_OBJC_MSGSEND. Removed GCC_MODEL_TUNING.
+
+        * bmalloc.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
+
+2015-07-02  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Shrink the super chunk size
+        https://bugs.webkit.org/show_bug.cgi?id=146519
+
+        Reviewed by Andreas Kling.
+
+        We have lots of reports of crashing due to failed VM allocation on iOS.
+        (This VM limit on iOS is usually 1GB-2GB, and has been as low as 256MB.)
+
+        Shrink the super chunk size in case fragmentation is the reason for
+        VM allocation failure.
+
+        This has the downside that >= 2MB allocations will now be super slow,
+        but they are also super rare (as in never on most websites), so this
+        is probably an OK tradeoff.
+
+        * bmalloc/Sizes.h:
+
+2015-07-01  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: realloc of an XLarge range can unmap adjacent VM ranges
+        https://bugs.webkit.org/show_bug.cgi?id=146535
+
+        Reviewed by Anders Carlsson.
+
+        This bug causes a crash when running fast/css/large-list-of-rules-crash.html
+        with the fix applied for https://bugs.webkit.org/show_bug.cgi?id=146519.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Start at object + newSize since starting
+        at object + oldSize means deleting the adjacent VM range.
+
+2015-05-26  Geoffrey Garen  <ggaren@apple.com>
+
+        Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf)
+        https://bugs.webkit.org/show_bug.cgi?id=145385
+
+        Reviewed by Andreas Kling.
+
+        Added some checking to verify that round-up operations will not overflow
+        a size_t.
+
+        The simplest way to do this was to introduce a notion of xLargeMax, like
+        we have for smallMax, mediumMax, and largeMax. It's a bit surprising at
+        first to think that there is an xLargeMax, since xLarge is what we use
+        to handle the biggest things. But computers have limits, so it makes sense.
+
+        FWIW, TCMalloc used to have an xLargeMax too, which it called kMaxValidPages.
+
+        No test because this bug was found by code inspection and I don't know
+        of a practical way to convince WebKit to make an allocation this large.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::allocateSlowCase): Check against xLargeMax to avoid
+        overflow when rounding up.
+
+        * bmalloc/BAssert.h: Added support for explicit crashing.
+
+        * bmalloc/Sizes.h:
+
+2015-05-26  Dan Bernstein  <mitz@apple.com>
+
+        <rdar://problem/21104551> Update build settings
+
+        Reviewed by Anders Carlsson.
+
+        * Configurations/DebugRelease.xcconfig:
+
+2015-05-23  Dan Bernstein  <mitz@apple.com>
+
+        Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
+        https://bugs.webkit.org/show_bug.cgi?id=145345
+
+        Reviewed by Sam Weinig.
+
+        * Configurations/Base.xcconfig: Also changed to use $(inherited).
+
+2015-05-07  Geoffrey Garen  <ggaren@apple.com>
+
+        Release assert in com.apple.WebKit.WebContent under JavaScriptCore: JSC::JSONProtoFuncStringify
+        https://bugs.webkit.org/show_bug.cgi?id=144758
+
+        Reviewed by Andreas Kling.
+
+        This was an out-of-memory error when trying to shrink a string builder.
+        bmalloc was missing the optimization that allowed realloc() to shrink
+        without copying. So, let's add it.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Added Large and XLarge cases for
+        shrinking without copying. This isn't possible for small and medium
+        objects, and probably not very profitable, either.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::findXLarge):
+        (bmalloc::Heap::deallocateXLarge):
+        * bmalloc/Heap.h: Refactored this code to return a reference to an
+        XLarge range. This makes the code reusable, and also makes it easier
+        for realloc() to update metadata.
+
+        * bmalloc/LargeObject.h:
+        (bmalloc::LargeObject::split): Allow allocated objects to split because
+        that's what realloc() wants to do, and there's nothing intrinsically
+        wrong with it.
+
+2015-05-07  Dan Bernstein  <mitz@apple.com>
+
+        <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
+        https://bugs.webkit.org/show_bug.cgi?id=144727
+
+        Reviewed by Darin Adler.
+
+        * Configurations/Base.xcconfig: Dont’s include AspenFamily.xcconfig, and define
+        INSTALL_PATH_PREFIX for the iOS 8.x Simulator.
+
+2015-04-01  Alex Christensen  <achristensen@webkit.org>
+
+        Progress towards CMake on Windows and Mac.
+        https://bugs.webkit.org/show_bug.cgi?id=143293
+
+        Reviewed by Filip Pizlo.
+
+        * bmalloc/BAssert.h:
+        Removed ellipses from macros to appease Visual Studio.
+
+2015-03-13  Alex Christensen  <achristensen@webkit.org>
+
+        Progress towards CMake on Mac.
+        https://bugs.webkit.org/show_bug.cgi?id=142680
+
+        Reviewed by Gyuyoung Kim.
+
+        * CMakeLists.txt:
+        * PlatformMac.cmake:
+        Added Zone.cpp to Mac CMake builds.
+
+2015-03-12  Geoffrey Garen  <ggaren@apple.com>
+
+        Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
+        https://bugs.webkit.org/show_bug.cgi?id=142642
+
+        Reviewed by Michael Saboff.
+
+        The typical backtrace to this crash shows the main thread trying to
+        realloc a large string while a DFG compiler thread tries to
+        free a large vector buffer.
+
+        I believe that this is a race condition -- at least in debug builds --
+        since the main thread will try to validate its object's neighbors
+        without holding a lock, even though those neighbors might be in the
+        midst of changing.
+
+        In general, there may be sneaky times when it is valid to look at an
+        object's metadata without holding the heap lock, but it is best not to
+        do so unless we have a really really good reason to.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Take a lock before reading the metadata
+        for this object, since we generally require any access to shared heap
+        metadata to take a lock.
+
+2015-03-10  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: tryFastMalloc shouldn't crash
+        https://bugs.webkit.org/show_bug.cgi?id=142443
+
+        Reviewed by Sam Weinig.
+
+        Rolling back in r181307 with a check for whether bmalloc is enabled, to
+        avoid crashes when running with ASan and GuardMalloc.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::tryAllocate):
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateXLarge):
+        (bmalloc::Heap::tryAllocateXLarge):
+        * bmalloc/Heap.h:
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate):
+        (bmalloc::vmAllocate):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryMalloc):
+        (bmalloc::api::realloc):
+        (bmalloc::api::free):
+
+2015-03-09  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r181307.
+        https://bugs.webkit.org/show_bug.cgi?id=142525
+
+        Broke ASan tests (Requested by ap on #webkit).
+
+        Reverted changeset:
+
+        "bmalloc: tryFastMalloc shouldn't crash"
+        https://bugs.webkit.org/show_bug.cgi?id=142443
+        http://trac.webkit.org/changeset/181307
+
+2015-03-09  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: tryFastMalloc shouldn't crash
+        https://bugs.webkit.org/show_bug.cgi?id=142443
+
+        Reviewed by Darin Adler.
+
+        Added support for tryMalloc.
+
+        We assume that non-x-large allocations always succeed, and we crash
+        otherwise, since normal allocation failure will just cause the next
+        non-try allocation or internal metadata allocation to fail, and it's
+        hard and not really useful to keep limping along after that. But
+        extra-large allocations can meaningfully fail, and we can recover.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateXLarge):
+        (bmalloc::Heap::tryAllocateXLarge):
+        * bmalloc/Heap.h: Added support for non-crashy x-large allocation.
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate):
+        (bmalloc::vmAllocate): Added support for non-crashy VM allocation.
+
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryMalloc):
+        (bmalloc::api::realloc):
+        (bmalloc::api::free): Tried to clarify our behavior with some comments.
+        Unfortunately, calling what we do "malloc" is still not quite right, since
+        malloc returns null on failure and we don't.
+
+2015-03-03  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Don't branch when setting the owner of a large object
+        https://bugs.webkit.org/show_bug.cgi?id=142241
+
+        Reviewed by Andreas Kling.
+
+        * bmalloc/BoundaryTag.h:
+        (bmalloc::BoundaryTag::owner):
+        (bmalloc::BoundaryTag::setOwner):
+
+2015-03-03  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
+        https://bugs.webkit.org/show_bug.cgi?id=141802
+
+        Reviewed by Andreas Kling.
+
+        Re-enabled this feature on iOS, now that the iOS crash should be fixed.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::grow):
+        * bmalloc/VMHeap.h:
+
+2015-03-03  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Added missing features to the malloc zone introspection API
+        https://bugs.webkit.org/show_bug.cgi?id=142235
+
+        Reviewed by Andreas Kling.
+
+        This should fix the crash we saw on the iOS PLT bot
+        (c.f. http://trac.webkit.org/changeset/180604).
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::good_size):
+        (bmalloc::check):
+        (bmalloc::print):
+        (bmalloc::log):
+        (bmalloc::force_lock):
+        (bmalloc::force_unlock):
+        (bmalloc::statistics):
+        (bmalloc::size):
+        (bmalloc::enumerator): Provide all of these functions since they are called
+        indiscriminately on all zones.
+
+        (bmalloc::Zone::Zone):
+        (bmalloc::Zone::size): Deleted.
+        (bmalloc::Zone::enumerator): Deleted. Moved these functions out of the
+        Zone class since they can stand alone.
+
+        * bmalloc/Zone.h:
+
 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
 
         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)