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)
        https://bugs.webkit.org/show_bug.cgi?id=141802

        Reviewed by Andreas Kling.

        Rolling back in but disabled on iOS until I can debug why the iOS PLT crashes.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h:
        * bmalloc/Zone.cpp:
        (bmalloc::Zone::size):
        (bmalloc::Zone::Zone):
        * bmalloc/Zone.h:

2015-03-03  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Miscellaneous cleanup
        https://bugs.webkit.org/show_bug.cgi?id=142231

        Reviewed by Andreas Kling.

        No performance change -- maybe a tiny reduction in memory use.

        * bmalloc/Heap.cpp: Moved the sleep function into StaticMutex, since
        it's a helper for working with mutexes.

        (bmalloc::Heap::scavenge): Make sure to wait before we start any
        scavenging, since individual scavenging functions now always scavenge
        at least one page before waiting themselves.

        (bmalloc::Heap::scavengeSmallPages):
        (bmalloc::Heap::scavengeMediumPages):
        (bmalloc::Heap::scavengeLargeObjects): Use the new wait helper to
        simplify this code. Also, we now require our caller to wait until at
        least one deallocation is desirable. This simplifies our loop.

        (bmalloc::Heap::allocateSmallPage):
        (bmalloc::Heap::allocateMediumPage):
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::allocateLarge): Don't freak out any time the heap does
        an allocation. Only consider the heap to be growing if it actually needs
        to allocate new VM. This allows us to shrink the heap back down from a
        high water mark more reliably even if heap activity continues.

        (bmalloc::sleep): Deleted.
        (bmalloc::Heap::scavengeLargeRanges): Renamed to match our use of
        "LargeObject".

        * bmalloc/Heap.h:

        * bmalloc/LargeObject.h:
        (bmalloc::LargeObject::operator bool): Added to simplify a while loop.

        * bmalloc/StaticMutex.h:
        (bmalloc::sleep):
        (bmalloc::waitUntilFalse): New helper for waiting until a condition
        becomes reliably false.

        * bmalloc/Vector.h:
        (bmalloc::Vector<T>::~Vector): Oops! Don't deallocate the null pointer.
        We don't actually run any Vector destructors, but an iteration of this
        patch did, and then crashed. So, let's fix that.

2015-03-02  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Eagerly remove allocated objects from the free list
        https://bugs.webkit.org/show_bug.cgi?id=142194

        Reviewed by Andreas Kling.

        This reduces the pressure to garbage collect the free list.

        Might be a 1% speedup on MallocBench.

        * bmalloc/FreeList.cpp: Put this comment at the top of the file instead
        of repeating it inside of each function. Tried to clarify the details.

        (bmalloc::FreeList::takeGreedy): Matched the other iteration code in this
        file for consistency -- even though either direction works fine in this
        function.

        (bmalloc::FreeList::take): Change to iterate from low to high so that we
        can maintain an index into the vector that is not disturbed even if we
        pop from the middle (which invalidates the last index in the vector).

        Decrement i when popping from the middle to make sure that we don't
        skip the next item after popping.

        (bmalloc::FreeList::removeInvalidAndDuplicateEntries): Ditto.

2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>

        Fixed a typo in the previous commit.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::setOwner):

2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>

        EFL build fix after r180797.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::owner):
        (bmalloc::BoundaryTag::setOwner):

2015-02-27  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Pathological madvise churn on the free(malloc(x)) benchmark
        https://bugs.webkit.org/show_bug.cgi?id=142058

        Reviewed by Andreas Kling.

        The churn was caused by repeatedly splitting an object with physical
        pages from an object without, and then merging them back together again.
        The merge would conservatively forget that we had physical pages, forcing
        a new call to madvise on the next allocation.

        This patch more strictly segregates objects in the heap from objects in
        the VM heap, with these changes:

        (1) Objects in the heap are not allowed to merge with objects in the VM
        heap, and vice versa -- since that would erase our precise knowledge of
        which physical pages had been allocated.

        (2) The VM heap is exclusively responsible for allocating and deallocating
        physical pages.

        (3) The heap free list must consider entries for objects that are in the
        VM heap to be invalid, and vice versa. (This condition can arise
        because the free list does not eagerly remove items.)

        With these changes, we can know that any valid object in the heap's free
        list already has physical pages, and does not need to call madvise.

        Note that the VM heap -- as before -- might sometimes contain ranges
        or pieces of ranges that have physical pages, since we allow splitting
        of ranges at granularities smaller than the VM page size. These ranges
        can eventually merge with ranges in the heap during scavenging.

        * bmalloc.xcodeproj/project.pbxproj:

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::owner):
        (bmalloc::BoundaryTag::setOwner):
        (bmalloc::BoundaryTag::initSentinel):
        (bmalloc::BoundaryTag::hasPhysicalPages): Deleted.
        (bmalloc::BoundaryTag::setHasPhysicalPages): Deleted. Replaced the concept
        of "has physical pages" with a bit indicating which heap owns the large
        object. This is a more precise concept, since the old bit was really a
        Yes / Maybe bit.

        * bmalloc/Deallocator.cpp:

        * bmalloc/FreeList.cpp: Adopt
        (bmalloc::FreeList::takeGreedy):
        (bmalloc::FreeList::take):
        (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
        * bmalloc/FreeList.h:
        (bmalloc::FreeList::push): Added API for considering the owner when
        deciding if a free list entry is valid.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::Heap): Adopt new API.

        (bmalloc::Heap::scavengeLargeRanges): Scavenge all ranges with no minimum,
        since some ranges might be able to merge with ranges in the VM heap, and
        they won't be allowed to until we scavenge them.

        (bmalloc::Heap::allocateSmallPage):
        (bmalloc::Heap::allocateMediumPage):
        (bmalloc::Heap::allocateLarge): New VM heap API makes this function
        simpler, since we always get back physical pages now.

        * bmalloc/Heap.h:
        * bmalloc/LargeObject.h:
        (bmalloc::LargeObject::end):
        (bmalloc::LargeObject::owner):
        (bmalloc::LargeObject::setOwner):
        (bmalloc::LargeObject::isValidAndFree):
        (bmalloc::LargeObject::merge): Do not merge objects across heaps since
        that causes madvise churn.
        (bmalloc::LargeObject::validateSelf):
        (bmalloc::LargeObject::init):
        (bmalloc::LargeObject::hasPhysicalPages): Deleted.
        (bmalloc::LargeObject::setHasPhysicalPages): Deleted. Propogate the Owner API.

        * bmalloc/Owner.h: Added.

        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::SegregatedFreeList):
        (bmalloc::SegregatedFreeList::insert):
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h: Propogate the owner API.

        * bmalloc/VMAllocate.h:
        (bmalloc::vmDeallocatePhysicalPagesSloppy):
        (bmalloc::vmAllocatePhysicalPagesSloppy): Clarified these functions and
        removed an edge case.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::VMHeap):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeObject):
        (bmalloc::VMHeap::deallocateLargeObject): Be sure to give each object
        a new chance to merge, since it might have been prohibited from merging
        before by virtue of not being in the VM heap.

        (bmalloc::VMHeap::allocateLargeRange): Deleted.
        (bmalloc::VMHeap::deallocateLargeRange): Deleted.

2015-02-26  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Large object free list can grow infinitely
        https://bugs.webkit.org/show_bug.cgi?id=142055

        Reviewed by Andreas Kling.

        By design, we don't eagerly remove large objects from the free list.
        This creates two simple pathologies:

            (1) If you free and then allocate the same object repeatedly, it will
            duplicate itself in the free list repeatedly. Since it is never
            invalid at the time of allocation, it will never be removed.

            (2) If you split and then merge the same object repeatedly, it will
            duplicate its split sibling in the free list repeatedly. If its
            sibling is in a separate free list size class, it will never be
            consulted at the time of allocation, so it will never be removed.

        So, a simple "while (1) { free(malloc(x)); }" causes infinite memory
        use in the free list.

        The solution in this patch is a simple helper to remove garbage from the
        free list if it grows too large. This pathology is not common, so the
        cost is OK.

        Long-term, perhaps we should rethink the laziness of these free lists.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::isMarked):
        (bmalloc::BoundaryTag::setMarked): New bit, used by free list GC.

        * bmalloc/FreeList.cpp:
        (bmalloc::FreeList::removeInvalidAndDuplicateEntries): The GC algorithm.

        * bmalloc/FreeList.h:
        (bmalloc::FreeList::FreeList):
        (bmalloc::FreeList::push): Invoke the GC if we're getting huge.

        * bmalloc/LargeObject.h:
        (bmalloc::LargeObject::isMarked):
        (bmalloc::LargeObject::setMarked):
        (bmalloc::LargeObject::validateSelf): Expose the new bit.

        * bmalloc/Sizes.h: New constant to control GC frequency.

2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>

        URTBF after r180693.

        * CMakeLists.txt:

2015-02-26  Geoffrey Garen  <ggaren@apple.com>

        Try to fix the Mac build.

        Unreviewed.

        * bmalloc.xcodeproj/project.pbxproj: Make FreeList.h available.

2015-02-26  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Refactored SegregatedFreeList and BoundaryTag::init
        https://bugs.webkit.org/show_bug.cgi?id=142049

        Reviewed by Anders Carlsson.

        Split out a FreeList class from SegregatedFreeList. This will make it
        easier to add behaviors on free list insertion and removal -- and it's
        probably how I should have designed things at the start.

        Moved BoundaryTag::init into LargeObject, since all the related logic
        lives in LargeObject now too, and this allows us to remove BoundaryTagInlines.h.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/BoundaryTagInlines.h: Removed.
        * bmalloc/FreeList.cpp: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.cpp.
        (bmalloc::FreeList::takeGreedy):
        (bmalloc::FreeList::take):
        (bmalloc::SegregatedFreeList::SegregatedFreeList): Deleted.
        (bmalloc::SegregatedFreeList::insert): Deleted.
        (bmalloc::SegregatedFreeList::takeGreedy): Deleted.
        (bmalloc::SegregatedFreeList::take): Deleted.
        * bmalloc/FreeList.h: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.h.
        (bmalloc::FreeList::push):
        * bmalloc/LargeObject.h:
        (bmalloc::LargeObject::init):
        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::SegregatedFreeList):
        (bmalloc::SegregatedFreeList::insert):
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h:
        * bmalloc/Sizes.h:
        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):

2015-02-26  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: free up a bit in BoundaryTag
        https://bugs.webkit.org/show_bug.cgi?id=142048

        Reviewed by Brady Eidson.

        We were wasting a bit by accident, and I need one now.

        * bmalloc/Algorithm.h:
        (bmalloc::rightShift): Deleted. Not needed, now that I've simplified
        the math.

        * bmalloc/BoundaryTag.h: Since each boundary tag bucket is 1024 bytes
        long, the maximum offset into a bucket is 1023.

        You need 5 bits to count up to 1024, but only 4 to count up to 1023.
        
        Math is hard.

        (bmalloc::BoundaryTag::compactBegin): Switched to division because it
        is simpler, and easier to match up with our ASSERT. The compiler will
        turn division by constant power of two into a shift for us.

        (bmalloc::BoundaryTag::setRange): Added an ASSERT for compactBegin
        because we do encode it, so we should ASSERT that encoding did not
        lose information.

        * bmalloc/Sizes.h: Shifting is no longer used since we use division
        instead.

2015-02-24  Stephanie Lewis  <slewis@apple.com>

        Rolling out http://trac.webkit.org/changeset/180430 as it causes the PLT to crash.
        <rdar://problem/19948015>

        Unreviewed.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h:
        * bmalloc/Zone.cpp:
        (bmalloc::Zone::Zone):
        (bmalloc::Zone::size): Deleted.
        * bmalloc/Zone.h:

2015-02-24  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Added a little more abstraction for large objects
        https://bugs.webkit.org/show_bug.cgi?id=141978

        Reviewed by Sam Weinig.

        Previously, each client needed to manage the boundary tags of
        a large object using free functions. This patch introduces a LargeObject
        class that does things a little more automatically.

        * bmalloc.xcodeproj/project.pbxproj:

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::reallocate): Use the new LargeObject class.

        * bmalloc/BeginTag.h:
        (bmalloc::BeginTag::isInFreeList): Deleted. Moved this logic into the
        LargeObject class.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::isSentinel):
        (bmalloc::BoundaryTag::compactBegin):
        (bmalloc::BoundaryTag::setRange):
        (bmalloc::BoundaryTag::initSentinel): Added an explicit API for sentinels,
        which we used to create and test for implicitly.

        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::BoundaryTag::init):
        (bmalloc::validate): Deleted.
        (bmalloc::validatePrev): Deleted.
        (bmalloc::validateNext): Deleted.
        (bmalloc::BoundaryTag::mergeLeft): Deleted.
        (bmalloc::BoundaryTag::mergeRight): Deleted.
        (bmalloc::BoundaryTag::merge): Deleted.
        (bmalloc::BoundaryTag::deallocate): Deleted.
        (bmalloc::BoundaryTag::split): Deleted.
        (bmalloc::BoundaryTag::allocate): Deleted. Moved this logic into the
        LargeObject class.

        * bmalloc/EndTag.h:
        (bmalloc::EndTag::init):
        (bmalloc::EndTag::operator=): Deleted. Re-reading this code, I found
        special behavior in the assignment operator to be a surprising API.
        So, I replaced the assignment operation with an explicit initializing
        function.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::scavengeLargeRanges):
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::findXLarge):
        (bmalloc::Heap::deallocateXLarge):
        (bmalloc::Heap::allocateLarge):
        (bmalloc::Heap::deallocateLarge):
        * bmalloc/Heap.h: No behavior changes here -- just adopting the
        LargeObject interface.

        * bmalloc/LargeObject.h: Added.
        (bmalloc::LargeObject::operator!):
        (bmalloc::LargeObject::begin):
        (bmalloc::LargeObject::size):
        (bmalloc::LargeObject::range):
        (bmalloc::LargeObject::LargeObject):
        (bmalloc::LargeObject::setFree):
        (bmalloc::LargeObject::isFree):
        (bmalloc::LargeObject::hasPhysicalPages):
        (bmalloc::LargeObject::setHasPhysicalPages):
        (bmalloc::LargeObject::isValidAndFree):
        (bmalloc::LargeObject::merge):
        (bmalloc::LargeObject::split):
        (bmalloc::LargeObject::validateSelf):
        (bmalloc::LargeObject::validate): Moved this code into a class, out of
        BoundaryTag free functions.

        New to the class are these features:

            (1) Every reference to an object is validated upon creation and use.

            (2) There's an explicit API for "This is a reference to an object
            that might be stale (the DoNotValidate API)".

            (3) The begin and end tags are kept in sync automatically.

        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::insert):
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h: Adopt the LargeObject interface.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateLargeRange):
        (bmalloc::VMHeap::deallocateLargeRange): Adopt the LargeObject interface.

2015-02-20  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.

        Rolling back in with a fix for a crash seen while using GuardMalloc.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h:
        * bmalloc/Zone.cpp: Re-land the old patch.

        (bmalloc::Zone::size): Be sure to implement the size() function since
        it's accessible indirectly via the malloc_zone_from_ptr public API --
        and GuardMalloc calls it all the time.

        (bmalloc::Zone::Zone):
        * bmalloc/Zone.h: Re-land the old patch.

2015-02-19  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r180363.
        https://bugs.webkit.org/show_bug.cgi?id=141814

        Caused >50 crashes when running LayoutTests in GuardMalloc or
        ASAN modes. (Requested by jernoble on #webkit).

        Reverted changeset:

        "bmalloc should implement malloc introspection (to stop false-
        positive leaks when MallocStackLogging is off)"
        https://bugs.webkit.org/show_bug.cgi?id=141802
        http://trac.webkit.org/changeset/180363

2015-02-19  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.

        Fixed a last-minute type.

        The macro is OS, not PLATFORM.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h:
        * bmalloc/Zone.h:

2015-02-19  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.

        This patch does the bare minimum to stop false positive leaks from
        being reported by the Darwin leaks tool. We register each super chunk
        as a single object, and then request that the leaks tool scan it.

        * bmalloc.xcodeproj/project.pbxproj: Added an abstraction for the malloc
        zone introspection API.

        * bmalloc/Algorithm.h: Missing #include.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        * bmalloc/VMHeap.h: Adopt the new abstraction.

        * bmalloc/Zone.cpp: Added.
        (bmalloc::remoteRead): Helper for reading an object out of another process.
        (bmalloc::Zone::enumerator):
        (bmalloc::Zone::Zone): Register a malloc zone so that we will participate
        in introspection.

        * bmalloc/Zone.h: Added.
        (bmalloc::Zone::superChunks):
        (bmalloc::Zone::addSuperChunk): Use a non-dynamically-allocated vector
        since our dynamic allocations will not be scanned by leaks since they
        will have the malloc VM tag.

2015-02-18  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: VMHeap should keep a record of all of its VM ranges (for malloc introspection)
        https://bugs.webkit.org/show_bug.cgi?id=141759

        Reviewed by Andreas Kling.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/SuperChunk.h: Added.
        (bmalloc::SuperChunk::create):
        (bmalloc::SuperChunk::SuperChunk):
        (bmalloc::SuperChunk::smallChunk):
        (bmalloc::SuperChunk::mediumChunk):
        (bmalloc::SuperChunk::largeChunk): Factored out super chunk creation
        into a separate class, for clarity and type safety.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::grow):
        (bmalloc::VMHeap::allocateSuperChunk): Renamed "allocateSuperChunk" to
        "grow" because Andreas found "allocateSuperChunk" to be unclear.

        * bmalloc/VMHeap.h: Track all our VM ranges. We will use this information
        for malloc introspection.

        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeRange): Updated for renames.

2015-02-18  Zan Dobersek  <zdobersek@igalia.com>

        Build bmalloc through CMake as a static library. It's then linked either
        into the WTF library (if built as a shared library) or into the JSC and
        WebKit2 libraries. There's no need to build it as a standalone shared library.

        Rubber-stamped by Carlos Garcia Campos.

        * CMakeLists.txt:

2015-02-13  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        [BMalloc] Add a FIXME comment for memory alignas
        https://bugs.webkit.org/show_bug.cgi?id=141556

        Reviewed by Csaba Osztrogonác.

        * bmalloc/Chunk.h: Add a FIXME comment.
        * bmalloc/LargeChunk.h: ditto.

2015-02-11  Csaba Osztrogonác  <ossy@webkit.org>

        bmalloc buildfix on 32 bit Linux (x86/ARM)
        https://bugs.webkit.org/show_bug.cgi?id=141472

        Reviewed by Gyuyoung Kim.

        * bmalloc/Algorithm.h:
        (bmalloc::roundUpToMultipleOf):
        * bmalloc/FixedVector.h:
        (bmalloc::FixedVector::clear):
        * bmalloc/Sizes.h:
        (bmalloc::Sizes::sizeClass):

2015-02-11  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        [EFL][GTK] Use bmalloc instead of tcmalloc
        https://bugs.webkit.org/show_bug.cgi?id=140162

        Reviewed by Carlos Garcia Campos.

        Support to use bmalloc on EFL and GTK ports.

        * CMakeLists.txt: Added.
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::allocate):
            Fix unused return value caused by posix_memalign().
        * bmalloc/AsyncTask.h:
        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::clear):
        * bmalloc/Chunk.h:
            Change Traits::Page with Traits::PageType in order to fix
            -fpermitive build error on EFL and GTK port. 
        * bmalloc/EndTag.h:
        (bmalloc::EndTag::operator=):
        * bmalloc/Line.h: ditto.
        * bmalloc/MediumTraits.h:
        * bmalloc/Page.h: ditto.
        * bmalloc/PerThread.h:
            EFL port doesn't support __has_include definition yet.
            Define HAVE_PTHREAD_MACHDEP_H according to check if __has_include is supported.
        * bmalloc/SmallTraits.h: ditto.
        * bmalloc/VMAllocate.h:
        (bmalloc::vmDeallocatePhysicalPages):
        (bmalloc::vmAllocatePhysicalPages):
        * bmalloc/Vector.h:
        (bmalloc::Vector<T>::push):
        (bmalloc::Vector<T>::reallocateBuffer):

2015-01-31  Sam Weinig  <sam@webkit.org>

        Remove even more Mountain Lion support
        https://bugs.webkit.org/show_bug.cgi?id=141124

        Reviewed by Alexey Proskuryakov.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2015-01-30  Geoffrey Garen  <ggaren@apple.com>

        GC marking threads should clear malloc caches
        https://bugs.webkit.org/show_bug.cgi?id=141097

        Reviewed by Andreas Kling.

        Split the scavenging API into per-thread vs global, so that you can
        request to scavenge your own thread without scavenging the whole heap.

        * bmalloc/Cache.cpp:
        (bmalloc::Cache::scavenge):
        * bmalloc/bmalloc.h:
        (bmalloc::api::scavengeThisThread):
        (bmalloc::api::scavenge):

2015-01-28  Dana Burkart  <dburkart@apple.com>

        Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
        https://bugs.webkit.org/show_bug.cgi?id=136765

        Reviewed by Alexey Proskuryakov.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2015-01-21  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: support aligned allocation
        https://bugs.webkit.org/show_bug.cgi?id=140732

        Reviewed by Andreas Kling.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::allocate): New function for aligned allocation.

        Small and medium requests just allocate and free until they find an
        aligned pointer. This is slightly inefficient in the worst case, but
        still constant-time with little-to-no space overhead.

        Large requests use a new API that requires the client to specify both
        its ideal size and alignment, and the worst-case size you would have to
        allocate in order to produce some interior pointer of the requested size
        and alignment. We put the burden of this calculation on the client
        because it simplifies things if we guarantee that allocation won't fail.

        XLarge requests are easy: we just forward them to vmAllocate, which
        already supported aligned requests.

        * bmalloc/BoundaryTag.h:
        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::BoundaryTag::mergeLeft):
        (bmalloc::BoundaryTag::mergeRight):
        (bmalloc::BoundaryTag::merge):
        (bmalloc::BoundaryTag::deallocate):
        (bmalloc::BoundaryTag::split):
        (bmalloc::BoundaryTag::allocate): No behavior change here. I just
        refactored the interface to remove some reference out parameters in
        order to clarify what changes and what doesn't.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::allocateXLarge): Added an alignment API.

        (bmalloc::Heap::allocateLarge):
        * bmalloc/Heap.h: Added an alignment API. I split out allocateLarge into
        a few variants, so aligned and unaligned allocation could share some code.

        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h: Changed to use a separate, explicit API
        for aligned allocation. It turns out that the aligned path is pretty
        different, since it ends up searching for two potential ways to satisfy
        an allocation: either large enough and aligned, or large enough to split
        into something not aligned and something large enough and aligned.

        * bmalloc/VMAllocate.h:
        (bmalloc::vmAllocate): Switched alignment to come before size because
        that's how the memalign API specifies it.

        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateLargeRange): Added an alignment API.

2015-01-20  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: a little bit of cleanup
        https://bugs.webkit.org/show_bug.cgi?id=140687

        Reviewed by Anders Carlsson.

        * bmalloc/Algorithm.h:
        (bmalloc::isPowerOfTwo): Added a check for 0, since 0 would break a lot
        of code.

        * bmalloc/BoundaryTag.h:
        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::BoundaryTag::mergeLeft):
        (bmalloc::BoundaryTag::mergeRight):
        (bmalloc::BoundaryTag::merge):
        (bmalloc::BoundaryTag::deallocate):
        (bmalloc::BoundaryTag::split):
        (bmalloc::BoundaryTag::allocate):
        (bmalloc::BoundaryTag::mergeLargeLeft): Deleted.
        (bmalloc::BoundaryTag::mergeLargeRight): Deleted.
        (bmalloc::BoundaryTag::mergeLarge): Deleted.
        (bmalloc::BoundaryTag::splitLarge): Deleted. Removed the word "Large"
        from all these functions, since boundary tags always pertain to large
        objects, and putting the word "Large" everywhere wasn't helping to
        explain that.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::findXLarge):
        (bmalloc::Heap::deallocateXLarge):
        * bmalloc/Heap.h:
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateXLarge): Deleted.
        (bmalloc::VMHeap::findXLarge): Deleted.
        (bmalloc::VMHeap::deallocateXLarge): Deleted. Moved XLarge allocation
        from VMHeap to Heap. Since the purpose of the VMHeap is to cache VM
        ranges, and the VMHeap never caches any XLarge ranges, it doesn't
        really make sense for the VMHeap to be involved.

2015-01-16  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: refactored XLarge allocation for better alignment
        https://bugs.webkit.org/show_bug.cgi?id=140582

        Reviewed by Andreas Kling.

        XLarge objects used to be Large objects with an extra bit of metadata
        that said "actually, I'm not large -- I'm extra large".

        The metadata header in an XLarge allocation made it impossible for the
        XLarge object to honor a very large alignment request.

        The solution is to stop using a metadata header for XLarge objects, and
        instead to store explicit metadata on the side.

        This is a bit less astonishing, which is also nice.

        Finding XLarge metadata is now a linear search. That's probably OK, since
        it was always so in TCMalloc, and the usual number of XLarge allocations
        in a process is 0.

        This design makes it possible for the heap to cache XLarge allocations
        with and/or without physical pages. I haven't actually done that yet
        because the tradeoffs are subtle, so I don't want to do anything without
        a motivating test case.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::reallocate): Removed the concept of an XLargeChunk,
        since an XLarge allocation is now just a naked buffer without a header.

        (bmalloc::Allocator::allocateXLarge): Added an explicit qualifier for
        XLarge alignment, since XLargeChunk won't give this to us implicitly
        anymore.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::setRange):
        (bmalloc::BoundaryTag::isXLarge): Deleted.
        (bmalloc::BoundaryTag::setXLarge): Deleted.
        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::validate):
        (bmalloc::BoundaryTag::deallocate): Removed the XLarge hacks from Large allocations.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::deallocateXLarge):
        (bmalloc::Deallocator::deallocateSlowCase):
        * bmalloc/Heap.cpp:
        (bmalloc::Heap::findXLarge):
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::deallocateXLarge):
        * bmalloc/Heap.h: Updated for interface changes.

        * bmalloc/ObjectType.cpp:
        (bmalloc::objectType):
        * bmalloc/ObjectType.h:
        (bmalloc::isXLarge): We can now tell if a pointer is XLarge just by
        examining its bit pattern -- just like we do for other kinds of
        allocations -- which is nice.

        * bmalloc/Sizes.h:
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateXLarge):
        (bmalloc::VMHeap::findXLarge):
        (bmalloc::VMHeap::deallocateXLarge): Keep an explicit vector of metadata
        for XLarge allocations.

        * bmalloc/XLargeChunk.h: Removed.

2015-01-16  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: added some infrastructure for aligned allocation
        https://bugs.webkit.org/show_bug.cgi?id=140572

        Reviewed by Andreas Kling.

        * bmalloc/Algorithm.h:
        (bmalloc::isPowerOfTwo):
        (bmalloc::roundUpToMultipleOf):
        (bmalloc::roundDownToMultipleOf): Refactored some duplicate code to use our
        isPowerOfTwo helper function.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::allocate):
        * bmalloc/Allocator.h: Stubbed out an implementation of aligned allocation.
        Doesn't do anything yet, but does correctly forward to system malloc
        when bmalloc is disabled.

        * bmalloc/Cache.cpp:
        (bmalloc::Cache::allocateSlowCaseNullCache):
        * bmalloc/Cache.h:
        (bmalloc::Cache::allocate):
        * bmalloc/bmalloc.h:
        (bmalloc::api::memalign):
        * bmalloc/mbmalloc.cpp: Stubbed out an API for aligned allocation.

2015-01-13  Geoffrey Garen  <ggaren@apple.com>

        Consider alignment when allocating from a SegregatedFreeList
        https://bugs.webkit.org/show_bug.cgi?id=140408

        Reviewed by Sam Weinig.

        In preparation for supporting aligned allocation.

        No performance change.

        Since this is just one extra branch in an already expensive function,
        I decided not to duplicate the function just to avoid the branch in
        the un-aligned case.

        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h:

2015-01-13  Geoffrey Garen  <ggaren@apple.com>

        Renamed minimum to size in SegregatedFreeList
        https://bugs.webkit.org/show_bug.cgi?id=140406

        Reviewed by Sam Weinig.

        In preparation for supporting aligned allocation.

        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take): Every size passed to malloc is
        really just a minimum. Let's not imply that this value is special.

2015-01-11  Dan Bernstein  <mitz@apple.com>

        Geoff is organized, but he is not an organization.

        Rubber-stamped by Anders Carlsson.

        * bmalloc.xcodeproj/project.pbxproj: Removed the ORGANIZATIONNAME project attribute.

2015-01-07  Geoffrey Garen  <ggaren@apple.com>

        Make bmalloc work with ASan
        https://bugs.webkit.org/show_bug.cgi?id=140194

        Reviewed by Mark Lam.

        * bmalloc/BPlatform.h: Added a way to detect Darwin OSes, since we need
        an OS-specific API to test for loaded runtime libraries.

        * bmalloc/Environment.cpp:
        (bmalloc::isASanEnabled):
        (bmalloc::Environment::computeIsBmallocEnabled): Disabled bmalloc if
        ASan is enabled, since system malloc has the Asan hooks we need.

        You could check for the ASan compile-time flag instead, but doing this
        check at runtime prepares bmalloc for a world where it is a dynamic
        library that might be loaded into projects it did not compile with.

2015-01-05  Geoffrey Garen  <ggaren@apple.com>

        Fix up bmalloc's PerThread for use on Linux
        https://bugs.webkit.org/show_bug.cgi?id=139804

        Reviewed by Anders Carlsson.

        The previous implementation was a bit slow.

        * bmalloc/PerThread.h:
        (bmalloc::PerThreadStorage<Cache>::get):
        (bmalloc::PerThreadStorage::get):
        (bmalloc::PerThreadStorage::init): Added a catch-all cross-platform Unix
        way to do fast per-thread access without taking a lock every time. This
        probably works on all the platforms we care about, and it matches other
        techniques we use elsewhere in WebKit.

        (bmalloc::PerThread<T>::getFastCase): Removed the conditional from
        this class because PerThreadStorage now encapsulates everything that
        needs to be conditional.

        (bmalloc::PerThreadStorage::initSharedKeyIfNeeded): Deleted.

2014-12-26  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
        https://bugs.webkit.org/show_bug.cgi?id=139950

        Reviewed by David Kilzer.

        * Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
        in a manner that works with Xcode 5.1.1.

2014-12-15  Geoffrey Garen  <ggaren@apple.com>

        Safari crashes when you set Malloc environment variables
        https://bugs.webkit.org/show_bug.cgi?id=139656

        Reviewed by Michael Saboff.

        I forgot to cover the realloc() case. Whoops. (OoPS?)

        This time around, I ran the full MallocBench test suite in Malloc=1
        mode, and it passed.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::reallocate):
        * bmalloc/Allocator.h: Pushed realloc() logic down into the allocator.
        It needs to be down there so that we can do the short-circuiting check
        for whether bmalloc is enabled first.

        Also added the check.

        * bmalloc/Cache.cpp:
        (bmalloc::Cache::scavenge):
        (bmalloc::Cache::Cache):
        (bmalloc::Cache::reallocateSlowCaseNullCache):
        * bmalloc/Cache.h:
        (bmalloc::Cache::deallocator):
        (bmalloc::Cache::reallocate): Ditto.

        * bmalloc/bmalloc.h:
        (bmalloc::api::free):
        (bmalloc::api::realloc): Ditto.

        (bmalloc::api::scavenge): Pushed this down into Cache to match the
        surrounding functions.

2014-12-11  Geoffrey Garen  <ggaren@apple.com>

        bmalloc should support system memory analysis tools (part 2)
        https://bugs.webkit.org/show_bug.cgi?id=139565

        Reviewed by Mark Lam.

        This patch actually queries the environment to see if memory analysis
        tools have been enabled.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::scavenge): Don't process the object log if
        we've disabled bmalloc because it will be full of invalid nullptrs.

        * bmalloc/Environment.cpp:
        (bmalloc::isMallocEnvironmentVariableSet): Test for the list of known
        Malloc debugging flags. I also added a plain "Malloc" catch-all for
        when you want to disable bmalloc without enabling any kind of funny
        business.

        It would be slightly nicer just to iterate the list of environment
        variables and strstr them, but getenv is the more portable option,
        and performance here doesn't really matter.

        (bmalloc::isLibgmallocEnabled): Test for the libgmalloc insertion
        environment variable.

        (bmalloc::Environment::computeIsBmallocEnabled):

2014-12-11  Geoffrey Garen  <ggaren@apple.com>

        Try to fix the iOS simulator build.

        #include the declaration of malloc / free.

        * bmalloc/Allocator.cpp:
        * bmalloc/Deallocator.cpp:

2014-12-11  Geoffrey Garen  <ggaren@apple.com>

        Try to fix the build.

        * bmalloc.xcodeproj/project.pbxproj: Marked a header exported.

2014-12-11  Geoffrey Garen  <ggaren@apple.com>

        bmalloc should support system memory analysis tools (part 1)
        https://bugs.webkit.org/show_bug.cgi?id=139559

        Reviewed by Mark Lam.

        This patch adds the hooks to disable bmalloc at runtime if certain
        environment variables are set, but doesn't actually read from the
        environment yet.

        No performance change.

        * bmalloc.xcodeproj/project.pbxproj: Added the Environment class, which
        we'll use to read environment variables and see if memory analysis tools
        have been enabled.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator):
        (bmalloc::Allocator::allocateSlowCase): Added a hook to disable bmalloc
        on the allocation path. We cache the setting to make the check fast.

        * bmalloc/Allocator.h: Interface changes.

        * bmalloc/Cache.cpp:
        (bmalloc::Cache::Cache): Pass a heap pointer through to our allocator
        and deallocator. This main purpose is to enable them to query the
        environment for whether bmalloc is enabled; but this is also a slightly
        cleaner way to guarantee to them that the Heap has been pre-initialized.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::Deallocator): If bmalloc is disable, artificially
        fill the object log to force us to take the slow path on all deallocations.

        (bmalloc::Deallocator::deallocateSlowCase): Do the disabled check.

        * bmalloc/Deallocator.h: Interface changes.

        * bmalloc/Environment.cpp: Added.
        (bmalloc::Environment::Environment):
        (bmalloc::Environment::computeIsBmallocEnabled):
        * bmalloc/Environment.h: Added.
        (bmalloc::Environment::isBmallocEnabled): This is the class that will
        encapsulate looking for environment variables that turn on heap
        analysis tools.

        * bmalloc/Heap.h:
        (bmalloc::Heap::environment):

        * bmalloc/Mutex.h:
        (bmalloc::Mutex::Mutex):
        * bmalloc/StaticMutex.h: A little refactoring to clarify these comments,
        since I got super confused about them while writing this patch.

        * bmalloc/VMHeap.cpp: Fixed an #include.

2014-12-09  David Kilzer  <ddkilzer@apple.com>

        Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF
        <http://webkit.org/b/139212>

        Reviewed by Joseph Pecoraro.

        * Configurations/Base.xcconfig:
        - Only set GCC_ENABLE_OBJC_GC, GCC_MODEL_TUNING and TOOLCHAINS
          on OS X.
        * Configurations/DebugRelease.xcconfig:
        - Only set MACOSX_DEPLOYMENT_TARGET and SDKROOT on OS X.

2014-11-07  Geoffrey Garen  <ggaren@apple.com>

        bmalloc uses 8X more virtual memory than necessary
        https://bugs.webkit.org/show_bug.cgi?id=138495

        Reviewed by Mark Lam.

        iOS has a per-process virtual memory cap around 1GB, so there's some
        value to not going totally ham with virtual memory.

        We currently use about 8X the necessary amount:
            - 2X to align our VM allocation
            - 4X to reserve small / medium / (2) large chunk VM ranges per superchunk

        We can cut that down:
            - Return the unaligned portion of our VM allocation (-2X)
            - Use all the chunks in a superchunk, instead of allocating one
              chunk per superchunk (-4X)

        * bmalloc/Algorithm.h:
        (bmalloc::roundUpToMultipleOf): Added a non-constant version of this
        function so we can call it with getpagesize() at runtime.

        * bmalloc/Chunk.h:
        * bmalloc/LargeChunk.h:
        (bmalloc::LargeChunk::create): Deleted. Instead of each chunk allocating
        its own VM, VMHeap allocates the superchunk and all the chunks in it at a time.

        * bmalloc/VMAllocate.h:
        (bmalloc::vmValidate):
        (bmalloc::vmAllocate): ASSERT that mmap succeeds to make crashes clearer
        if it does not succeed. Allocate precisely, and give back the extra.

        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::allocateSuperChunk):
        (bmalloc::VMHeap::allocateSmallChunk): Deleted.
        (bmalloc::VMHeap::allocateMediumChunk): Deleted.
        (bmalloc::VMHeap::allocateLargeChunk): Deleted. Use all the chunks
        in a superchunk, instead of just one.

        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeRange):
        * bmalloc/XLargeChunk.h:
        (bmalloc::XLargeChunk::create): Updated to match changes above.

2014-11-01  David Kilzer  <ddkilzer@apple.com>

        JavaScriptCore is missing debug info for bmalloc because libbmalloc.a is stripped
        <https://webkit.org/b/138286>
        <rdar://problem/18847087>

        Reviewed by Dan Bernstein.

        * Configurations/bmalloc.xcconfig: Set STRIP_INSTALLED_PRODUCT
        to NO for the target that produces libbmalloc.a so that the
        debug symbols will be linked into JavaScriptCore and end up in
        its dSYM file.

2014-10-30  Dana Burkart  <dburkart@apple.com>

        <rdar://problem/18821260> Prepare for the mysterious future

        Reviewed by Lucas Forschler.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2014-09-24  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: cleaned up fast path vs slow path
        https://bugs.webkit.org/show_bug.cgi?id=137081

        Reviewed by Sam Weinig.

        Might be a 1% speedup on MallocBench. Also cleans up the code a bit.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator): Merged the small and medium range
        caches, just like the small and medium allocators. Ranges are abstract
        objects that don't really care whether they hold small or medium objects,
        so they don't need to be segregated.

        (bmalloc::Allocator::scavenge): Ditto.

        (bmalloc::Allocator::allocateBumpRangeSlowCase):
        (bmalloc::Allocator::allocateBumpRange): Same thing here, except that
        we do care a tiny bit, because we need to specify small vs medium when
        allocating new ranges from the heap, to ensure that the heap allocates
        from the right segment of VM.

        (bmalloc::Allocator::allocateLarge):
        (bmalloc::Allocator::allocateXLarge): NO_INLINE because this was clouding
        up the fast path. Large allocation performance is dominated by allocation
        logic and initialization, so inlining it doesn't help.

        (bmalloc::Allocator::allocateSlowCase): Slow path got a bit cleaner since
        it doesn't need to distinguish small vs medium objects.

        (bmalloc::Allocator::allocateSmallBumpRange): Deleted.
        (bmalloc::Allocator::allocateMediumBumpRange): Deleted.

        * bmalloc/Allocator.h:
        * bmalloc/BumpRange.h:

        * bmalloc/Cache.cpp:
        (bmalloc::Cache::allocateSlowCase): Deleted.
        (bmalloc::Cache::deallocateSlowCase): Deleted.
        * bmalloc/Cache.h:
        (bmalloc::Cache::allocate):
        (bmalloc::Cache::deallocate):
        (bmalloc::Cache::allocateFastCase): Deleted.
        (bmalloc::Cache::deallocateFastCase): Deleted. Removed the Cache slow
        paths. The downside to this change is that the fast path branches to two
        distinct failure cases instead of one. The upside is that the slow path
        doesn't need to re-read the segment register, which is not as cheap as a
        normal register, and it doesn't need to do an extra level of function 
        call. Seems to be worth it.

        * bmalloc/Deallocator.h:
        * bmalloc/Heap.cpp:
        (bmalloc::Heap::refillSmallBumpRangeCache):
        (bmalloc::Heap::refillMediumBumpRangeCache):
        * bmalloc/Heap.h: Updated for interface changes.

        * bmalloc/Sizes.h: The most ranges a cache will hold is the number of
        small lines in a page / 2, since any other free lines will coalesce
        with their neighbors.

2014-09-23  Geoffrey Garen  <ggaren@apple.com>

        Rolled out r173346.

            bmalloc should honor the FastMalloc statistics API
            https://bugs.webkit.org/show_bug.cgi?id=136592

        This didn't really work. Because we allow ranges with and without
        physical pages to merge, and we allow double-committing and
        double-decommitting, we can't rely on commit actions to track memory
        footprint.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::size): Deleted.
        (bmalloc::Heap::capacity): Deleted.
        * bmalloc/Heap.h:
        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::VMHeap):
        (bmalloc::VMHeap::allocateSmallChunk):
        (bmalloc::VMHeap::allocateMediumChunk):
        (bmalloc::VMHeap::allocateLargeChunk):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeRange):
        (bmalloc::VMHeap::deallocateSmallPage):
        (bmalloc::VMHeap::deallocateMediumPage):
        (bmalloc::VMHeap::deallocateLargeRange):
        (bmalloc::VMHeap::size): Deleted.
        (bmalloc::VMHeap::capacity): Deleted.
        * bmalloc/bmalloc.h:
        (bmalloc::api::heapSize): Deleted.
        (bmalloc::api::heapCapacity): Deleted.

2014-09-23  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Allocation should be more precise
        https://bugs.webkit.org/show_bug.cgi?id=136993

        Reviewed by Gavin Barraclough.

        13% reduction in heap size on the MallocBench *_memory_warning benchmarks.

        This patch teaches the allocator to merge adjacent free lines into a
        single allocatable range. This allows us to shrink the size of an
        individual line without increasing fragmentation or the rate of allocator
        slow paths.

        We'll only take more slow paths when available memory is sparse, which
        is exactly when it's worth it. When available memory is dense, we'll
        take fewer slow paths.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Algorithm.h:
        (bmalloc::divideRoundingUp):

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator): Updated for interface changes.

        (bmalloc::Allocator::scavenge): Scavenge by object instead of by line.
        Now that we merge lines, it's not convenient to scavenge by line.

        (bmalloc::Allocator::allocateSmallBumpRange):
        (bmalloc::Allocator::allocateMediumBumpRange): Allocate whole ranges
        instead of individual lines.

        (bmalloc::Allocator::allocateSlowCase):
        (bmalloc::Allocator::allocateSmallLine): Deleted.
        (bmalloc::Allocator::allocateMediumLine): Deleted.
        (bmalloc::Allocator::allocateMedium): Deleted.
        * bmalloc/Allocator.h:
        (bmalloc::Allocator::allocateFastCase): Folded medium allocations
        into the standard fast path with small allocations. Since a BumpAllocator
        just allocates out of an arbitrary range, it doesn't need to distinguish
        between small and medium lines.

        * bmalloc/BumpAllocator.h:
        (bmalloc::BumpAllocator::size):
        (bmalloc::BumpAllocator::BumpAllocator):
        (bmalloc::BumpAllocator::init):
        (bmalloc::BumpAllocator::refill):
        (bmalloc::BumpAllocator::line): Deleted. No need to track line information
        anymore: the heap just gives us a pointer and a pre-computed number of
        objects, and we allocate them.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::processObjectLog): Updated for interface changes.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::Heap):
        (bmalloc::Heap::initializeLineMetadata): Pre-compute precise metadata
        detailing where all objects will lie in memory. After we merge two lines,
        we might allocate an object that spans from one line to the next. This
        metadata details which bits of memory overlap in that way, and how they
        overlap.

        (bmalloc::Heap::refillSmallBumpRangeCache):
        (bmalloc::Heap::refillMediumBumpRangeCache): Scan a whole page at a time,
        and merge adjacent free lines into BumpRanges.

        (bmalloc::Heap::allocateSmallPage):
        (bmalloc::Heap::allocateMediumPage):
        (bmalloc::Heap::deallocateSmallLine):
        (bmalloc::Heap::deallocateMediumLine): Track pages rather than lines,
        since we scan for free memory a page at a time.

        (bmalloc::Heap::allocateSmallLineSlowCase): Deleted.
        (bmalloc::Heap::allocateMediumLineSlowCase): Deleted. Folded into the
        fast path.

        * bmalloc/Heap.h:
        (bmalloc::Heap::derefSmallLine):
        (bmalloc::Heap::derefMediumLine):
        (bmalloc::Heap::deallocateSmallLine): Deleted.
        (bmalloc::Heap::allocateSmallLine): Deleted.
        (bmalloc::Heap::deallocateMediumLine): Deleted.
        (bmalloc::Heap::allocateMediumLine): Deleted. Updated for interface changes.

        * bmalloc/Line.h:
        (bmalloc::Line<Traits>::ref):
        (bmalloc::Line<Traits>::deref):
        (bmalloc::Line<Traits>::concurrentRef): Deleted. We don't pass a derefCount
        anymore, since we only ever deref by 1 now.

        * bmalloc/MediumAllocator.h:
        (bmalloc::MediumAllocator::isNull): Deleted.
        (bmalloc::MediumAllocator::MediumAllocator): Deleted.
        (bmalloc::MediumAllocator::line): Deleted.
        (bmalloc::MediumAllocator::allocate): Deleted.
        (bmalloc::MediumAllocator::derefCount): Deleted.
        (bmalloc::MediumAllocator::refill): Deleted.
        (bmalloc::MediumAllocator::clear): Deleted. Deleted some code that's
        been dead for a while, since it doesn't build anymore with this patch.

        * bmalloc/Page.h:
        (bmalloc::Page::sizeClass):
        (bmalloc::Page::setSizeClass):
        (bmalloc::Page::smallSizeClass): Deleted.
        (bmalloc::Page::setSmallSizeClass): Deleted. Renamed setSmallSizeClass
        to sizeClass, since we use it for medium sizes too.

        * bmalloc/Sizes.h:
        (bmalloc::Sizes::sizeClass):
        (bmalloc::Sizes::objectSize): Shrank line sizes to save memory.

        (bmalloc::Sizes::smallSizeClassFor): Deleted.
        (bmalloc::Sizes::mediumSizeClassFor): Deleted.

        * bmalloc/bmalloc.h:
        (bmalloc::api::realloc): Now that we have precise objects sizes, realloc
        can be a bit more precise. It also has to be, since we can't guarantee
        that an object ends at the end of a line anymore.

2014-09-19  Daniel Bates  <dabates@apple.com>

        Always assume internal SDK when building configuration Production
        https://bugs.webkit.org/show_bug.cgi?id=136925
        <rdar://problem/18362399>

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:

2014-09-16  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: moved line caches from the deallocator to the allocator
        https://bugs.webkit.org/show_bug.cgi?id=136868

        Reviewed by Gavin Barraclough.

        I did this mostly as a simplification, to make it easier to change the
        allocation strategy.

        No throughput change on MallocBench. Saves about 50kB.

        Since the deallocator needs to lock the heap when freeing lines anyway,
        there isn't much benefit to giving the deallocator a local cache of
        deallocated lines.

        We still give the allocator a local cache of lines because that does
        reduce the frequency at which it needs to lock the heap in order to
        acquire more lines.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::scavenge):
        (bmalloc::Allocator::allocateSmallLine):
        (bmalloc::Allocator::allocateMediumLine):
        (bmalloc::Allocator::allocateMedium):
        (bmalloc::Allocator::allocateSlowCase):
        * bmalloc/Allocator.h:
        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::Deallocator):
        (bmalloc::Deallocator::scavenge):
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSmallLine): Deleted.
        (bmalloc::Deallocator::allocateSmallLine): Deleted.
        (bmalloc::Deallocator::deallocateMediumLine): Deleted.
        (bmalloc::Deallocator::allocateMediumLine): Deleted.
        * bmalloc/Deallocator.h:

        * bmalloc/Sizes.h:
        * bmalloc/VMAllocate.h: Took the opportunity to make the line cache size
        exactly one page in size. That's about what we were shooting for anyway,
        and it may make it easier to switch to per-page allocation in future.

2014-09-15  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: allocate small and medium objects using the same bump pointer class
        https://bugs.webkit.org/show_bug.cgi?id=136843

        Reviewed by Gavin Barraclough.

        4% speedup on MallocBench.

        Now that medium-sized objects have dedicated per-size allocators, they
        don't need to use an arbitrary bump pointer allocator. This means that
        every allocator knows how many objects it will allocate from the start,
        and we don't need a post-processing step to adjust refcounts based on
        real allocation count.

        * bmalloc.xcodeproj/project.pbxproj: Renamed SmallAllocator to BumpAllocator
        since it's used for small and medium objects now.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator): Updated to use new interface.
        (bmalloc::Allocator::scavenge): To "retire" an allocator, we just need
        to make sure that we finish allocating all the objects in it.

        (bmalloc::Allocator::allocateMedium):
        (bmalloc::Allocator::allocateSlowCase):
        (bmalloc::Allocator::retire): Deleted.
        (bmalloc::Allocator::processSmallAllocatorLog): Deleted.
        (bmalloc::Allocator::processMediumAllocatorLog): Deleted.
        * bmalloc/Allocator.h:
        (bmalloc::Allocator::allocateFastCase): Removed abstractions and data
        used to post-process an allocator based on how many objects it allocated.

        * bmalloc/BumpAllocator.h: Copied from Source/bmalloc/bmalloc/SmallAllocator.h.
        (bmalloc::BumpAllocator::BumpAllocator):
        (bmalloc::BumpAllocator::init):
        (bmalloc::BumpAllocator::line):
        (bmalloc::BumpAllocator::validate):
        (bmalloc::BumpAllocator::allocate):
        (bmalloc::BumpAllocator::refill):
        (bmalloc::BumpAllocator::clear): Updated these functions to be agnostic
        about the kinds of lines they allocate into. In some cases, the line
        type must be provided as a template parameter by the caller.

        (bmalloc::SmallAllocator::SmallAllocator): Deleted.
        (bmalloc::SmallAllocator::line): Deleted.
        (bmalloc::SmallAllocator::allocate): Deleted.
        (bmalloc::SmallAllocator::objectCount): Deleted.
        (bmalloc::SmallAllocator::derefCount): Deleted.
        (bmalloc::SmallAllocator::refill): Deleted.
        (bmalloc::SmallAllocator::clear): Deleted.

        * bmalloc/ObjectType.h:
        (bmalloc::isMedium):

        * bmalloc/SmallAllocator.h:
        (bmalloc::SmallAllocator::isNull): Deleted.
        (bmalloc::SmallAllocator::canAllocate): Deleted.
        (bmalloc::SmallAllocator::SmallAllocator): Deleted.
        (bmalloc::SmallAllocator::line): Deleted.
        (bmalloc::SmallAllocator::allocate): Deleted.
        (bmalloc::SmallAllocator::objectCount): Deleted.
        (bmalloc::SmallAllocator::derefCount): Deleted.
        (bmalloc::SmallAllocator::refill): Deleted.
        (bmalloc::SmallAllocator::clear): Deleted.

2014-09-12  Geoffrey Garen  <ggaren@apple.com>

        Fixed a goof in bmalloc Vector sizing
        https://bugs.webkit.org/show_bug.cgi?id=136795

        Reviewed by Gavin Barraclough and Sam Weinig.

        We want our minimum vector to be page-sized since the OS will give us
        a page no matter what -- but we want that many bytes, and not enough
        bytes to store that many elements.

        * bmalloc/Vector.h: Math is hard.

2014-09-11  Geoffrey Garen  <ggaren@apple.com>

        bmalloc should segregate medium-sized objects by line like it does for small-sized objects
        https://bugs.webkit.org/show_bug.cgi?id=136693

        Reviewed by Gavin Barraclough.

        4% reduction in heap size on the MallocBench *_memory_warning benchmarks.

        No throughput change.

        We keep an array of medium allocators, just like our array of small
        allocators.

        In future, we can simplify the allocation fast path by merging the small
        and medium allocator arrays. For now, this is the simplest change that
        gets the win.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator):
        (bmalloc::Allocator::scavenge):
        (bmalloc::Allocator::allocateMedium):
        * bmalloc/Allocator.h:
        * bmalloc/Sizes.h:
        (bmalloc::Sizes::mediumSizeClassFor):

2014-09-11  Geoffrey Garen  <ggaren@apple.com>

        Reviewed by Sam Weinig.

        Renamed log => retire for clarity.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::scavenge):
        (bmalloc::Allocator::retire):
        (bmalloc::Allocator::allocateMedium):
        (bmalloc::Allocator::allocateSlowCase):
        (bmalloc::Allocator::log): Deleted.
        * bmalloc/Allocator.h:

2014-09-11  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: eager scavenge leaves behind a bogus allocator
        https://bugs.webkit.org/show_bug.cgi?id=136743

        Reviewed by Sam Weinig.

        Be sure to clear the allocator after logging it in the eager scavenge
        case, so that we don't later try to allocate out of the lines that we
        have thrown away.

        We didn't need to do this previously because scavenge would only happen
        at thread exit time, after which no further allocation from the per-thread
        cache would take place.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::scavenge):
        * bmalloc/MediumAllocator.h:
        (bmalloc::MediumAllocator::clear):
        * bmalloc/SmallAllocator.h:
        (bmalloc::SmallAllocator::clear):

2014-09-05  Geoffrey Garen  <ggaren@apple.com>

        bmalloc should honor the FastMalloc statistics API
        https://bugs.webkit.org/show_bug.cgi?id=136592

        Reviewed by Gavin Barraclough.

        We do this by tracking "size" and "capacity" in the VM heap.

        The VM heap's "capacity" is all the VM we ever allocated.

        The VM heap's "size" the subset of VM currently held onto by the
        VM heap (and therefore not in use by the regular heap).

        Somewhat ironically, reducing the process's memory footprint, increases
        the size of the VM heap, since the VM heap holds the pages that are
        purely virtual and not physical.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::size):
        (bmalloc::Heap::capacity):
        * bmalloc/Heap.h:
        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::VMHeap):
        (bmalloc::VMHeap::allocateSmallChunk):
        (bmalloc::VMHeap::allocateMediumChunk):
        (bmalloc::VMHeap::allocateLargeChunk):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::size):
        (bmalloc::VMHeap::capacity):
        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeRange):
        (bmalloc::VMHeap::deallocateSmallPage):
        (bmalloc::VMHeap::deallocateMediumPage):
        (bmalloc::VMHeap::deallocateLargeRange):
        * bmalloc/bmalloc.h:
        (bmalloc::api::heapSize):
        (bmalloc::api::heapCapacity):

2014-09-02  Geoffrey Garen  <ggaren@apple.com>

        bmalloc crashes on the EWS bots (due to bad large object allocation)
        https://bugs.webkit.org/show_bug.cgi?id=136469

        Reviewed by Andreas Kling.

        It's possible to convince bmalloc to perform a bad large object allocation,
        through these steps:

        (1) Insert object A into freelist F0.

        (2) Split, merge and split again A's neighbors such that object B is
        inserted into freelist F0, with boundary tag and size equal to object A,
        but pointer not completely equal to object A. Put object B at the head of F0.

        (3) Allocate some other object from F0, swapping its position in the
        freelist with object B, such that object A is now ahead of object B.

        --> Now, the next allocation for size A/B will allocate object A, which
        has a slightly wrong idea about where the object actually begins.
        Immediately, you'll corrupt a little memory, and over time, you'll also
        corrupt boundary tag metadata.

        The solution is to store the begin pointer in the boundary tag. Luckily,
        this doesn't make the tag any bigger, and it's not a noticeable slowdown
        on MallocBench.

        * bmalloc/Algorithm.h:
        (bmalloc::rightShift):
        * bmalloc/BeginTag.h:
        (bmalloc::BeginTag::isInFreeList): This is the bug fix. Make sure to
        validate the start pointer when popping off the free list. Through a
        very uncommon set of steps, it is possible to have an item in the free
        list that is valid by all accounts except for its start pointer.

        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::compactBegin):
        (bmalloc::BoundaryTag::setRange):
        (bmalloc::BoundaryTag::setSize): Deleted. Record a compact version of the
        start pointer. We don't need the whole pointer -- just the offset, in
        largeAlignment increments, into the relevant boundary tag bucket.

        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::validateNext):
        (bmalloc::BoundaryTag::init):
        (bmalloc::BoundaryTag::mergeLarge):
        (bmalloc::BoundaryTag::splitLarge):
        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::insert):
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take): Provide the whole range instead of
        the size when establishing a boundary tag, as required by the new
        interface.

        * bmalloc/Sizes.h:

2014-08-14  Geoffrey Garen  <ggaren@apple.com>

        Fixed a bmalloc crash seen on the EWS bot
        https://bugs.webkit.org/show_bug.cgi?id=135955

        Reviewed by Andreas Kling.

        * bmalloc/Syscall.h: Some CG APIs vm_copy their input buffers. If the
        input buffer is a malloc region, that region will get marked Copy-On-Write
        by the kernel. Calls to madvise() for COW regions fail and return EINVAL
        on older OS X's. In 10.10, they still fail, but they do not return
        EINVAL.

        So, we can only ASSERT that our syscalls succeed starting with 10.10.

2014-08-14  Geoffrey Garen  <ggaren@apple.com>

        Fixed the bmalloc build
        https://bugs.webkit.org/show_bug.cgi?id=135953

        Reviewed by Andreas Kling.

        * bmalloc.xcodeproj/project.pbxproj: Marked a few headers as private.
        These headers are used, so they must be available outside the project.

2014-08-13  Daniel Bates  <dabates@apple.com>

        Attempt to fix the build following <http://trac.webkit.org/changeset/172576>
        (https://bugs.webkit.org/show_bug.cgi?id=135895)

        Substitute PerThreadStorage<T>::initSharedKeyIfNeeded() for initSharedKeyIfNeeded() in
        implementation of PerThread<T>::getFastCase().

        * bmalloc/PerThread.h:
        (bmalloc::PerThread<T>::getFastCase):

2014-08-13  Daniel Bates  <dabates@apple.com>

        Make bmalloc::PerThread work without C++ thread local storage
        https://bugs.webkit.org/show_bug.cgi?id=135895

        Reviewed by Geoffrey Garen.

        Implement support for building bmalloc without C++ thread local storage.

        * bmalloc/BPlatform.h: Remove macro define BPLATFORM_IOS_SIMULATOR. Added macro function
        BCOMPILER_SUPPORTS() and macro define BCOMPILER_SUPPORTS_CXX_THREAD_LOCAL that can be used
        to determine whether the compiler supports C++ thread local storage.
        * bmalloc/PerThread.h:
        (bmalloc::PerThreadStorage::get): Modified to call pthread_getspecific() when building
        without C++ thread local storage.
        (bmalloc::PerThreadStorage::initSharedKeyIfNeeded): Added.
        (bmalloc::PerThreadStorage::init): Moved logic to initialize shared Pthread key from here to
        PerThreadStorage::initSharedKeyIfNeeded().
        (bmalloc::PerThread<T>::getFastCase): Modified to call PerThreadStorage::initSharedKeyIfNeeded()
        before querying PerThreadStorage::get() when building without C++ thread local storage so as to
        ensure that the shared key has been initialized.
        (_pthread_setspecific_direct): Deleted.
        (_pthread_getspecific_direct): Deleted.

2014-08-13  Daniel Bates  <dabates@apple.com>

        [iOS] Make JavaScriptCore and bmalloc build with the public SDK
        https://bugs.webkit.org/show_bug.cgi?id=135848

        Reviewed by Geoffrey Garen.

        * bmalloc/BPlatform.h: Added macro BPLATFORM_IOS_SIMULATOR, which evaluates to true
        when building for the iOS Simulator.
        * bmalloc/PerThread.h: Use pthread_machdep.h code path when building for iOS Simulator
        using the public SDK.
        (_pthread_setspecific_direct): Added; only defined when building for the iOS Simulator
        using the public SDK.
        (_pthread_getspecific_direct): Added; only defined when building for the iOS Simulator
        using the public SDK.

2014-08-12  Daniel Bates  <dabates@apple.com>

        BPLATFORM(IOS) always evaluates to false
        https://bugs.webkit.org/show_bug.cgi?id=135843

        Reviewed by Geoffrey Garen.

        Fix typo in definition of BPLATFORM() and include system header TargetConditionals.h
        (when building on an Apple platform) so that BPLATFORM(X) evaluates to true when
        building for platform X. In particular, so that BPLATFORM(IOS) evaluates to true when
        building for iOS.

        As a side effect of this change, the change made in <http://trac.webkit.org/changeset/167289>
        will be honored and iOS will assume a VM page size of 16kB (again) instead of 4kB.

        * bmalloc/BPlatform.h:

2014-08-11  Andy Estes  <aestes@apple.com>

        [iOS] Get rid of iOS.xcconfig
        https://bugs.webkit.org/show_bug.cgi?id=135809

        Reviewed by Joseph Pecoraro.

        All iOS.xcconfig did was include AspenFamily.xcconfig, so there's no need for the indirection.

        * Configurations/Base.xcconfig:
        * Configurations/iOS.xcconfig: Removed.
        * bmalloc.xcodeproj/project.pbxproj:

2014-05-01  Dan Bernstein  <mitz@apple.com>

        Fixed production builds for the iOS Simulator.
        <rdar://problem/16792221>

        * Configurations/bmalloc.xcconfig: Include INSTALL_PATH_PREFIX in
        PRIVATE_HEADERS_FOLDER_PATH when installing.

2014-04-20  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Segregate pages by objects size
        https://bugs.webkit.org/show_bug.cgi?id=131909

        Reviewed by Andreas Kling.

        2% reduction in memory-at-end on the Membuster memory_warning benchmarks.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::allocateSlowCase):
        * bmalloc/Allocator.h:
        (bmalloc::Allocator::allocateFastCase):
        (bmalloc::Allocator::smallAllocatorFor): Use the new shared helper
        function for size class calculation.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::Deallocator):
        (bmalloc::Deallocator::scavenge):
        (bmalloc::Deallocator::deallocateSmallLine):
        (bmalloc::Deallocator::allocateSmallLine):
        * bmalloc/Deallocator.h: Keep a cache for every size class, since the
        cache can't be shared anymore.

        * bmalloc/Heap.cpp:
        (bmalloc::Heap::allocateSmallLineSlowCase):
        * bmalloc/Heap.h:
        (bmalloc::Heap::deallocateSmallLine): Ditto.

        (bmalloc::Heap::allocateSmallLine): Check size class in addition to
        page refcount when allocating a line because we might have deallocated
        the page and the recycled it for another size class.

        (bmalloc::Heap::deallocateMediumLine):
        (bmalloc::Heap::allocateMediumLine):
        * bmalloc/Line.h:
        (bmalloc::Line::refCount):
        * bmalloc/Page.h:
        (bmalloc::Page::refCount):
        (bmalloc::Page::smallSizeClass):
        (bmalloc::Page::setSmallSizeClass):
        (bmalloc::Page<Traits>::refCount): Deleted.
        * bmalloc/Sizes.h:
        (bmalloc::Sizes::smallSizeClassFor): New shared API for computing
        an index into an array from a size.

2014-04-19  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Improved alignment in LargeChunk
        https://bugs.webkit.org/show_bug.cgi?id=131895

        Reviewed by Andreas Kling.

        * bmalloc/Chunk.h:
        * bmalloc/LargeChunk.h: Align to vmPageSize just like Chunk does.
        Technically, the previous alignment was harmless, but I would prefer,
        dear reader, not to have to explain the interlocking set of
        circumstances that made it so.

2014-04-19  Geoffrey Garen  <ggaren@apple.com>

        Rolled out r167502 because it caused a crash on the facebook benchmark.

        Unreviewed.

            bmalloc: Added an XSmall line size
            https://bugs.webkit.org/show_bug.cgi?id=131851

            Reviewed by Sam Weinig.

2014-04-19  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Mutex should be harder to use wrong
        https://bugs.webkit.org/show_bug.cgi?id=131879

        Reviewed by Andreas Kling.

        Mutex now has a proper constructor, so you can't deadlock by forgetting
        to initialize it.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::processXSmallAllocatorLog):
        (bmalloc::Allocator::processSmallAllocatorLog):
        (bmalloc::Allocator::processMediumAllocatorLog):
        (bmalloc::Allocator::allocateLarge):
        (bmalloc::Allocator::allocateXLarge): Global replace Mutex => StaticMutex,
        since the Heap mutex is a static.

        * bmalloc/AsyncTask.h:
        (bmalloc::Function>::AsyncTask): Use Mutex, since we're not static. No
        need for explicit initialization anymore.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::scavenge):
        (bmalloc::Deallocator::deallocateLarge):
        (bmalloc::Deallocator::deallocateXLarge):
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSmallLine):
        (bmalloc::Deallocator::deallocateXSmallLine):
        (bmalloc::Deallocator::allocateSmallLine):
        (bmalloc::Deallocator::allocateXSmallLine):
        (bmalloc::Deallocator::deallocateMediumLine):
        (bmalloc::Deallocator::allocateMediumLine):
        * bmalloc/Deallocator.h:
        * bmalloc/Heap.cpp:
        (bmalloc::sleep):
        (bmalloc::Heap::Heap):
        (bmalloc::Heap::concurrentScavenge):
        (bmalloc::Heap::scavenge):
        (bmalloc::Heap::scavengeSmallPages):
        (bmalloc::Heap::scavengeXSmallPages):
        (bmalloc::Heap::scavengeMediumPages):
        (bmalloc::Heap::scavengeLargeRanges):
        (bmalloc::Heap::allocateXSmallLineSlowCase):
        (bmalloc::Heap::allocateSmallLineSlowCase):
        (bmalloc::Heap::allocateMediumLineSlowCase):
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::deallocateXLarge):
        (bmalloc::Heap::allocateLarge):
        (bmalloc::Heap::deallocateLarge):
        * bmalloc/Heap.h:
        (bmalloc::Heap::deallocateXSmallLine):
        (bmalloc::Heap::allocateXSmallLine):
        (bmalloc::Heap::deallocateSmallLine):
        (bmalloc::Heap::allocateSmallLine):
        (bmalloc::Heap::deallocateMediumLine):
        (bmalloc::Heap::allocateMediumLine):
        * bmalloc/Line.h:
        (bmalloc::Line<Traits>::deref):
        * bmalloc/Mutex.cpp: Removed.
        * bmalloc/Mutex.h:
        (bmalloc::Mutex::Mutex):
        (bmalloc::Mutex::init): Deleted.
        (bmalloc::Mutex::try_lock): Deleted.
        (bmalloc::Mutex::lock): Deleted.
        (bmalloc::Mutex::unlock): Deleted.
        * bmalloc/Page.h:
        (bmalloc::Page<Traits>::ref):
        (bmalloc::Page<Traits>::deref):
        (bmalloc::Page<Traits>::refCount):
        * bmalloc/PerProcess.h:
        (bmalloc::PerProcess::mutex):
        (bmalloc::PerProcess<T>::getSlowCase):
        * bmalloc/StaticMutex.cpp: Added.
        (bmalloc::StaticMutex::lockSlowCase):
        * bmalloc/StaticMutex.h: Added.
        (bmalloc::StaticMutex::init):
        (bmalloc::StaticMutex::try_lock):
        (bmalloc::StaticMutex::lock):
        (bmalloc::StaticMutex::unlock):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::deallocateXSmallPage):
        (bmalloc::VMHeap::deallocateSmallPage):
        (bmalloc::VMHeap::deallocateMediumPage):
        (bmalloc::VMHeap::deallocateLargeRange):
        * bmalloc/bmalloc.h:
        (bmalloc::api::scavenge): Global replace Mutex => StaticMutex,
        since the Heap mutex is a static.

2014-04-18  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: AsyncTask should use Mutex instead of std::mutex
        https://bugs.webkit.org/show_bug.cgi?id=131865

        Reviewed by Gavin Barraclough.

        std::mutex is so slow that it makes parallelizing simple tasks through
        AsyncTask a net regression. Mutex fixes this.

        * bmalloc/AsyncTask.h:
        (bmalloc::Function>::AsyncTask):
        (bmalloc::Function>::join):
        (bmalloc::Function>::runSlowCase):
        (bmalloc::Function>::entryPoint):
        * bmalloc/Mutex.h:
        (bmalloc::Mutex::init):

2014-04-18  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Added an XSmall line size
        https://bugs.webkit.org/show_bug.cgi?id=131851

        Reviewed by Sam Weinig.

        Reduces malloc footprint on Membuster recordings by 10%.

        This is a throughput regression, but we're still way ahead of TCMalloc.
        I have some ideas for how to recover the regression -- but I wanted to
        get this win in first.

        Full set of benchmark results:

                bmalloc> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks --measure-heap nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
                                                                                                
                                                               nopatch                      patch                                Δ
                Peak Memory:
                    reddit_memory_warning                      7,896kB                    7,532kB                  ^ 1.05x smaller
                    flickr_memory_warning                     12,968kB                   12,324kB                  ^ 1.05x smaller
                    theverge_memory_warning                   16,672kB                   15,200kB                   ^ 1.1x smaller

                    <geometric mean>                          11,952kB                   11,216kB                  ^ 1.07x smaller
                    <arithmetic mean>                         12,512kB                   11,685kB                  ^ 1.07x smaller
                    <harmonic mean>                           11,375kB                   10,726kB                  ^ 1.06x smaller

                Memory at End:
                    reddit_memory_warning                      7,320kB                    6,856kB                  ^ 1.07x smaller
                    flickr_memory_warning                     10,848kB                    9,692kB                  ^ 1.12x smaller
                    theverge_memory_warning                   16,380kB                   14,872kB                   ^ 1.1x smaller

                    <geometric mean>                          10,916kB                    9,961kB                   ^ 1.1x smaller
                    <arithmetic mean>                         11,516kB                   10,473kB                   ^ 1.1x smaller
                    <harmonic mean>                           10,350kB                    9,485kB                  ^ 1.09x smaller

                MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
                                                                                                
                                                   nopatch                patch                         Δ
                Execution Time:
                    churn                            127ms                151ms            ! 1.19x slower
                    list_allocate                    130ms                164ms            ! 1.26x slower
                    tree_allocate                    109ms                127ms            ! 1.17x slower
                    tree_churn                       115ms                120ms            ! 1.04x slower
                    facebook                         240ms                259ms            ! 1.08x slower
                    fragment                          91ms                131ms            ! 1.44x slower
                    fragment_iterate                 105ms                106ms            ! 1.01x slower
                    message_one                      260ms                259ms             ^ 1.0x faster
                    message_many                     149ms                154ms            ! 1.03x slower
                    medium                           194ms                248ms            ! 1.28x slower
                    big                              157ms                160ms            ! 1.02x slower

                    <geometric mean>                 144ms                163ms            ! 1.13x slower
                    <arithmetic mean>                152ms                171ms            ! 1.12x slower
                    <harmonic mean>                  137ms                156ms            ! 1.14x slower

                MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
                                                                                                
                                                                       nopatch                          patch                                     Δ
                Execution Time:
                    churn                                                126ms                          148ms                        ! 1.17x slower
                    churn --parallel                                      62ms                           76ms                        ! 1.23x slower
                    list_allocate                                        130ms                          164ms                        ! 1.26x slower
                    list_allocate --parallel                             120ms                          175ms                        ! 1.46x slower
                    tree_allocate                                        111ms                          127ms                        ! 1.14x slower
                    tree_allocate --parallel                              95ms                          135ms                        ! 1.42x slower
                    tree_churn                                           115ms                          124ms                        ! 1.08x slower
                    tree_churn --parallel                                107ms                          126ms                        ! 1.18x slower
                    facebook                                             240ms                          276ms                        ! 1.15x slower
                    facebook --parallel                                  802ms                        1,088ms                        ! 1.36x slower
                    fragment                                              92ms                          130ms                        ! 1.41x slower
                    fragment --parallel                                   66ms                          124ms                        ! 1.88x slower
                    fragment_iterate                                     109ms                          127ms                        ! 1.17x slower
                    fragment_iterate --parallel                           55ms                           64ms                        ! 1.16x slower
                    message_one                                          260ms                          260ms                                      
                    message_many                                         170ms                          238ms                         ! 1.4x slower
                    medium                                               185ms                          250ms                        ! 1.35x slower
                    medium --parallel                                    210ms                          334ms                        ! 1.59x slower
                    big                                                  150ms                          169ms                        ! 1.13x slower
                    big --parallel                                       138ms                          144ms                        ! 1.04x slower

                    <geometric mean>                                     135ms                          170ms                        ! 1.26x slower
                    <arithmetic mean>                                    167ms                          214ms                        ! 1.28x slower
                    <harmonic mean>                                      117ms                          148ms                        ! 1.26x slower

                MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks TC:~/scratch/Build-TCMalloc/Release/ patch:~/webkit/WebKitBuild/Release/

                                                                    TC                      patch                                Δ
                Peak Memory:
                    reddit_memory_warning                     13,836kB                   13,436kB                  ^ 1.03x smaller
                    flickr_memory_warning                     24,868kB                   25,188kB                   ! 1.01x bigger
                    theverge_memory_warning                   24,504kB                   26,636kB                   ! 1.09x bigger

                    <geometric mean>                          20,353kB                   20,812kB                   ! 1.02x bigger
                    <arithmetic mean>                         21,069kB                   21,753kB                   ! 1.03x bigger
                    <harmonic mean>                           19,570kB                   19,780kB                   ! 1.01x bigger

                Memory at End:
                    reddit_memory_warning                      8,656kB                   10,016kB                   ! 1.16x bigger
                    flickr_memory_warning                     11,844kB                   13,784kB                   ! 1.16x bigger
                    theverge_memory_warning                   18,516kB                   22,748kB                   ! 1.23x bigger

                    <geometric mean>                          12,382kB                   14,644kB                   ! 1.18x bigger
                    <arithmetic mean>                         13,005kB                   15,516kB                   ! 1.19x bigger
                    <harmonic mean>                           11,813kB                   13,867kB                   ! 1.17x bigger

                MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks TC:~/scratch/Build-TCMalloc/Release/ patch:~/webkit/WebKitBuild/Release/
                                                                                                
                                                        TC                patch                         Δ
                Execution Time:
                    churn                            416ms                148ms            ^ 2.81x faster
                    list_allocate                    463ms                164ms            ^ 2.82x faster
                    tree_allocate                    292ms                127ms             ^ 2.3x faster
                    tree_churn                       157ms                120ms            ^ 1.31x faster
                    facebook                         327ms                276ms            ^ 1.18x faster
                    fragment                         335ms                129ms             ^ 2.6x faster
                    fragment_iterate                 344ms                108ms            ^ 3.19x faster
                    message_one                      386ms                258ms             ^ 1.5x faster
                    message_many                     410ms                154ms            ^ 2.66x faster
                    medium                           391ms                245ms             ^ 1.6x faster
                    big                              261ms                167ms            ^ 1.56x faster

                    <geometric mean>                 332ms                164ms            ^ 2.02x faster
                    <arithmetic mean>                344ms                172ms            ^ 1.99x faster
                    <harmonic mean>                  317ms                157ms            ^ 2.02x faster

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::Allocator): Don't assume that each allocator's
        index corresponds with its size. Instead, use the size selection function
        explicitly. Now that we have XSmall, some small allocator entries are
        unused.

        (bmalloc::Allocator::scavenge):
        (bmalloc::Allocator::log):
        (bmalloc::Allocator::processXSmallAllocatorLog):
        (bmalloc::Allocator::allocateSlowCase):
        * bmalloc/Allocator.h:
        (bmalloc::Allocator::xSmallAllocatorFor):
        (bmalloc::Allocator::allocateFastCase):
        * bmalloc/Chunk.h:
        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::scavenge):
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSlowCase):
        (bmalloc::Deallocator::deallocateXSmallLine):
        (bmalloc::Deallocator::allocateXSmallLine):
        * bmalloc/Deallocator.h:
        (bmalloc::Deallocator::deallocateFastCase):
        * bmalloc/Heap.cpp:
        (bmalloc::Heap::scavenge):
        (bmalloc::Heap::scavengeXSmallPages):
        (bmalloc::Heap::allocateXSmallLineSlowCase):
        * bmalloc/Heap.h:
        (bmalloc::Heap::deallocateXSmallLine):
        (bmalloc::Heap::allocateXSmallLine):
        * bmalloc/LargeChunk.h:
        (bmalloc::LargeChunk::get):
        (bmalloc::LargeChunk::endTag):
        * bmalloc/Line.h:
        * bmalloc/MediumAllocator.h:
        (bmalloc::MediumAllocator::allocate):
        (bmalloc::MediumAllocator::refill):
        * bmalloc/ObjectType.cpp:
        (bmalloc::objectType):
        * bmalloc/ObjectType.h:
        (bmalloc::isXSmall):
        (bmalloc::isSmall):
        (bmalloc::isMedium):
        (bmalloc::isLarge):
        (bmalloc::isSmallOrMedium): Deleted.
        * bmalloc/SegregatedFreeList.h: I boiler-plate copied existing code for
        handling small objects. There's probably a reasonable way to share this
        code in the future -- I'll look into that once it's stopped changing.

        * bmalloc/Sizes.h: Tweaked size classes to make Membuster happy. This
        is the main reason things got slower.

        * bmalloc/SmallAllocator.h:
        (bmalloc::SmallAllocator::allocate):
        * bmalloc/SmallTraits.h:
        * bmalloc/VMHeap.cpp:
        (bmalloc::VMHeap::allocateXSmallChunk):
        * bmalloc/VMHeap.h:
        (bmalloc::VMHeap::allocateXSmallPage):
        (bmalloc::VMHeap::deallocateXSmallPage):
        * bmalloc/XSmallAllocator.h: Added.
        (bmalloc::XSmallAllocator::isNull):
        (bmalloc::XSmallAllocator::canAllocate):
        (bmalloc::XSmallAllocator::XSmallAllocator):
        (bmalloc::XSmallAllocator::line):
        (bmalloc::XSmallAllocator::allocate):
        (bmalloc::XSmallAllocator::objectCount):
        (bmalloc::XSmallAllocator::derefCount):
        (bmalloc::XSmallAllocator::refill):
        * bmalloc/XSmallChunk.h: Added.
        * bmalloc/XSmallLine.h: Added.
        * bmalloc/XSmallPage.h: Added.
        * bmalloc/XSmallTraits.h: Added.
        * bmalloc/bmalloc.h:
        (bmalloc::api::realloc): Boiler-plate copy, as above.

2014-04-14  Geoffrey Garen  <ggaren@apple.com>

        MallocBench should scavenge explicitly instead of waiting
        https://bugs.webkit.org/show_bug.cgi?id=131661

        Reviewed by Andreas Kling.

        Added explicit scavenge support to bmalloc. This isn't a memory win,
        since bmalloc's per-thread cache is so small. But it makes testing
        simpler.

        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::~Allocator):
        (bmalloc::Allocator::scavenge):
        * bmalloc/Allocator.h:
        * bmalloc/Cache.cpp:
        (bmalloc::Cache::operator new):
        (bmalloc::Cache::operator delete):
        (bmalloc::Cache::Cache):
        (bmalloc::Cache::scavenge):
        * bmalloc/Cache.h:
        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::~Deallocator):
        (bmalloc::Deallocator::scavenge):
        * bmalloc/Deallocator.h: Factored existing scavenging code into helper
        functions, for reuse.

        * bmalloc/Heap.cpp:
        (bmalloc::sleep):
        (bmalloc::Heap::concurrentScavenge):
        (bmalloc::Heap::scavenge):
        (bmalloc::Heap::scavengeSmallPages):
        (bmalloc::Heap::scavengeMediumPages):
        (bmalloc::Heap::scavengeLargeRanges):
        * bmalloc/Heap.h: Made scavenge sleep duration a parameter. Forced
        scavenging -- in response to a benchmark or a low memory warning --
        wants to complete as soon as possible, so its sleep duration is 0.

        * bmalloc/bmalloc.h:
        (bmalloc::api::scavenge):
        * bmalloc/mbmalloc.cpp: Exported the scavenge API for MallocBench's use.

2014-04-14  Geoffrey Garen  <ggaren@apple.com>

        Use 4kB pages on Mac
        https://bugs.webkit.org/show_bug.cgi?id=131658

        Reviewed by Sam Weinig.

        This reduces memory use a lot on Membuster:

                                                                  base                      patch                                Δ
                Execution Time:
                    reddit_memory_warning                         18ms                       17ms                   ^ 1.06x faster
                    flickr_memory_warning                         34ms                       36ms                   ! 1.06x slower
                    theverge_memory_warning                       39ms                       41ms                   ! 1.05x slower

                    <geometric mean>                              29ms                       29ms                   ! 1.02x slower
                    <arithmetic mean>                             30ms                       31ms                   ! 1.03x slower
                    <harmonic mean>                               27ms                       27ms                    ^ 1.0x faster

                Peak Memory:
                    reddit_memory_warning                     16,412kB                   16,436kB                    ! 1.0x bigger
                    flickr_memory_warning                     30,120kB                   30,184kB                    ! 1.0x bigger
                    theverge_memory_warning                   33,408kB                   33,420kB                    ! 1.0x bigger

                    <geometric mean>                          25,466kB                   25,499kB                    ! 1.0x bigger
                    <arithmetic mean>                         26,647kB                   26,680kB                    ! 1.0x bigger
                    <harmonic mean>                           24,181kB                   24,214kB                    ! 1.0x bigger

                Memory at End:
                    reddit_memory_warning                      2,404kB                    1,920kB                  ^ 1.25x smaller
                    flickr_memory_warning                      3,764kB                    3,072kB                  ^ 1.23x smaller
                    theverge_memory_warning                    3,648kB                    3,132kB                  ^ 1.16x smaller

                    <geometric mean>                           3,208kB                    2,644kB                  ^ 1.21x smaller
                    <arithmetic mean>                          3,272kB                    2,708kB                  ^ 1.21x smaller
                    <harmonic mean>                            3,139kB                    2,574kB                  ^ 1.22x smaller


        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/BPlatform.h: Added.
        * bmalloc/VMAllocate.h: Only use 16kB pages on iOS because the page size
        is 4kB on Mac.

2014-04-14  Alexey Proskuryakov  <ap@apple.com>

        Fixed svn:ignore on bmalloc.xcodeproj, it had erroneous leading spaces.

        * bmalloc.xcodeproj: Modified property svn:ignore.

2014-04-13  Geoffrey Garen  <ggaren@apple.com>

        Fixed some mbmalloc exports
        https://bugs.webkit.org/show_bug.cgi?id=131599

        Reviewed by Ryosuke Niwa.

        * bmalloc.xcodeproj/project.pbxproj: Made some headers a private part
        of the project, so we can call them from API.

        * bmalloc/mbmalloc.cpp: Marked the mbmalloc functions with default
        visibility, so they show up as exported in the .dylib.

2014-04-09  Geoffrey Garen  <ggaren@apple.com>

        Put bmalloc headers in the right place
        https://bugs.webkit.org/show_bug.cgi?id=131464

        Reviewed by Mark Rowe.

        * Configurations/bmalloc.xcconfig: Set PRIVATE_HEADERS_FOLDER_PATH to
        specify that we don't just want to dump all of our generically-named
        headers into /usr/local/include.

2014-04-08  Geoffrey Garen  <ggaren@apple.com>

        Made bmalloc more #include friendly
        https://bugs.webkit.org/show_bug.cgi?id=131386

        Reviewed by Andreas Kling.

        Marked a bunch of headers private so they can be used from client code
        that #includes bmalloc.h.

        Renamed ASSERT macros to BASSERT. This matches their header, which already
        had to be renamed, and fixes conflicts with WTF's ASSERT macros.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::allocateSlowCase):
        * bmalloc/AsyncTask.h:
        (bmalloc::Function>::runSlowCase):
        * bmalloc/BAssert.h:
        * bmalloc/BoundaryTag.h:
        (bmalloc::BoundaryTag::setSize):
        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::validate):
        (bmalloc::BoundaryTag::init):
        (bmalloc::BoundaryTag::deallocate):
        (bmalloc::BoundaryTag::splitLarge):
        (bmalloc::BoundaryTag::allocate):
        * bmalloc/Chunk.h:
        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSlowCase):
        * bmalloc/Deallocator.h:
        (bmalloc::Deallocator::deallocateFastCase):
        * bmalloc/FixedVector.h:
        (bmalloc::Capacity>::operator):
        (bmalloc::Capacity>::push):
        (bmalloc::Capacity>::pop):
        (bmalloc::Capacity>::shrink):
        * bmalloc/Heap.cpp:
        (bmalloc::Heap::allocateLarge):
        * bmalloc/LargeChunk.h:
        (bmalloc::LargeChunk::get):
        (bmalloc::LargeChunk::endTag):
        * bmalloc/Line.h:
        (bmalloc::Line<Traits>::concurrentRef):
        (bmalloc::Line<Traits>::deref):
        * bmalloc/MediumAllocator.h:
        (bmalloc::MediumAllocator::allocate):
        * bmalloc/ObjectType.h:
        (bmalloc::isSmall):
        * bmalloc/Page.h:
        (bmalloc::Page<Traits>::ref):
        (bmalloc::Page<Traits>::deref):
        * bmalloc/PerThread.h:
        (bmalloc::PerThread<T>::getSlowCase):
        * bmalloc/SegregatedFreeList.cpp:
        (bmalloc::SegregatedFreeList::SegregatedFreeList):
        (bmalloc::SegregatedFreeList::insert):
        * bmalloc/SmallAllocator.h:
        (bmalloc::SmallAllocator::allocate):
        (bmalloc::SmallAllocator::refill):
        * bmalloc/Syscall.h:
        * bmalloc/VMAllocate.h:
        (bmalloc::vmValidate):
        (bmalloc::vmAllocate):
        (bmalloc::vmDeallocatePhysicalPagesSloppy):
        * bmalloc/Vector.h:
        (bmalloc::Vector<T>::operator):
        (bmalloc::Vector<T>::pop):
        (bmalloc::Vector<T>::shrink):
        * bmalloc/XLargeChunk.h:
        (bmalloc::XLargeChunk::range):
        (bmalloc::XLargeChunk::size):

2014-04-08  Geoffrey Garen  <ggaren@apple.com>

        Removed an unused file.

        Unreviewed.

        * bmalloc/AsyncTask.cpp: Removed.

2014-04-07  Geoffrey Garen  <ggaren@apple.com>

        Build bmalloc on Mac
        https://bugs.webkit.org/show_bug.cgi?id=131333

        Reviewed by Mark Rowe.

        * Makefile: Added. For make clients.

        These files are required for building any project in WebKit. I copied
        them from WTF:
        * Configurations: Added.
        * Configurations/Base.xcconfig: Added.
        * Configurations/DebugRelease.xcconfig: Added.
        * Configurations/bmalloc.xcconfig: Added.
        * Configurations/iOS.xcconfig: Added.
        * Configurations/mbmalloc.xcconfig: Added.

        * bmalloc.xcodeproj/project.pbxproj: I removed per-project-file stuff
        from here because everything is in .xcconfig files now.

        I had to fix a bunch of minor warnings, since they're enabled in our
        .xcconfig files:

        * bmalloc/AsyncTask.h:
        (bmalloc::Function>::AsyncTask):
        * bmalloc/BAssert.h:
        * bmalloc/BoundaryTagInlines.h:
        (bmalloc::validate):
        * bmalloc/Heap.cpp:
        (bmalloc::Heap::Heap):
        (bmalloc::Heap::allocateLarge):
        (bmalloc::Heap::deallocateLarge):
        * bmalloc/Mutex.h:
        (bmalloc::Mutex::Mutex): Deleted.
        * bmalloc/VMAllocate.h:
        (bmalloc::vmValidate):
        * bmalloc/mbmalloc.cpp:

2014-04-07  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: Fixed a leak in the per-thread cache
        https://bugs.webkit.org/show_bug.cgi?id=131330

        Reviewed by Andreas Kling.

        Remember to deallocate our line caches upon thread exit.

        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::~Deallocator):

2014-04-07  Geoffrey Garen  <ggaren@apple.com>

        bmalloc: rolled out the tryLock experiment
        https://bugs.webkit.org/show_bug.cgi?id=131328

        Reviewed by Andreas Kling.

        It wasn't a speedup.

        * bmalloc.xcodeproj/project.pbxproj:
        * bmalloc/Allocator.cpp:
        (bmalloc::Allocator::processSmallAllocatorLog):
        (bmalloc::Allocator::processMediumAllocatorLog):
        * bmalloc/Deallocator.cpp:
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSlowCase):
        (bmalloc::Deallocator::deallocateSmallLine):
        (bmalloc::Deallocator::deallocateMediumLine):
        * bmalloc/Deallocator.h:
        (bmalloc::Deallocator::deallocateFastCase):
        * bmalloc/Heap.h:
        (bmalloc::Heap::deallocateSmallLine):
        (bmalloc::Heap::deallocateMediumLine):
        * bmalloc/Line.h:
        (bmalloc::Line<Traits>::deref):
        * bmalloc/Page.h:
        (bmalloc::Page<Traits>::deref):

2014-04-07  Geoffrey Garen  <ggaren@apple.com>

        bmalloc
        https://bugs.webkit.org/show_bug.cgi?id=131170

        Reviewed by Andreas Kling.

        Initial commit.

        * bmalloc: Added.
        * bmalloc.xcodeproj: Added.
        * bmalloc.xcodeproj/project.pbxproj: Added.
        * bmalloc/Algorithm.h: Added.
        (bmalloc::max):
        (bmalloc::min):
        (bmalloc::mask):
        (bmalloc::test):
        (bmalloc::roundUpToMultipleOf):
        (bmalloc::roundDownToMultipleOf):
        (bmalloc::sizeOf):
        (bmalloc::bitCount):
        (bmalloc::isPowerOfTwo):
        * bmalloc/Allocator.cpp: Added.
        (bmalloc::Allocator::Allocator):
        (bmalloc::Allocator::~Allocator):
        (bmalloc::Allocator::log):
        (bmalloc::Allocator::processSmallAllocatorLog):
        (bmalloc::Allocator::processMediumAllocatorLog):
        (bmalloc::Allocator::allocateLarge):
        (bmalloc::Allocator::allocateXLarge):
        (bmalloc::Allocator::allocateMedium):
        (bmalloc::Allocator::allocateSlowCase):
        * bmalloc/Allocator.h: Added.
        (bmalloc::Allocator::smallAllocatorFor):
        (bmalloc::Allocator::allocateFastCase):
        (bmalloc::Allocator::allocate):
        * bmalloc/AsyncTask.cpp: Added.
        (bmalloc::AsyncTask<Function>::runSlowCase):
        (bmalloc::AsyncTask<Function>::pthreadEntryPoint):
        (bmalloc::AsyncTask<Function>::entryPoint):
        * bmalloc/AsyncTask.h: Added.
        (bmalloc::Function>::AsyncTask):
        (bmalloc::Function>::join):
        (bmalloc::Function>::run):
        (bmalloc::Function>::runSlowCase):
        (bmalloc::Function>::pthreadEntryPoint):
        (bmalloc::Function>::entryPoint):
        * bmalloc/BAssert.h: Added.
        * bmalloc/BeginTag.h: Added.
        (bmalloc::BeginTag::isInFreeList):
        * bmalloc/BoundaryTag.h: Added.
        (bmalloc::BoundaryTag::isXLarge):
        (bmalloc::BoundaryTag::setXLarge):
        (bmalloc::BoundaryTag::isFree):
        (bmalloc::BoundaryTag::setFree):
        (bmalloc::BoundaryTag::isEnd):
        (bmalloc::BoundaryTag::setEnd):
        (bmalloc::BoundaryTag::hasPhysicalPages):
        (bmalloc::BoundaryTag::setHasPhysicalPages):
        (bmalloc::BoundaryTag::isNull):
        (bmalloc::BoundaryTag::clear):
        (bmalloc::BoundaryTag::size):
        (bmalloc::BoundaryTag::setSize):
        (bmalloc::BoundaryTag::prev):
        (bmalloc::BoundaryTag::next):
        * bmalloc/BoundaryTagInlines.h: Added.
        (bmalloc::validate):
        (bmalloc::validatePrev):
        (bmalloc::validateNext):
        (bmalloc::BoundaryTag::init):
        (bmalloc::BoundaryTag::mergeLargeLeft):
        (bmalloc::BoundaryTag::mergeLargeRight):
        (bmalloc::BoundaryTag::mergeLarge):
        (bmalloc::BoundaryTag::deallocate):
        (bmalloc::BoundaryTag::splitLarge):
        (bmalloc::BoundaryTag::allocate):
        * bmalloc/Cache.cpp: Added.
        (bmalloc::Cache::operator new):
        (bmalloc::Cache::operator delete):
        (bmalloc::Cache::Cache):
        (bmalloc::Cache::allocateSlowCase):
        (bmalloc::Cache::allocateSlowCaseNullCache):
        (bmalloc::Cache::deallocateSlowCase):
        (bmalloc::Cache::deallocateSlowCaseNullCache):
        * bmalloc/Cache.h: Added.
        (bmalloc::Cache::allocator):
        (bmalloc::Cache::deallocator):
        (bmalloc::Cache::allocateFastCase):
        (bmalloc::Cache::deallocateFastCase):
        (bmalloc::Cache::allocate):
        (bmalloc::Cache::deallocate):
        * bmalloc/Chunk.h: Added.
        (bmalloc::Chunk::begin):
        (bmalloc::Chunk::end):
        (bmalloc::Chunk::lines):
        (bmalloc::Chunk::pages):
        * bmalloc/Deallocator.cpp: Added.
        (bmalloc::Deallocator::Deallocator):
        (bmalloc::Deallocator::~Deallocator):
        (bmalloc::Deallocator::deallocateLarge):
        (bmalloc::Deallocator::deallocateXLarge):
        (bmalloc::Deallocator::processObjectLog):
        (bmalloc::Deallocator::deallocateSlowCase):
        (bmalloc::Deallocator::deallocateSmallLine):
        (bmalloc::Deallocator::allocateSmallLine):
        (bmalloc::Deallocator::deallocateMediumLine):
        (bmalloc::Deallocator::allocateMediumLine):
        * bmalloc/Deallocator.h: Added.
        (bmalloc::Deallocator::deallocateFastCase):
        (bmalloc::Deallocator::deallocate):
        * bmalloc/EndTag.h: Added.
        (bmalloc::EndTag::operator=):
        * bmalloc/FixedVector.h: Added.
        (bmalloc::FixedVector::begin):
        (bmalloc::FixedVector::end):
        (bmalloc::FixedVector::size):
        (bmalloc::FixedVector::capacity):
        (bmalloc::FixedVector::clear):
        (bmalloc::FixedVector::isEmpty):
        (bmalloc::Capacity>::FixedVector):
        (bmalloc::Capacity>::operator):
        (bmalloc::Capacity>::push):
        (bmalloc::Capacity>::pop):
        (bmalloc::Capacity>::shrink):
        * bmalloc/Heap.cpp: Added.
        (bmalloc::sleep):
        (bmalloc::Heap::Heap):
        (bmalloc::Heap::concurrentScavenge):
        (bmalloc::Heap::scavengeSmallPages):
        (bmalloc::Heap::scavengeMediumPages):
        (bmalloc::Heap::scavengeLargeRanges):
        (bmalloc::Heap::allocateSmallLineSlowCase):
        (bmalloc::Heap::allocateMediumLineSlowCase):
        (bmalloc::Heap::allocateXLarge):
        (bmalloc::Heap::deallocateXLarge):
        (bmalloc::Heap::allocateLarge):
        (bmalloc::Heap::deallocateLarge):
        * bmalloc/Heap.h: Added.
        (bmalloc::Heap::deallocateSmallLine):
        (bmalloc::Heap::allocateSmallLine):
        (bmalloc::Heap::deallocateMediumLine):
        (bmalloc::Heap::allocateMediumLine):
        * bmalloc/Inline.h: Added.
        * bmalloc/LargeChunk.h: Added.
        (bmalloc::LargeChunk::begin):
        (bmalloc::LargeChunk::end):
        (bmalloc::LargeChunk::create):
        (bmalloc::LargeChunk::get):
        (bmalloc::LargeChunk::beginTag):
        (bmalloc::LargeChunk::endTag):
        * bmalloc/Line.h: Added.
        (bmalloc::Line<Traits>::begin):
        (bmalloc::Line<Traits>::end):
        (bmalloc::Line<Traits>::concurrentRef):
        (bmalloc::Line<Traits>::deref):
        * bmalloc/MediumAllocator.h: Added.
        (bmalloc::MediumAllocator::isNull):
        (bmalloc::MediumAllocator::MediumAllocator):
        (bmalloc::MediumAllocator::line):
        (bmalloc::MediumAllocator::allocate):
        (bmalloc::MediumAllocator::derefCount):
        (bmalloc::MediumAllocator::refill):
        * bmalloc/MediumChunk.h: Added.
        * bmalloc/MediumLine.h: Added.
        * bmalloc/MediumPage.h: Added.
        * bmalloc/MediumTraits.h: Added.
        * bmalloc/Mutex.cpp: Added.
        (bmalloc::Mutex::lockSlowCase):
        * bmalloc/Mutex.h: Added.
        (bmalloc::Mutex::Mutex):
        (bmalloc::Mutex::try_lock):
        (bmalloc::Mutex::lock):
        (bmalloc::Mutex::unlock):
        * bmalloc/ObjectType.cpp: Added.
        (bmalloc::objectType):
        * bmalloc/ObjectType.h: Added.
        (bmalloc::isSmallOrMedium):
        (bmalloc::isSmall):
        * bmalloc/Page.h: Added.
        (bmalloc::Page<Traits>::ref):
        (bmalloc::Page<Traits>::deref):
        (bmalloc::Page<Traits>::refCount):
        * bmalloc/PerProcess.h: Added.
        (bmalloc::PerProcess::mutex):
        (bmalloc::PerProcess<T>::getFastCase):
        (bmalloc::PerProcess<T>::get):
        (bmalloc::PerProcess<T>::getSlowCase):
        * bmalloc/PerThread.h: Added.
        (bmalloc::PerThreadStorage<Cache>::get):
        (bmalloc::PerThreadStorage<Cache>::init):
        (bmalloc::PerThreadStorage::get):
        (bmalloc::PerThreadStorage::init):
        (bmalloc::PerThread<T>::getFastCase):
        (bmalloc::PerThread<T>::get):
        (bmalloc::PerThread<T>::destructor):
        (bmalloc::PerThread<T>::getSlowCase):
        * bmalloc/Range.h: Added.
        (bmalloc::Range::Range):
        (bmalloc::Range::begin):
        (bmalloc::Range::end):
        (bmalloc::Range::size):
        (bmalloc::Range::operator!):
        (bmalloc::Range::operator<):
        * bmalloc/SegregatedFreeList.cpp: Added.
        (bmalloc::SegregatedFreeList::SegregatedFreeList):
        (bmalloc::SegregatedFreeList::insert):
        (bmalloc::SegregatedFreeList::takeGreedy):
        (bmalloc::SegregatedFreeList::take):
        * bmalloc/SegregatedFreeList.h: Added.
        * bmalloc/Sizes.h: Added.
        * bmalloc/SmallAllocator.h: Added.
        (bmalloc::SmallAllocator::isNull):
        (bmalloc::SmallAllocator::canAllocate):
        (bmalloc::SmallAllocator::SmallAllocator):
        (bmalloc::SmallAllocator::line):
        (bmalloc::SmallAllocator::allocate):
        (bmalloc::SmallAllocator::objectCount):
        (bmalloc::SmallAllocator::derefCount):
        (bmalloc::SmallAllocator::refill):
        * bmalloc/SmallChunk.h: Added.
        * bmalloc/SmallLine.h: Added.
        * bmalloc/SmallPage.h: Added.
        * bmalloc/SmallTraits.h: Added.
        * bmalloc/Syscall.h: Added.
        * bmalloc/VMAllocate.h: Added.
        (bmalloc::vmSize):
        (bmalloc::vmValidate):
        (bmalloc::vmAllocate):
        (bmalloc::vmDeallocate):
        (bmalloc::vmDeallocatePhysicalPages):
        (bmalloc::vmAllocatePhysicalPages):
        (bmalloc::vmDeallocatePhysicalPagesSloppy):
        (bmalloc::vmAllocatePhysicalPagesSloppy):
        * bmalloc/VMHeap.cpp: Added.
        (bmalloc::VMHeap::VMHeap):
        (bmalloc::VMHeap::allocateSmallChunk):
        (bmalloc::VMHeap::allocateMediumChunk):
        (bmalloc::VMHeap::allocateLargeChunk):
        * bmalloc/VMHeap.h: Added.
        (bmalloc::VMHeap::allocateSmallPage):
        (bmalloc::VMHeap::allocateMediumPage):
        (bmalloc::VMHeap::allocateLargeRange):
        (bmalloc::VMHeap::deallocateSmallPage):
        (bmalloc::VMHeap::deallocateMediumPage):
        (bmalloc::VMHeap::deallocateLargeRange):
        * bmalloc/Vector.h: Added.
        (bmalloc::Vector::begin):
        (bmalloc::Vector::end):
        (bmalloc::Vector::size):
        (bmalloc::Vector::capacity):
        (bmalloc::Vector::last):
        (bmalloc::Vector::pop):
        (bmalloc::Vector<T>::Vector):
        (bmalloc::Vector<T>::~Vector):
        (bmalloc::Vector<T>::operator):
        (bmalloc::Vector<T>::push):
        (bmalloc::Vector<T>::pop):
        (bmalloc::Vector<T>::shrink):
        (bmalloc::Vector<T>::reallocateBuffer):
        (bmalloc::Vector<T>::shrinkCapacity):
        (bmalloc::Vector<T>::growCapacity):
        * bmalloc/XLargeChunk.h: Added.
        (bmalloc::XLargeChunk::get):
        (bmalloc::XLargeChunk::begin):
        (bmalloc::XLargeChunk::XLargeChunk):
        (bmalloc::XLargeChunk::create):
        (bmalloc::XLargeChunk::destroy):
        (bmalloc::XLargeChunk::range):
        (bmalloc::XLargeChunk::size):
        * bmalloc/bmalloc.h: Added.
        (bmalloc::api::malloc):
        (bmalloc::api::free):
        (bmalloc::api::realloc):
        * bmalloc/mbmalloc.cpp: Added.

