[Linux] Port MallocBench
[WebKit-https.git] / Source / bmalloc / ChangeLog
index 9eca8f3..ad0ac34 100644 (file)
+2017-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        [Linux] Port MallocBench
+        https://bugs.webkit.org/show_bug.cgi?id=177856
+
+        Reviewed by Filip Pizlo.
+
+        * CMakeLists.txt:
+
+2017-10-04  Filip Pizlo  <fpizlo@apple.com>
+
+        bmalloc mutex should be adaptive
+        https://bugs.webkit.org/show_bug.cgi?id=177839
+
+        Reviewed by Michael Saboff.
+        
+        This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
+        copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
+        anything other than malloc.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::compareExchangeWeak):
+        (bmalloc::compareExchangeStrong):
+        * bmalloc/PerThread.h:
+        * bmalloc/StaticMutex.cpp:
+        (bmalloc::StaticMutex::lockSlow):
+        (bmalloc::StaticMutex::unlockSlow):
+        (bmalloc::StaticMutex::lockSlowCase): Deleted.
+        * bmalloc/StaticMutex.h:
+        (bmalloc::StaticMutex::try_lock):
+        (bmalloc::StaticMutex::isLocked const):
+        (bmalloc::StaticMutex::init):
+        (bmalloc::StaticMutex::tryLock):
+        (bmalloc::StaticMutex::lock):
+        (bmalloc::StaticMutex::unlock):
+        (bmalloc::sleep): Deleted.
+        (bmalloc::waitUntilFalse): Deleted.
+
+2017-10-02  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        [Linux] Enable Gigacage in x64 Linux environment
+        https://bugs.webkit.org/show_bug.cgi?id=177745
+
+        Reviewed by Carlos Garcia Campos.
+
+        This patch enables Gigacage in x64 Linux environment.
+        Gigacage enforces a caged pointer to reference to the
+        specific memory region. This reduces the effectiveness
+        of some types of attacks setting a pointer to ArrayBuffer
+        and modifying arbitrary memory region.
+
+        * bmalloc/Gigacage.h:
+
+2017-09-29  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r222625.
+        https://bugs.webkit.org/show_bug.cgi?id=177664
+
+        causes crashes on iOS (Requested by pizlo-mbp on #webkit).
+
+        Reverted changeset:
+
+        "Enable gigacage on iOS"
+        https://bugs.webkit.org/show_bug.cgi?id=177586
+        http://trac.webkit.org/changeset/222625
+
+2017-09-28  Filip Pizlo  <fpizlo@apple.com>
+
+        Enable gigacage on iOS
+        https://bugs.webkit.org/show_bug.cgi?id=177586
+
+        Reviewed by Michael Saboff.
+        
+        This enables Gigacage on iOS using a much smaller cage size. It's not necessary for it to be so
+        small, but this is a good conservative starting point to start to exercise the code.
+
+        * bmalloc/Gigacage.h:
+
+2017-09-26  Filip Pizlo  <fpizlo@apple.com>
+
+        Put g_gigacageBasePtr into its own page and make it read-only
+        https://bugs.webkit.org/show_bug.cgi?id=174972
+
+        Reviewed by Michael Saboff.
+        
+        This puts the gigacage base pointers into their own page and makes that page read-only.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+        (Gigacage::disablePrimitiveGigacage):
+        (Gigacage::addPrimitiveDisableCallback):
+        * bmalloc/Gigacage.h:
+        (Gigacage::basePtr):
+        (Gigacage::basePtrs):
+
+2017-09-04  Adrian Perez de Castro  <aperez@igalia.com>
+
+        Unreviewed build fix for Clang with libc++
+
+        Fixes a build failure when building with Clang, -stdlib=libc++, and gigacage
+        support enabled, which resulted in "stderr" being undefined.
+
+        * bmalloc/Gigacage.cpp: Add missing <ctsdio> include to pull the definition.
+
+2017-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Large virtual memory region allocation requires MMAP_NORESERVE in Linux
+        https://bugs.webkit.org/show_bug.cgi?id=176211
+
+        Reviewed by Geoffrey Garen.
+
+        In Linux, we cannot allocate very large memory region without MMAP_NORESERVE.
+        Linux kernel needs to reserve swap area for allocated memory region. If the
+        swap area is exhausted, kernel fails to allocate the memory region with ENOMEM.
+
+        This patch adds MMAP_NORESERVE to mmap flags in Linux. By adding this flag,
+        mmap does not need to reserve swap area for the reserved memory region.
+        This allows us to reserve very large memory region that is necessary for Gigacage.
+
+        * bmalloc/BPlatform.h:
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate):
+
+2017-08-22  Filip Pizlo  <fpizlo@apple.com>
+
+        Strings need to be in some kind of gigacage
+        https://bugs.webkit.org/show_bug.cgi?id=174924
+
+        Reviewed by Oliver Hunt.
+        
+        This adds a StringGigacage.
+
+        * bmalloc/Gigacage.cpp:
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::basePtr):
+        (Gigacage::forEachKind):
+        * bmalloc/HeapKind.h:
+        (bmalloc::isGigacage):
+        (bmalloc::gigacageKind):
+        (bmalloc::heapKind):
+
+2017-08-30  Matt Lewis  <jlewis3@apple.com>
+
+        Unreviewed, rolling out r221384.
+
+        This patch caused multiple 32-bit JSC test failures.
+
+        Reverted changeset:
+
+        "Strings need to be in some kind of gigacage"
+        https://bugs.webkit.org/show_bug.cgi?id=174924
+        http://trac.webkit.org/changeset/221384
+
+2017-08-22  Filip Pizlo  <fpizlo@apple.com>
+
+        Strings need to be in some kind of gigacage
+        https://bugs.webkit.org/show_bug.cgi?id=174924
+
+        Reviewed by Oliver Hunt.
+        
+        This adds a StringGigacage.
+
+        * bmalloc/Gigacage.cpp:
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::basePtr):
+        (Gigacage::forEachKind):
+        * bmalloc/HeapKind.h:
+        (bmalloc::isGigacage):
+        (bmalloc::gigacageKind):
+        (bmalloc::heapKind):
+
+2017-08-25  Daniel Bates  <dabates@apple.com>
+
+        Demarcate code added due to lack of NSDMI for aggregates
+        https://bugs.webkit.org/show_bug.cgi?id=175990
+
+        Reviewed by Andy Estes.
+
+        * bmalloc/BPlatform.h:
+        * bmalloc/List.h: Be explicit when initializing m_node to improve readability.
+        (bmalloc::ListNode::ListNode):
+
+2017-08-23  Filip Pizlo  <fpizlo@apple.com>
+
+        Reduce Gigacage sizes
+        https://bugs.webkit.org/show_bug.cgi?id=175920
+
+        Reviewed by Mark Lam.
+
+        This introduces the ability to have different gigacage sizes for different gigacages, and uses it to reduce the size of both
+        gigacages, but to different extents: Primitive gets 32GB with a 16GB runway and JSValue gets 16GB.
+
+        This is a ~10% membuster progression on my Mac Pro.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+        * bmalloc/Gigacage.h:
+        (Gigacage::size):
+        (Gigacage::alignment):
+        (Gigacage::mask):
+        (Gigacage::runway):
+        (Gigacage::totalSize):
+        (Gigacage::caged):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::gigacageSize):
+        * bmalloc/Heap.h:
+
+2017-08-08  Filip Pizlo  <fpizlo@apple.com>
+
+        Baseline JIT should do caging
+        https://bugs.webkit.org/show_bug.cgi?id=175037
+
+        Reviewed by Mark Lam.
+        
+        This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
+        and WebProcess.
+        
+        This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
+        checks on each typed array access.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::primitiveGigacageDisabled):
+        (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
+        (Gigacage::isDisablingPrimitiveGigacageDisabled):
+        * bmalloc/Gigacage.h:
+        (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
+        (Gigacage::canPrimitiveGigacageBeDisabled):
+
+2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r220368.
+
+        This change caused WK1 tests to exit early with crashes.
+
+        Reverted changeset:
+
+        "Baseline JIT should do caging"
+        https://bugs.webkit.org/show_bug.cgi?id=175037
+        http://trac.webkit.org/changeset/220368
+
+2017-08-07  Filip Pizlo  <fpizlo@apple.com>
+
+        Baseline JIT should do caging
+        https://bugs.webkit.org/show_bug.cgi?id=175037
+
+        Reviewed by Mark Lam.
+        
+        This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
+        and WebProcess.
+        
+        This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
+        checks on each typed array access.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::primitiveGigacageDisabled):
+        (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
+        (Gigacage::isDisablingPrimitiveGigacageDisabled):
+        * bmalloc/Gigacage.h:
+        (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
+        (Gigacage::canPrimitiveGigacageBeDisabled):
+
+2017-08-06  Filip Pizlo  <fpizlo@apple.com>
+
+        Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
+        https://bugs.webkit.org/show_bug.cgi?id=174919
+
+        Reviewed by Keith Miller.
+        
+        This introduces two kinds of Gigacage, Primitive and JSValue. This translates to two kinds of
+        HeapKind, PrimitiveGigacage and JSValueGigacage.
+        
+        The new support functionality required turning Inline.h into BInline.h, and INLINE into BINLINE, and
+        NO_INLINE into BNO_INLINE.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::refillAllocatorSlowCase):
+        (bmalloc::Allocator::refillAllocator):
+        (bmalloc::Allocator::allocateLarge):
+        (bmalloc::Allocator::allocateLogSizeClass):
+        * bmalloc/AsyncTask.h:
+        * bmalloc/BInline.h: Copied from Source/bmalloc/bmalloc/Inline.h.
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        (bmalloc::Cache::deallocateSlowCaseNullCache):
+        (bmalloc::Cache::reallocateSlowCaseNullCache):
+        * bmalloc/Deallocator.cpp:
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
+        (Gigacage::ensureGigacage):
+        (Gigacage::disablePrimitiveGigacage):
+        (Gigacage::addPrimitiveDisableCallback):
+        (Gigacage::removePrimitiveDisableCallback):
+        (Gigacage::Callbacks::Callbacks): Deleted.
+        (Gigacage::disableGigacage): Deleted.
+        (Gigacage::addDisableCallback): Deleted.
+        (Gigacage::removeDisableCallback): Deleted.
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::basePtr):
+        (Gigacage::forEachKind):
+        (Gigacage::caged):
+        (Gigacage::isCaged):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::usingGigacage):
+        (bmalloc::Heap::gigacageBasePtr):
+        * bmalloc/Heap.h:
+        * bmalloc/HeapKind.h:
+        (bmalloc::isGigacage):
+        (bmalloc::gigacageKind):
+        (bmalloc::heapKind):
+        * bmalloc/Inline.h: Removed.
+        * bmalloc/Map.h:
+        * bmalloc/PerProcess.h:
+        (bmalloc::PerProcess<T>::getFastCase):
+        (bmalloc::PerProcess<T>::get):
+        (bmalloc::PerProcess<T>::getSlowCase):
+        * bmalloc/PerThread.h:
+        (bmalloc::PerThread<T>::getFastCase):
+        * bmalloc/Vector.h:
+        (bmalloc::Vector<T>::push):
+        (bmalloc::Vector<T>::shrinkCapacity):
+        (bmalloc::Vector<T>::growCapacity):
+
+2017-08-02  Filip Pizlo  <fpizlo@apple.com>
+
+        If Gigacage is disabled, bmalloc should service large aligned memory allocation requests through vmAllocate
+        https://bugs.webkit.org/show_bug.cgi?id=175085
+
+        Reviewed by Saam Barati.
+        
+        This fixes a problem where if we used gmalloc, WebAssembly memory allocations would still use
+        bmalloc's large allocator.
+        
+        We want to use the page allocator for those "large" allocations when the Gigacage is disabled.
+
+        * bmalloc/DebugHeap.cpp:
+        (bmalloc::DebugHeap::DebugHeap):
+        (bmalloc::DebugHeap::memalignLarge):
+        (bmalloc::DebugHeap::freeLarge):
+        * bmalloc/DebugHeap.h:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::deallocateLarge):
+
+2017-08-02  Filip Pizlo  <fpizlo@apple.com>
+
+        We should be OK with the gigacage being disabled on gmalloc
+        https://bugs.webkit.org/show_bug.cgi?id=175082
+
+        Reviewed by Michael Saboff.
+        
+        This adds Gigacage::shouldBeEnabled(), which returns false when we're using gmalloc or other things
+        that enable DebugHeap.
+
+        * bmalloc/Environment.cpp:
+        (bmalloc::Environment::Environment):
+        * bmalloc/Environment.h:
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+        (Gigacage::shouldBeEnabled):
+        * bmalloc/Gigacage.h:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        * bmalloc/Heap.h:
+
+2017-08-01  Filip Pizlo  <fpizlo@apple.com>
+
+        Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
+        https://bugs.webkit.org/show_bug.cgi?id=174727
+
+        Reviewed by Mark Lam.
+        
+        This adds a mechanism for managing multiple isolated heaps in bmalloc. For now, these isoheaps
+        (isolated heaps) have a very simple relationship with each other and with the rest of bmalloc:
+        
+        - You have to choose how many isoheaps you will have statically. See numHeaps in HeapKind.h.
+        
+        - Because numHeaps is static, each isoheap gets fast thread-local allocation. Basically, we have a
+          Cache for each heap kind.
+        
+        - Each isoheap gets its own Heap.
+        
+        - Each Heap gets a scavenger thread.
+        
+        - Some things, like Zone/VMHeap/Scavenger, are per-process.
+        
+        Most of the per-HeapKind functionality is handled by PerHeapKind<>.
+        
+        This approach is ideal for supporting special per-HeapKind behaviors. For now we have two heaps:
+        the Primary heap for normal malloc and the Gigacage. The gigacage is a 64GB-aligned 64GB virtual
+        region that we now use for variable-length random-access allocations. No Primary allocations will
+        go into the Gigacage.
+
+        * CMakeLists.txt:
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/AllocationKind.h: Added.
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::refillAllocatorSlowCase):
+        (bmalloc::Allocator::allocateLarge):
+        * bmalloc/Allocator.h:
+        * bmalloc/BExport.h: Added.
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::scavenge):
+        (bmalloc::Cache::Cache):
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        (bmalloc::Cache::deallocateSlowCaseNullCache):
+        (bmalloc::Cache::reallocateSlowCaseNullCache):
+        (bmalloc::Cache::operator new): Deleted.
+        (bmalloc::Cache::operator delete): Deleted.
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate):
+        (bmalloc::Cache::allocate):
+        (bmalloc::Cache::deallocate):
+        (bmalloc::Cache::reallocate):
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::Deallocator):
+        (bmalloc::Deallocator::scavenge):
+        (bmalloc::Deallocator::processObjectLog):
+        (bmalloc::Deallocator::deallocateSlowCase):
+        * bmalloc/Deallocator.h:
+        * bmalloc/Gigacage.cpp: Added.
+        (Gigacage::Callback::Callback):
+        (Gigacage::Callback::function):
+        (Gigacage::Callbacks::Callbacks):
+        (Gigacage::ensureGigacage):
+        (Gigacage::disableGigacage):
+        (Gigacage::addDisableCallback):
+        (Gigacage::removeDisableCallback):
+        * bmalloc/Gigacage.h: Added.
+        (Gigacage::caged):
+        (Gigacage::isCaged):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::usingGigacage):
+        (bmalloc::Heap::concurrentScavenge):
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::allocateLarge):
+        (bmalloc::Heap::shrinkLarge):
+        (bmalloc::Heap::deallocateLarge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::mutex):
+        (bmalloc::Heap::kind const):
+        (bmalloc::Heap::setScavengerThreadQOSClass): Deleted.
+        * bmalloc/HeapKind.h: Added.
+        * bmalloc/ObjectType.cpp:
+        (bmalloc::objectType):
+        * bmalloc/ObjectType.h:
+        * bmalloc/PerHeapKind.h: Added.
+        (bmalloc::PerHeapKindBase::PerHeapKindBase):
+        (bmalloc::PerHeapKindBase::size):
+        (bmalloc::PerHeapKindBase::at):
+        (bmalloc::PerHeapKindBase::at const):
+        (bmalloc::PerHeapKindBase::operator[]):
+        (bmalloc::PerHeapKindBase::operator[] const):
+        (bmalloc::StaticPerHeapKind::StaticPerHeapKind):
+        (bmalloc::PerHeapKind::PerHeapKind):
+        (bmalloc::PerHeapKind::~PerHeapKind):
+        * bmalloc/PerThread.h:
+        (bmalloc::PerThread<T>::destructor):
+        (bmalloc::PerThread<T>::getSlowCase):
+        (bmalloc::PerThreadStorage<Cache>::get): Deleted.
+        (bmalloc::PerThreadStorage<Cache>::init): Deleted.
+        * bmalloc/Scavenger.cpp: Added.
+        (bmalloc::Scavenger::Scavenger):
+        (bmalloc::Scavenger::scavenge):
+        * bmalloc/Scavenger.h: Added.
+        (bmalloc::Scavenger::setScavengerThreadQOSClass):
+        (bmalloc::Scavenger::requestedScavengerThreadQOSClass const):
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::VMHeap):
+        (bmalloc::VMHeap::tryAllocateLargeChunk):
+        * bmalloc/VMHeap.h:
+        * bmalloc/Zone.cpp:
+        (bmalloc::Zone::Zone):
+        * bmalloc/Zone.h:
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryMalloc):
+        (bmalloc::api::malloc):
+        (bmalloc::api::tryMemalign):
+        (bmalloc::api::memalign):
+        (bmalloc::api::realloc):
+        (bmalloc::api::tryLargeMemalignVirtual):
+        (bmalloc::api::free):
+        (bmalloc::api::freeLargeVirtual):
+        (bmalloc::api::scavengeThisThread):
+        (bmalloc::api::scavenge):
+        (bmalloc::api::isEnabled):
+        (bmalloc::api::setScavengerThreadQOSClass):
+        * bmalloc/mbmalloc.cpp:
+
+2017-08-01  Daewoong Jang  <daewoong.jang@navercorp.com>
+
+        Implement __builtin_clzl for MSVC
+        https://bugs.webkit.org/show_bug.cgi?id=174232
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::clzl):
+        (bmalloc::clzl<1>):
+        (bmalloc::__builtin_clzl):
+        * bmalloc/BPlatform.h:
+
+2017-07-31  Mark Lam  <mark.lam@apple.com>
+
+        Fixed some comment typos.
+
+        Not reviewed.
+
+        * bmalloc/PerProcess.h:
+
+2017-07-14  Filip Pizlo  <fpizlo@apple.com>
+
+        It should be easy to decide how WebKit yields
+        https://bugs.webkit.org/show_bug.cgi?id=174298
+
+        Reviewed by Saam Barati.
+        
+        Use sched_yield() explicitly.
+
+        * bmalloc/StaticMutex.cpp:
+        (bmalloc::StaticMutex::lockSlowCase):
+
+2017-07-20  Chris Dumez  <cdumez@apple.com>
+
+        Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
+        https://bugs.webkit.org/show_bug.cgi?id=174660
+
+        Reviewed by Geoffrey Garen.
+
+        Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
+        This essentially replaces a branch to figure out if the new size is less or greater than the
+        current size by an assertion.
+
+        * bmalloc/Map.h:
+        (bmalloc::Hash>::rehash):
+
+2017-07-18  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
+        https://bugs.webkit.org/show_bug.cgi?id=174631
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+
+2017-07-18  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
+        https://bugs.webkit.org/show_bug.cgi?id=174631
+
+        Reviewed by Sam Weinig.
+
+        * Configurations/Base.xcconfig:
+
+2017-07-18  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
+        https://bugs.webkit.org/show_bug.cgi?id=174631
+
+        Reviewed by Dan Bernstein.
+
+        * Configurations/Base.xcconfig:
+
+2017-07-18  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
+        https://bugs.webkit.org/show_bug.cgi?id=174631
+
+        Reviewed by Darin Adler.
+
+        * Configurations/Base.xcconfig:
+
+2017-07-12  Adrian Perez de Castro  <aperez@igalia.com>
+
+        bmalloc: Failure to build when the compiler specifically targets ARMv8-A / defines __ARM_ARCH_8A__
+        https://bugs.webkit.org/show_bug.cgi?id=174424
+
+        Reviewed by Michael Catanzaro.
+
+        * bmalloc/BPlatform.h: Also check for __ARCH_ARM_8A__ to detect ARMv8.
+
+2017-07-05  Daewoong Jang  <daewoong.jang@navercorp.com>
+
+        reinterpret_cast does not evaluate to constexpr
+        https://bugs.webkit.org/show_bug.cgi?id=173622
+
+        Reviewed by Yusuke Suzuki.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::mask):
+        (bmalloc::roundUpToMultipleOf):
+
+2017-07-03  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Add an experimental setting to build with ccache
+        https://bugs.webkit.org/show_bug.cgi?id=173875
+
+        Reviewed by Tim Horton.
+
+        * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.
+
+2017-07-01  Dan Bernstein  <mitz@apple.com>
+
+        [iOS] Remove code only needed when building for iOS 9.x
+        https://bugs.webkit.org/show_bug.cgi?id=174068
+
+        Reviewed by Tim Horton.
+
+        * bmalloc/BPlatform.h:
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmPageSizePhysical):
+
+2017-07-01  Dan Bernstein  <mitz@apple.com>
+
+        [macOS] Remove code only needed when building for OS X Yosemite
+        https://bugs.webkit.org/show_bug.cgi?id=174067
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/DebugRelease.xcconfig:
+
+2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>
+
+        Ran sort-Xcode-project-file.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+2017-06-19  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Add a per-thread line cache
+        https://bugs.webkit.org/show_bug.cgi?id=173552
+
+        Reviewed by Darin Adler.
+
+        Previously, any thread could allocate out of any page with free lines.
+        Now, the first thread to free a line in a page owns that page's free
+        lines until the whole page becomes free.
+
+        This patch is a big speedup on multi-threaded benchmarks.
+        tree_churn --parallel gets 14% faster on a 2-core (4-hyper-core) MacBook
+        Air and 2.85X faster on 12-core (24-hyper-core) Mac Pro. Other parallel
+        benchmarks show significant but smaller speedups.
+
+        Thread affinity is a great predictor of object lifetime. The per-thread
+        line cache avoids the pathology of shuffling pages between threads,
+        turning predictable lifetimes into unpredictable lifetimes, increasing
+        fragmentation. On tree_churn --parallel, the per-thread line cache
+        increases free memory found per page scanned by 2.85X.
+
+        Free line scanning in fragmented pages is pretty expensive relative to
+        other allocate / initialize / free operations. According to Instruments,
+        on tree_churn --parallel, scanning is about 10X more expensive than
+        freeing. This explains why a 2.85X improvement in scanning efficiency
+        translates into a 2.85X overall speedup on tree_churn --parallel.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::refillAllocatorSlowCase): Pass through our line
+        cache so the Heap can fill it.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::scavenge): Scavenge our line cache.
+
+        (bmalloc::Deallocator::processObjectLog): Deleted.
+
+        * bmalloc/Deallocator.h:
+        (bmalloc::Deallocator::lineCache): Added a line cache.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::deallocateLineCache): Deallocation function for thread
+        destruction.
+
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::deallocateSmallLine):
+        (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
+        (bmalloc::Heap::allocateSmallBumpRangesByObject): Consult the new per-thread line
+        cache for allocation and deallocation.
+
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::allocateSmallBumpRanges):
+        (bmalloc::Heap::derefSmallLine):
+
+        * bmalloc/List.h:
+        (bmalloc::List::remove): Remove has always been a logically static
+        operation. Declare it static now so that the Heap can remove a page from
+        a thread's line cache without holding a direct pointer to the cache.
+
+        * bmalloc/SmallPage.h:
+
+2017-06-10  Dan Bernstein  <mitz@apple.com>
+
+        Reverted r218056 because it made the IDE reindex constantly.
+
+        * Configurations/DebugRelease.xcconfig:
+
+2017-06-10  Dan Bernstein  <mitz@apple.com>
+
+        [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
+        https://bugs.webkit.org/show_bug.cgi?id=173223
+
+        Reviewed by Sam Weinig.
+
+        The rebuilds were happening due to a difference in the compiler options that the IDE and
+        xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
+        xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
+        specify an appropriate path in CLANG_INDEX_STORE_PATH.
+
+        * Configurations/DebugRelease.xcconfig:
+
+2017-06-07  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: memory APIs don't need to be heap members
+        https://bugs.webkit.org/show_bug.cgi?id=173076
+
+        Reviewed by Sam Weinig.
+
+        Asking the OS about memory use is unrelated to the state of bmalloc's
+        heap, so it's a better separation of concerns if related code is not 
+        part of the heap.
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::memoryStatus):
+        * bmalloc/AvailableMemory.h:
+        (bmalloc::MemoryStatus::MemoryStatus):
+        (bmalloc::isUnderMemoryPressure):
+        (bmalloc::memoryFootprint):
+        (bmalloc::percentAvailableMemoryInUse):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::updateMemoryInUseParameters): Deleted.
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::isUnderMemoryPressure): Deleted.
+        (bmalloc::Heap::memoryFootprint): Deleted.
+        (bmalloc::Heap::percentAvailableMemoryInUse): Deleted.
+
+2017-06-06  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        struct does not accept initializer-form if member has initializers in GCC 4.9
+        https://bugs.webkit.org/show_bug.cgi?id=172974
+
+        Reviewed by Carlos Garcia Campos.
+
+        struct cannot accept initializer-form constructor (like, `ListNode<T> t { ... }`) if
+        the member of the struct has a default initializer.
+        Here is a simple snippet.
+
+        template<typename T>
+        struct Pair {
+            T* prev { nullptr };
+            T* next { nullptr };
+        };
+
+        Pair<int> pair { nullptr, nullptr };  // compile erorr in GCC 4.9.
+
+        Instead, we define a default constructor (to invoke default initializers) and a constructor
+        to accept the above initialization.
+
+        * bmalloc/List.h:
+        (bmalloc::ListNode::ListNode):
+        (bmalloc::List::iterator::iterator):
+
+2017-06-06  Geoffrey Garen  <ggaren@apple.com>
+
+        Try to fix the GTK build.
+
+        Unreviewed.
+
+        * bmalloc/List.h:
+        (bmalloc::List::List):
+
+2017-06-05  Geoffrey Garen  <ggaren@apple.com>
+
+        Try to fix the GTK build.
+
+        Unreviewed.
+
+        * bmalloc/List.h:
+
+2017-06-02  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Small and large objects should share memory
+        https://bugs.webkit.org/show_bug.cgi?id=172880
+        <rdar://problem/31494732>
+
+        Reviewed by Sam Weinig.
+
+        This reduces our high water mark memory usage on JetStream on macOS
+        by 10%-20%. It also has the nice side effect that we can free small
+        object metadata after returning from a high water mark.
+
+        No change in throughput.
+
+        Our old algorithm allocated small object chunks and large objects in
+        segregated virtual memory and never recycled addresses between them.
+        This provided a slight security benefit because we could apply guard
+        pages between the segregated ranges and we would never reuse the same
+        virtual address for object and metadata memory.
+
+        Our new algorithm allocates small object chunks from the large object
+        allocator. This naturally recycles memory between small chunks and large
+        objects, and between small chunks of different page classes. This allows
+        us to shift memory between allocation types as a program moves between
+        different phases of allocation, and to delete small object chunk metadata
+        when a program shrinks back from a high water mark.
+
+        Two intuitions I had about memory use turned out to be backwards in
+        this context:
+
+        (1) I thought that this optimization would work because it allowed you to
+        allocate and free a 4MB object and then reuse that large allocation to
+        service small allocations. In practice, the common benefit seems to be
+        the opposite: After you allocate and free many small objects, you can
+        stitch them together to allocate a large object without growing the heap.
+
+        (2) I thought that it would be more memory-efficient to allocate
+        fine-grained pages from the large object allocator. In practice, giving
+        the large object allocator too many arbitrarily-sized ranges to manage
+        leads to fragmentation. Meanwhile, segregated fit is a powerful memory
+        optimization. So, it's best to return small object memory to the large
+        allocator only when a whole small object chunk is free.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::Chunk::ref):
+        (bmalloc::Chunk::deref):
+        (bmalloc::Chunk::refCount):
+        (bmalloc::Chunk::freePages): We keep a free list per chunk and refcount
+        each chunk so we can notice when a chunk becomes empty, and return it
+        to the large allocator.
+
+        (bmalloc::forEachPage): A new helper function for iterating the pages
+        in a Chunk.
+
+        (bmalloc::Chunk::Chunk): Use forEachPage instead of manual iteration.
+        Use { } initialization because we don't get zero-initialized by the OS
+        anymore.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::concurrentScavenge):
+        (bmalloc::Heap::scavenge): Don't bother unlocking while scavenging. I
+        wasn't able to show it to be a consistent speedup. A more promising
+        approach, if we find a motivating example, is for the scavenger to give
+        up and return early if any other client is waiting on the lock.
+
+        (bmalloc::Heap::allocateSmallChunk): New helper function for allocating
+        a small chunk. It allocates through the large allocator to facilitate
+        sharing. We still allocate a chunk at a time instead of a page at a time.
+        Surprisingly, more precise page-at-a-time allocation is worse for memory
+        use because of fragmentation. Segregated fit is a powerful optimization.
+
+        (bmalloc::Heap::deallocateSmallChunk): New helper function for deallocating
+        a small chunk.
+
+        (bmalloc::Heap::allocateSmallPage): Updated for new APIs.
+
+        (bmalloc::Heap::deallocateSmallLine):  Updated for new APIs. Note that
+        we cache one free chunk per page class. This avoids churn in the large
+        allocator when you free(malloc(X)).
+
+        (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
+        (bmalloc::Heap::allocateSmallBumpRangesByObject):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::scavengeSmallPages): Deleted.
+        (bmalloc::Heap::scavengeLargeObjects): Deleted.
+        * bmalloc/Heap.h:
+
+        * bmalloc/LargeMap.h:
+        (bmalloc::LargeMap::begin):
+        (bmalloc::LargeMap::end): Added iteration helpers for scavenging.
+
+        * bmalloc/LargeRange.h:
+        (bmalloc::LargeRange::physicalSize): Added a comment about something
+        that I confused myself about in this patch.
+
+        * bmalloc/List.h:
+        (bmalloc::List::iterator::operator*):
+        (bmalloc::List::iterator::operator->):
+        (bmalloc::List::iterator::operator!=):
+        (bmalloc::List::iterator::operator++):
+        (bmalloc::List::begin):
+        (bmalloc::List::end):
+        (bmalloc::List::pushFront):
+        (bmalloc::List::remove):
+        (bmalloc::ListNode::ListNode): Deleted. Added iteration helpers for
+        scavenging. Changed the default state of a Node to null pointers instead
+        of self pointers to distinguish the null node from the empty node for
+        easier debugging.
+
+        * bmalloc/Sizes.h: Changed the chunk size to 1MB to increase the chances
+        of a chunk becoming free and recyclable.
+
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::hasPhysicalPages):
+        (bmalloc::SmallPage::setHasPhysicalPages): Track physical state by page
+        instead of implicitly by which list a page is in. It's simpler not
+        to have to move chunks and pages between physical vs virtual lists.
+
+        (bmalloc::SmallPage::SmallPage): Deleted.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::tryAllocateLargeChunk):
+        (bmalloc::VMHeap::allocateSmallChunk): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::allocateSmallPage): Deleted.
+        (bmalloc::VMHeap::deallocateSmallPage): Deleted. Small chunk allocation
+        just forwards to the large allocator now.
+
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::scavenge):
+
+2017-05-28  Dan Bernstein  <mitz@apple.com>
+
+        [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
+        https://bugs.webkit.org/show_bug.cgi?id=172691
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
+
+2017-05-25  Geoffrey Garen  <ggaren@apple.com> and Michael Saboff  <msaboff@apple.com>
+
+        bmalloc: scavenger runs too much on JetStream
+        https://bugs.webkit.org/show_bug.cgi?id=172373
+
+        Reviewed by Geoffrey Garen.
+
+        Instruments says that JetStream on macOS spends about 3% of its time in
+        madvise.
+
+        In <https://bugs.webkit.org/show_bug.cgi?id=160098>, Ben saw some
+        evidence that madvise was the reason that switching to bmalloc for
+        DFG::Node allocations was a slowdown the first time around.
+
+        In <https://bugs.webkit.org/show_bug.cgi?id=172124>, Michael saw that
+        scavening policy can affect JetStream.
+
+        Intuitively, it seems wrong for the heap to idle shrink during hardcore
+        benchmarking.
+
+        The strategy here is to back off in response to any heap growth event,
+        and to wait 2s instead of 0.5s for heap growth to take place -- but we
+        scavenge immediately in response to critical memory pressure, to avoid
+        jetsam.
+
+        One hole in this strategy is that a workload with a perfectly
+        unfragmented heap that allocates and deallocates ~16kB every 2s will
+        never shrink its heap. This doesn't seem to be a problem in practice.
+
+        This looks like a 2% - 4% speedup on JetStream on Mac Pro and MacBook Air.
+
+        * bmalloc/AsyncTask.h:
+        (bmalloc::AsyncTask::willRun):
+        (bmalloc::AsyncTask::willRunSoon):
+        (bmalloc::Function>::AsyncTask):
+        (bmalloc::Function>::run):
+        (bmalloc::Function>::runSoon):
+        (bmalloc::Function>::threadRunLoop):
+        (bmalloc::Function>::runSlowCase): Deleted. Added a "run soon" state
+        so that execution delay is modeled directly instead of implicitly
+        through sleep events. This enables the Heap to issue a "run now" event
+        at any moment in response ot memory pressure.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap): Don't call into our own API -- that's a layering
+        violation.
+
+        (bmalloc::Heap::updateMemoryInUseParameters): No need for
+        m_scavengeSleepDuration anymore.
+
+        (bmalloc::Heap::concurrentScavenge): Added a back-off policy when the
+        heap is growing.
+        (bmalloc::Heap::scavenge):
+
+        (bmalloc::Heap::scavengeSmallPages):
+        (bmalloc::Heap::scavengeLargeObjects): Don't try to give up in the middle
+        of a scavenge event. Our new backoff policy supplants that design. Also,
+        it's easier to profile and understand scavenging behavior if it always
+        runs to completion once started.
+
+        (bmalloc::Heap::scheduleScavenger):
+        (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Added a
+        synchronous amortized check for memory pressure. This check has the
+        benefit that it runs immediately during high rates of heap activity,
+        so we can detect memory pressure right away and wake the scavenger
+        instead of waiting for the scavenger to wake up.
+
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::deallocateSmallLine):
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::shrinkLarge):
+        (bmalloc::Heap::deallocateLarge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::isUnderMemoryPressure):
+        * bmalloc/Sizes.h:
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::deallocateSmallPage):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::scavenge): Updated for API changes above.
+
+2017-05-17  Michael Saboff  <msaboff@apple.com>
+
+        [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info (172186)
+        https://bugs.webkit.org/show_bug.cgi?id=172186
+
+        Reviewed by Geoffrey Garen.
+
+        The calls memoryFootprint() and percentAvailableMemoryInUse() now make a system call to get
+        the current memory footprint value.
+
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::memoryFootprint):
+        (bmalloc::Heap::percentAvailableMemoryInUse):
+
+2017-05-16  Michael Saboff  <msaboff@apple.com>
+
+        REGRESSION(r216763): JetStream is 1% slower on Mac
+        https://bugs.webkit.org/show_bug.cgi?id=172124
+
+        Reviewed by Filip Pizlo.
+
+        It appears that changing maxScavengeSleepDuration from 512 to 250ms in r216763 is
+        responsible for the regression.
+
+        * bmalloc/Sizes.h:
+
+2017-05-15  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Bump the size of the deallocator log to 512
+        https://bugs.webkit.org/show_bug.cgi?id=172143
+
+        Reviewed by Michael Saboff.
+
+        This is a speedup on parallel workloads for machines with lots of CPUs.
+
+        * bmalloc/Sizes.h:
+
+2017-05-12  Michael Saboff  <msaboff@apple.com>
+
+        [iOS] Use memory footprint to dynamically adjust behavior of allocators
+        https://bugs.webkit.org/show_bug.cgi?id=171944
+
+        Reviewed by Filip Pizlo.
+
+        This change is iOS only.
+
+        After the scavenger thread completes scavenging, it asks the OS for how much total memory the
+        process is using.  This information is used to update the sleep delay for the scanvenger thread,
+        as well as to provide memory in use data for other parts of the system.
+
+        The scavenger sleep time is calculated using the following quadradic equation.
+
+            scavengerSleep = 1.2*percentFreeMemory^2 - percentFreeMemory + 2
+
+        Where percentFreeMemory is between 0 and 100.  The result is constrained to the values 2 and 250.
+
+        This equation empirically works out to providing a 2ms sleep time when we have less than 10%
+        memory available, 30ms when 20% is available and 250ms when 50% or more is available.  In testing,
+        this exponentially agressive scavenging delay by itself reduced memory usage and made it much
+        more deterministic when used without the corresponding change in the JSC Heap.
+
+        Changed the scavenger thread to use the User Initiated QOS priority to ensure it doesn't
+        get starved.
+
+        Moved the non-Windows functionality of WTF::RAMSize() to new files AvailableMemory.{cpp,h}
+        and implemented in the function availableMemory().  That functions limits the value returned
+        on iOS to a maximum of 840MB as that is the jetsam soft memory limit.
+        Added a new API availableMemory() so that WTF::RAMSize() will use this value.
+
+        * CMakeLists.txt:
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/BPlatform.h:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::updateMemoryInUseParameters):
+        (bmalloc::Heap::concurrentScavenge):
+        (bmalloc::Heap::scavenge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::memoryFootprint):
+        (bmalloc::Heap::percentAvailableMemoryInUse):
+        * bmalloc/Sizes.h:
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::availableMemory):
+        (bmalloc::api::memoryFootprint):
+        (bmalloc::api::percentAvailableMemoryInUse):
+        * bmalloc/AvailableMemory.cpp: Added.
+        (bmalloc::computeAvailableMemory):
+        (bmalloc::availableMemory):
+        * bmalloc/AvailableMemory.h: Added.
+
+2017-05-05  Joseph Pecoraro  <pecoraro@apple.com>
+
+        Leaks always reports "WebKit Malloc Memory Pressure Handler" dispatch_queue/source as leaking
+        https://bugs.webkit.org/show_bug.cgi?id=171532
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        * bmalloc/Heap.h:
+        Store the dispatch_source_t in a member to avoid a false positive leak.
+
+2017-04-27  Michael Saboff  <msaboff@apple.com>
+
+        bmalloc scavenger should know what page classes are allocating
+        https://bugs.webkit.org/show_bug.cgi?id=171384
+
+        Reviewed by Geoffrey Garen.
+
+        This change replaces m_isAllocatingPages with a per page class flag to track which page
+        classes are currently allocating.  When scavenging, we skip page classes that are actively
+        allocating and come back to them on a subsequent pass.  This reduces the amount of time it
+        takes for scavenger to free up pages as well as the total time it takes to handle all
+        page classes.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::concurrentScavenge):
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::scavengeSmallPages):
+        (bmalloc::Heap::scavengeLargeObjects):
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::deallocateLarge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::takeRequestedScavengerThreadQOSClass): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::deallocateSmallPage):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::scavenge):
+
+2017-04-25  Michael Saboff  <msaboff@apple.com>
+
+        Call bmalloc scavenger first when handling a memory pressure event
+        https://bugs.webkit.org/show_bug.cgi?id=171289
+
+        Reviewed by Geoffrey Garen.
+
+        Registered a critical memory pressure handler.  We add this handler in addition to the
+        call to release bmalloc memory in the WebCore releaseMemory handler for the case of
+        JSC API users that don't use WebCore.  When both handlers are in the process, it is
+        basically a race.  One will win, but the loser won't do any more work, so it is harmless.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+
+2017-04-14  Mark Lam  <mark.lam@apple.com>
+
+        Update architectures in xcconfig files.
+        https://bugs.webkit.org/show_bug.cgi?id=170867
+        <rdar://problem/31628104>
+
+        Reviewed by Joseph Pecoraro.
+
+        * Configurations/Base.xcconfig:
+
+2017-04-12  Dan Bernstein  <mitz@apple.com>
+
+        [Mac] Future-proof .xcconfig files
+        https://bugs.webkit.org/show_bug.cgi?id=170802
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/DebugRelease.xcconfig:
+
+2017-02-03  Ting-Wei Lan  <lantw44@gmail.com>
+
+        Include cstdlib before using ::malloc and posix_memalign
+        https://bugs.webkit.org/show_bug.cgi?id=167800
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc/DebugHeap.cpp:
+
+2017-02-01  Andreas Kling  <akling@apple.com>
+
+        Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
+        <https://webkit.org/b/167387>
+        <rdar://problem/29711409>
+
+        Reviewed by Antti Koivisto.
+
+        Support changing the QoS level of the scavenger thread asynchronously through
+        a request variable. This is not the most elegant thing in the world, but since
+        threads are only allowed to change their own QoS class, our options are limited.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::concurrentScavenge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
+        (bmalloc::Heap::setScavengerThreadQOSClass):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::setScavengerThreadQOSClass):
+
+2017-01-13  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Use a separate zone when using system malloc
+        https://bugs.webkit.org/show_bug.cgi?id=167014
+
+        Reviewed by Filip Pizlo.
+
+        Harris asked for this so he could separate Safari and WebKit memory use
+        when doing memory analysis.
+
+        This patch adds an explicit DebugHeap class that contains all our
+        code for specialized allocation with debugging.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::allocateSlowCase):
+        * bmalloc/Allocator.h: Forward to DebugHeap instead of inlining all the
+        code. This is required for our new interface, and it is also a nice
+        simplification that moves some not-very-important code out of the way.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::Deallocator):
+        (bmalloc::Deallocator::scavenge):
+        (bmalloc::Deallocator::deallocateSlowCase):
+        * bmalloc/Deallocator.h: Ditto.
+
+        * bmalloc/DebugHeap.cpp: Added.
+        (bmalloc::DebugHeap::DebugHeap):
+        (bmalloc::DebugHeap::malloc):
+        (bmalloc::DebugHeap::memalign):
+        (bmalloc::DebugHeap::realloc):
+        (bmalloc::DebugHeap::free):
+        * bmalloc/DebugHeap.h: Added. New class for overriding normal heap
+        behavior. Right now, it just adds a malloc zone and then forwards to
+        system malloc -- but we can add lots more kinds of debug heaps in the
+        future if we find them useful.
+
+        * bmalloc/Environment.cpp:
+        (bmalloc::Environment::Environment):
+        (bmalloc::Environment::computeIsDebugHeapEnabled):
+        (bmalloc::Environment::computeIsBmallocEnabled): Deleted.
+        * bmalloc/Environment.h:
+        (bmalloc::Environment::isDebugHeapEnabled):
+        (bmalloc::Environment::isBmallocEnabled): Deleted. Renamed everything to
+        reflect our new use of DebugHeap.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::debugHeap): Updated to use DebugHeap.
+        (bmalloc::Heap::environment): Deleted. 
+
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::isEnabled): Updated to use DebugHeap.
+
+2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
+
+        Sort Xcode project files
+        https://bugs.webkit.org/show_bug.cgi?id=165937
+
+        Reviewed by Simon Fraser.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+2016-12-08  David Kilzer  <ddkilzer@apple.com>
+
+        Always check the return value of pthread_key_create()
+        <https://webkit.org/b/165274>
+
+        Reviewed by Darin Adler.
+
+        * bmalloc/PerThread.h:
+        (bmalloc::PerThreadStorage::init): Call BCRASH() if
+        pthread_key_create() returns an error.  The error code will be
+        stored in a register available in a crash log, so no need to log
+        the value explicitly.
+
+2016-12-06  Alexey Proskuryakov  <ap@apple.com>
+
+        Correct SDKROOT values in xcconfig files
+        https://bugs.webkit.org/show_bug.cgi?id=165487
+        rdar://problem/29539209
+
+        Reviewed by Dan Bernstein.
+
+        Fix suggested by Dan Bernstein.
+
+        * Configurations/DebugRelease.xcconfig:
+
+2016-11-29  Andy Estes  <aestes@apple.com>
+
+        [Cocoa] Enable two clang warnings recommended by Xcode
+        https://bugs.webkit.org/show_bug.cgi?id=164498
+
+        Reviewed by Mark Lam.
+
+        * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
+
+2016-11-10  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc threads should have a non-default QoS
+        https://bugs.webkit.org/show_bug.cgi?id=164612
+
+        Reviewed by Filip Pizlo.
+
+        * bmalloc/AsyncTask.h:
+        (bmalloc::Function>::threadEntryPoint): Request user-interactive quality
+        of service because user-interactive tasks use malloc.
+
+2016-10-20  Mark Lam  <mark.lam@apple.com>
+
+        bmalloc api should crash on failure to allocate when !isBmallocEnabled.
+        https://bugs.webkit.org/show_bug.cgi?id=163766
+
+        Reviewed by Keith Miller and Filip Pizlo.
+
+        We want to crash in bmalloc on failure to allocate even when !isBmallocEnabled.
+        This is so that failures to allocate memory will manifest as crashes with a
+        unique signature (i.e. as a SIGTRAP on release builds, or as a write to illegal
+        address 0xbbadbeef on debug builds) and the crash will manifest inside bmalloc.
+        This distinguishes allocation failures from other crashing bugs that manifest as
+        SIGSEGVs due to random pointer dereferences in the clients of bmalloc.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::allocateSlowCase):
+
+2016-09-26  Yoshiaki Jitsukawa  <Yoshiaki.Jitsukawa@sony.com>
+
+        Avoid implicit conversion from iterator to pointer
+        https://bugs.webkit.org/show_bug.cgi?id=162482
+
+        Reviewed by Geoffrey Garen.
+
+        Not every STL supporting such conversion, we should get a pointer explicitly.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::Chunk::lines):
+        (bmalloc::Chunk::pages):
+        * bmalloc/FixedVector.h:
+        (bmalloc::FixedVector::begin):
+
+2016-08-31  Filip Pizlo  <fpizlo@apple.com>
+
+        Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
+        https://bugs.webkit.org/show_bug.cgi?id=160125
+
+        Reviewed by Geoffrey Garen and Keith Miller.
+        
+        I needed to tryMemalign, so I added such a thing.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryMemalign):
+
+2016-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Unreviewed, build fix for GCC ports
+
+        std::forward is declared in <utility> header.
+
+        * bmalloc/ScopeExit.h:
+
+2016-08-30  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: speed up the lock slow path
+        https://bugs.webkit.org/show_bug.cgi?id=161058
+
+        Unreviewed roll-in - with regression fixed.
+
+        Revert to using yield() instead of swtch() because very low priority
+        background tasks can cause priority inversion and deadlock. In the
+        network process, that happened with com.apple.WebKit.Cache.Storage.serialBackground.
+
+        Still a big speedup on MallocBench.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/ScopeExit.h: Added.
+        (bmalloc::ScopeExit::ScopeExit):
+        (bmalloc::ScopeExit::~ScopeExit):
+        (bmalloc::makeScopeExit):
+        * bmalloc/StaticMutex.cpp:
+        (bmalloc::StaticMutex::lockSlowCase):
+        * bmalloc/StaticMutex.h:
+        (bmalloc::StaticMutex::init):
+
+2016-08-26  Geoffrey Garen  <ggaren@apple.com>
+
+        Unreviewed build fix.
+
+        Fix the CMake build.
+
+        * CMakeLists.txt:
+
+2016-08-26  Geoffrey Garen  <ggaren@apple.com>
+
+        Renamed XLarge* => Large*
+        https://bugs.webkit.org/show_bug.cgi?id=161261
+
+        Reviewed by Andreas Kling.
+
+        XLarge is not a thing anymore: We just have Small and Large.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::shrinkLarge):
+        (bmalloc::Heap::deallocateLarge):
+        * bmalloc/Heap.h:
+        * bmalloc/LargeMap.cpp: Copied from Source/bmalloc/bmalloc/XLargeMap.cpp.
+        (bmalloc::LargeMap::remove):
+        (bmalloc::LargeMap::add):
+        (bmalloc::XLargeMap::remove): Deleted.
+        (bmalloc::XLargeMap::add): Deleted.
+        * bmalloc/LargeMap.h: Copied from Source/bmalloc/bmalloc/XLargeMap.h.
+        (bmalloc::LargeMap::ranges):
+        (bmalloc::XLargeMap::ranges): Deleted.
+        * bmalloc/LargeRange.h: Copied from Source/bmalloc/bmalloc/XLargeRange.h.
+        (bmalloc::LargeRange::LargeRange):
+        (bmalloc::LargeRange::operator<):
+        (bmalloc::canMerge):
+        (bmalloc::merge):
+        (bmalloc::LargeRange::split):
+        (bmalloc::XLargeRange::XLargeRange): Deleted.
+        (bmalloc::XLargeRange::operator<): Deleted.
+        (bmalloc::XLargeRange::split): Deleted.
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::tryAllocateLargeChunk):
+        * bmalloc/VMHeap.h:
+        * bmalloc/XLargeMap.cpp: Removed.
+        * bmalloc/XLargeMap.h: Removed.
+        * bmalloc/XLargeRange.h: Removed.
+
+2016-08-26  Gavin Barraclough  <barraclough@apple.com>
+
+        bmalloc: speed up the lock slow path
+        https://bugs.webkit.org/show_bug.cgi?id=161058
+
+        Unreviewed rollout - this caused regressions <rdar://problem/28026089>.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/ScopeExit.h: Removed.
+        * bmalloc/StaticMutex.cpp:
+        (bmalloc::StaticMutex::lockSlowCase):
+        * bmalloc/StaticMutex.h:
+        (bmalloc::StaticMutex::init):
+        * bmalloc/ThreadSwitch.h: Removed.
+
+2016-08-24  Andreas Kling  <akling@apple.com>
+
+        Add bmalloc::api::isEnabled().
+        <https://webkit.org/b/160534>
+
+        Reviewed by Joseph Pecoraro.
+
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::isEnabled):
+
+2016-08-24  Filip Pizlo  <fpizlo@apple.com>
+
+        Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::tryAllocate): Deleted.
+        (bmalloc::Allocator::allocateImpl): Deleted.
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate): Deleted.
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryMemalign): Deleted.
+
+2016-08-12  Filip Pizlo  <fpizlo@apple.com>
+
+        Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
+        https://bugs.webkit.org/show_bug.cgi?id=160125
+
+        Reviewed by Geoffrey Garen.
+        
+        I needed to tryMemalign, so I added such a thing.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocate):
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::allocate):
+        (bmalloc::Cache::tryAllocate):
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::malloc):
+        (bmalloc::api::tryMemalign):
+        (bmalloc::api::memalign):
+
+2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Unreviewed, build fix on GCC environment
+        https://bugs.webkit.org/show_bug.cgi?id=161058
+
+        std::forward is declared in <utility> header.
+
+        * bmalloc/ScopeExit.h:
+
+2016-08-22  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: speed up the lock slow path
+        https://bugs.webkit.org/show_bug.cgi?id=161058
+
+        Reviewed by Filip Pizlo.
+
+        It is generally accepted practice that a lock should yield instead of
+        spinning when a lock acquisition fails, to avoid wasting CPU and power.
+
+        There are two problems with this generally accepted practice:
+
+        (1) It's a fallacy that yielding is free. In reality, yielding itself
+        consumes CPU and power -- by performing a syscall, running the OS
+        scheduler, and possibly performing a context switch. (Instruments
+        traces of MallocBench show the cost of yielding.) Therefore, spinning a
+        little to avoid yielding can actually *save* CPU and power.
+
+        (2) std::this_thread_yield() on Darwin is way too aggressive: It not only
+        yields but also depresses your priority to absolute zero for 10ms. A
+        recent PLT trace showed a few spots where the main thread just gave up
+        on loading and rendering a page for 10ms so an unimportant background
+        task could run.
+
+        To correct these problems, this patch adds a little bit of spinning to
+        the bmalloc lock slow path.
+
+        Below are performance results on various CPUs.
+
+        Mac Pro (12 hyperthreaded cores = 24 threads):
+
+                                                            Baseline                       Patch                           Δ
+            Execution Time:
+                message_one                                    173ms                       173ms                            
+                message_many                                   953ms                       927ms              ^ 1.03x faster
+                churn --parallel                                60ms                        41ms              ^ 1.46x faster
+                list_allocate --parallel                       224ms                       143ms              ^ 1.57x faster
+                tree_allocate --parallel                     1,190ms                       758ms              ^ 1.57x faster
+                tree_churn --parallel                        1,517ms                       906ms              ^ 1.67x faster
+                facebook --parallel                          6,519ms                     4,580ms              ^ 1.42x faster
+                reddit --parallel                            5,097ms                     3,411ms              ^ 1.49x faster
+                flickr --parallel                            4,903ms                     3,501ms               ^ 1.4x faster
+                theverge --parallel                          6,641ms                     4,505ms              ^ 1.47x faster
+
+                <geometric mean>                             1,158ms                       832ms              ^ 1.39x faster
+                <arithmetic mean>                            2,728ms                     1,895ms              ^ 1.44x faster
+                <harmonic mean>                                332ms                       240ms              ^ 1.38x faster
+
+        MacBook Air (2 hyperthreaded cores = 4 threads):
+
+                                                            Baseline                       Patch                           Δ
+            Execution Time:
+                message_one                                    911ms                       907ms               ^ 1.0x faster
+                message_many                                   515ms                       513ms               ^ 1.0x faster
+                churn --parallel                               132ms                       134ms              ! 1.02x slower
+                list_allocate --parallel                       104ms                       102ms              ^ 1.02x faster
+                tree_allocate --parallel                       117ms                       111ms              ^ 1.05x faster
+                tree_churn --parallel                          154ms                       151ms              ^ 1.02x faster
+                facebook --parallel                            719ms                       687ms              ^ 1.05x faster
+                reddit --parallel                              382ms                       341ms              ^ 1.12x faster
+                flickr --parallel                              372ms                       345ms              ^ 1.08x faster
+                theverge --parallel                            489ms                       444ms               ^ 1.1x faster
+
+                <geometric mean>                               299ms                       287ms              ^ 1.04x faster
+                <arithmetic mean>                              390ms                       374ms              ^ 1.04x faster
+                <harmonic mean>                                227ms                       220ms              ^ 1.03x faster
+
+        iPad (2 cores = 2 threads):
+
+            [ Doesn't run Ruby, so no pretty subtest output. ]
+
+                                                            Baseline                       Patch                           Δ
+            Execution Time:                                 174.14ms                     171.5ms              ^ 1.02x faster
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+        * bmalloc/ScopeExit.h: Added. A barebones very wimpy version of
+        WTF::ScopeExit.
+        (bmalloc::ScopeExit::ScopeExit):
+        (bmalloc::ScopeExit::~ScopeExit):
+        (bmalloc::makeScopeExit):
+
+        * bmalloc/StaticMutex.cpp:
+        (bmalloc::StaticMutex::lockSlowCase): Spin before yielding -- that's the
+        speedup. Don't spin if another CPU is already spinning. In theory, more
+        than one spinner accomplishes nothing, and I found that there's a cutoff
+        around 8 or 16 spinners that becomes performance negative on Mac Pro.
+
+        (Note: Another way to accomplish a similar result, if you don't want to
+        use a bit of state in the lock, is to spin for a random duration between
+        0 and aLot. I tested a version of WTF::WeakRandom with unsynchronized
+        static state and it worked great. But I ultimately opted for the explicit
+        bit because I thought it was clearer.)
+
+        * bmalloc/StaticMutex.h:
+        (bmalloc::StaticMutex::init): Initialize our new bit.
+
+        * bmalloc/ThreadSwitch.h: Added.
+        (bmalloc::threadSwitch): Don't call yield() on Darwin because it's too
+        aggressive. swtch() does what we want: Go run something else, without
+        any other side-effects.
+
+2016-08-03  Geoffrey Garen  <ggaren@apple.com>
+
+        [bmalloc] Merging of XLargeRanges can leak the upper range
+        https://bugs.webkit.org/show_bug.cgi?id=160403
+
+        Reviewed by Michael Saboff.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
+        Recorded physical size is a performance optimization. It is not the
+        truth. So it might be zero even if a range contains physical pages.
+
+        Instead, iterate each range in the map unconditionally.
+
+        The map can shrink when we release the lock, so we must clamp our
+        iterator each time through the loop.
+
+        The map can grow when we release the lock, but we don't care because
+        growth restarts the scavenger from the beginning.
+
+        * bmalloc/XLargeMap.cpp:
+        (bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.
+
+        * bmalloc/XLargeMap.h:
+        (bmalloc::XLargeMap::ranges): Added direct access for the sake of
+        scavengeLargeObjects. (This violates our naming conventions -- I'll do
+        a rename in a follow-up patch.)
+
+2016-07-13  Enrica Casucci  <enrica@apple.com>
+
+        Update supported platforms in xcconfig files to match the sdk names.
+        https://bugs.webkit.org/show_bug.cgi?id=159728
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+
+2016-07-11  Geoffrey Garen  <ggaren@apple.com>
+
+        Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
+        https://bugs.webkit.org/show_bug.cgi?id=159655
+
+        Reviewed by Sam Weinig.
+
+        It's not entirely clear what was happening in these crashes, but our
+        use of detach() was 100% forward-looking, so we can just remove it for
+        now.
+
+        This patch removes the ability for the scavenger owner to die before
+        the scavenger thread dies (which was unused) and also removes the
+        ability for the scavenger thread to exit (which was used, but we
+        messed up and did thread joining lazily, so we never got any benefit
+        from thread exit.)
+
+        We can add these features back when we need them, and make them work then.
+
+        * bmalloc/AsyncTask.h:
+        (bmalloc::Function>::AsyncTask): We start out in the running state now
+        because we know that starting our thread will run it.
+
+        (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
+
+        (bmalloc::Function>::runSlowCase): I removed the Exited state.
+
+        (bmalloc::Function>::threadRunLoop): I removed the Exited and
+        ExitRequested states.
+
+        * bmalloc/Heap.h:
+
+        * bmalloc/VMHeap.h:
+
+2016-06-12  David Kilzer  <ddkilzer@apple.com>
+
+        Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
+        <https://webkit.org/b/158660>
+        <rdar://problem/25652686>
+
+        Reviewed by Darin Adler.
+
+        * bmalloc/Logging.cpp: Switch to use
+        BSOFT_LINK_PRIVATE_FRAMEWORK() to link
+        CrashReporterSupport.framework.
+        * bmalloc/darwin/BSoftLinking.h:
+        (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
+        Switch to use /System/Library/PrivateFrameworks/.
+
+2016-06-11  David Kilzer  <ddkilzer@apple.com>
+
+        Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
+        <http://webkit.org/b/155992>
+
+        Reviewed by Geoff Garen.
+
+        * bmalloc/BAssert.h:
+        (BLOG_ERROR): Add method to always log error messages.
+        (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
+        logging in Debug builds.
+        * bmalloc/BPlatform.h:
+        (BPLATFORM_MAC): Add.
+        (BUSE): Add BUSE() macro.
+        (BATTRIBUTE_PRINTF): Add.
+        (BUSE_OS_LOG): Add.
+        * bmalloc/Logging.cpp:
+        (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
+        stderr.
+        * bmalloc/Logging.h:
+        (bmalloc::reportAssertionFailureWithMessage): Add declaration.
+
+2016-06-07  Pranjal Jumde  <pjumde@apple.com>
+
+        Prevents integer overflow in Vector.h
+        https://bugs.webkit.org/show_bug.cgi?id=158455
+        <rdar://problem/20235469>
+
+        Reviewed by Mark Lam.
+
+        * bmalloc/Vector.h:
+        (bmalloc::Vector<T>::reallocateBuffer):
+
+2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
+
+        [cmake] Deduplicated bmalloc/Zone.cpp handling.
+        https://bugs.webkit.org/show_bug.cgi?id=158154
+
+        Reviewed by Alex Christensen.
+
+        File bmalloc/Zone.cpp is required on Darwin irrespectively from what
+        port is being built.
+
+        Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
+        unlikely that bmalloc will ever need port-specific customizations (as
+        opposed to OS-specific customizations which should be done in
+        CMakeLists.txt).
+
+        * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
+        * PlatformGTK.cmake: Removed.
+        * PlatformMac.cmake: Removed.
+
+2016-05-22  Brady Eidson  <beidson@apple.com>
+
+        Move to C++14.
+        https://bugs.webkit.org/show_bug.cgi?id=157948
+
+        Reviewed by Michael Catanzaro.
+
+        * Configurations/Base.xcconfig:
+
+2016-05-17  Geoffrey Garen  <ggaren@apple.com>
+
+        REGRESSION: JetStream crashes on some iPhones
+        https://bugs.webkit.org/show_bug.cgi?id=157814
+
+        Reviewed by Michael Saboff.
+
+        * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
+
+        Previous justification for 64kB was:
+
+            * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
+            reasonable, since sizes between 16kB and 32kB share page sizes. I went
+            all the way up to 64kB because the GC uses 64kB blocks, and also just
+            for extra padding to ensure that large allocations are indeed rare.
+
+        It turns out that the bump to 64kB substantially increases our memory
+        high water mark on JetStream, leading to jetsam crashes. Also, there
+        doesn't seem to be a practical performance problem to putting objects in
+        the (32kB - 64kB) range in the large allocator.
+
+2016-05-16  Geoffrey Garen  <ggaren@apple.com>
+
+        REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
+        https://bugs.webkit.org/show_bug.cgi?id=157764
+
+        Reviewed by Gavin Barraclough.
+
+        We need to allow for guard pages and only report unguarded pages to the
+        leaks tool -- otherwise, it will try to remote map our guarded pages,
+        and crash.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::tryAllocateLargeChunk):
+        (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
+        a range instead of a Chunk*, and report the unguarded range.
+
+        This also fixes a separate bug -- very large allocations would not
+        fully participate in pointer scanning because they would only report 2MB
+        (chunkSize) in size. This could cause false-positive leak reports.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
+        Chunk pointers.
+
+        * bmalloc/Zone.h:
+        (bmalloc::Zone::ranges):
+        (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
+        pointers because our VM ranges have variable sizes -- both due to guard
+        pages and due to large allocations.
+
+        (bmalloc::Zone::chunks): Deleted.
+        (bmalloc::Zone::addChunk): Deleted.
+
+2016-05-10  David Kilzer  <ddkilzer@apple.com>
+
+        bmalloc should automatically disable itself when ThreadSanitizer is used
+        <https://webkit.org/b/157527>
+
+        Reviewed by Michael Catanzaro.
+
+        * bmalloc/Environment.cpp:
+        (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
+        (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
+        support for detecting ThreadSanitizer.
+        (bmalloc::Environment::computeIsBmallocEnabled): Switch from
+        isASanEnabled to isSanitizerEnabled.
+
+2016-05-03  Geoffrey Garen  <ggaren@apple.com>
+
+        Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
+        https://bugs.webkit.org/show_bug.cgi?id=157047
+
+        Reviewed by Filip Pizlo.
+
+        Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
+        (bmalloc::roundUpToMultipleOfSloppy): Deleted.
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk):
+
+2016-05-03  Geoffrey Garen  <ggaren@apple.com>
+
+        Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
+        https://bugs.webkit.org/show_bug.cgi?id=157047
+
+        Reviewed by Filip Pizlo.
+
+        The previous fix aligned the guard page sizes correctly but forgot to
+        align the guard page start address correctly.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
+        up when not working with a power of two, instead of writing out the
+        math by hand.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
+        page start address in addition to its size. Assert at the very end to
+        try to catch more bugs.
+
+2016-04-27  Geoffrey Garen  <ggaren@apple.com>
+
+        Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
+        https://bugs.webkit.org/show_bug.cgi?id=157047
+
+        Reviewed by Darin Adler.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::Chunk::Chunk):
+        (bmalloc::Chunk::get):
+        (bmalloc::Chunk::offset):
+        (bmalloc::Chunk::address):
+        (bmalloc::Object::Object):
+        (bmalloc::Object::address):
+        (bmalloc::Object::line):
+        (bmalloc::Chunk::object): Deleted.
+        (bmalloc::Object::begin): Deleted.
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallBumpRangesByObject):
+        * bmalloc/Object.h:
+        (bmalloc::Object::chunk):
+        (bmalloc::Object::offset): Renamed begin() to address() because this is
+        not an iterator.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
+        multiple because pageSize might be smaller than vmPageSize, but we
+        think the VM system requires vmPageSize-aligned values.
+
+2016-04-25  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: vm allocations should plant guard pages
+        https://bugs.webkit.org/show_bug.cgi?id=156937
+
+        Rolling back in r199936 with a fix for the memory regression.
+
+2016-04-23  Gavin Barraclough  <barraclough@apple.com>
+
+        bmalloc: vm allocations should plant guard pages
+        https://bugs.webkit.org/show_bug.cgi?id=156937
+
+        Rolling out - looks like this is memory regression.
+
+        * bmalloc/Object.h:
+        (bmalloc::Object::operator+):
+        (bmalloc::Object::operator<=):
+        (bmalloc::Object::operator-): Deleted.
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmDeallocate):
+        (bmalloc::vmRevokePermissions): Deleted.
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk):
+
+2016-04-22  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: vm allocations should plant guard pages
+        https://bugs.webkit.org/show_bug.cgi?id=156937
+
+        Reviewed by Michael Saboff.
+
+        * bmalloc/Object.h:
+        (bmalloc::Object::operator-): Added a - helper.
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmRevokePermissions): Added a helper to revoke permissions on
+        a VM region. We use this for guard pages.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::allocateSmallChunk): Add guard pages to the start and
+        end of the chunk.
+
+        Note that we don't guard large chunks becuase we need to be able to merge
+        them. Otherwise, we will run out of virtual addresses.
+
+2016-04-22  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Constify introspect function pointer table
+        https://bugs.webkit.org/show_bug.cgi?id=156936
+
+        Reviewed by Michael Saboff.
+
+        * bmalloc/Zone.cpp:
+        (bmalloc::Zone::Zone): Declaring this function pointer table const puts
+        it in the read-only section of the binary, providing a little hardening
+        against overwriting the function pointers at runtime. (We have to
+        const_cast when assigning because the API declares a pointer to non-const,
+        but we happen to know it will never try to write through that pointer.
+        This is not my favorite API.)
+
+2016-04-19  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: fix up overflow checks
+        https://bugs.webkit.org/show_bug.cgi?id=156780
+
+        Reviewed by Mark Lam.
+
+        We used to try to avoid overflow in large object math by setting a very
+        high limit on the largest large object. But that's a bit error-prone
+        since the check is far away from the math that might overflow -- and
+        we were missing some cases.
+
+        This patch removes the limit and instead checks at each math site.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocate):
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::allocateSlowCase): Remove the limit. tryAllocateLarge
+        will check for overflow for us.
+
+        * bmalloc/Chunk.h: This ASSERT was just totally wrong.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::tryAllocateLarge): Check for overflow when adding.
+
+        * bmalloc/Sizes.h:
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate): Check for overflow when adding.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::tryAllocateLargeChunk): Check for overflow when adding.
+
+2016-04-19  Geoffrey Garen  <ggaren@apple.com>
+
+        Unreviewed, try to fix an ASSERT seen on the bots.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::tryAllocateLarge): This ASSERT is supposed to be about
+        alignment, not size. Oops.
+
+2016-04-19  Geoffrey Garen  <ggaren@apple.com>
+
+        bmalloc: Merge the large and xlarge allocators
+        https://bugs.webkit.org/show_bug.cgi?id=156734
+
+        Reviewed by Andreas Kling.
+
+        This give us better defense against worst case memory usage:
+
+                                              Baseline                Patch                    Δ
+            Peak Memory:
+                nimlang                      198,132kB            181,468kB      ^ 1.09x smaller
+
+        It also eliminates inline metadata for large objects, fixing the
+        regression introduced in r198675, and more:
+
+            run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
+
+                                                                  Baseline                          Patch                              Δ
+            Memory at End:
+                big                                               10,880kB                        3,328kB                ^ 3.27x smaller
+                facebook                                           3,112kB                        2,868kB                ^ 1.09x smaller
+                fragment --parallel                                1,848kB                          760kB                ^ 2.43x smaller
+                fragment_iterate --parallel                        4,908kB                          776kB                ^ 6.32x smaller
+                big --parallel                                    48,076kB                       11,892kB                ^ 4.04x smaller
+
+        Overall memory use looks OK:
+
+            run-malloc-benchmarks --memory_warning Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
+
+                                                        Baseline                               Patch                                   Δ
+            Memory at End:
+                <arithmetic mean>                       13,992kB                            13,987kB                      ^ 1.0x smaller
+
+        Overall throughput looks OK:
+
+            run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
+
+                                                                  Baseline                          Patch                              Δ
+            Execution Time:
+                <arithmetic mean>                                    103ms                          104ms                 ! 1.01x slower
+
+        We're a bit slower on the "all-out large allocations on all cores"
+        benchmark, but I think that's an OK price to pay:
+
+                                                                  Baseline                          Patch                              Δ
+            Execution Time:
+                big --parallel                                       125ms                          136ms                 ! 1.09x slower
+
+        This patch net removes 1.5k lines of code. It turns out that large
+        allocations are rare, and free memory fragments are also rare, so the
+        combination is super rare, and a simple O(n) algorithm that ensures good
+        memory behavior is the best option.
+
+        Fun fact: In practice, the odds that the old code would save memory
+        were *worse* than the odds that it would contain a bug that wasted
+        memory. :)
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::tryAllocate): largeMax is the new xLargeMax since
+        xLargeMax is gone now.
+
+        (bmalloc::Allocator::allocate): I moved the rounding code into allocateLarge,
+        so we don't have to do it here.
+
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::allocateSlowCase):
+        (bmalloc::Allocator::allocateXLarge): Deleted. No more XLarge case.
+
+        * bmalloc/Allocator.h:
+
+        * bmalloc/BeginTag.h: Removed.
+        * bmalloc/BoundaryTag.h: Removed.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::ChunkHash::hash): Added a hash function. The best hash function
+        is a unique and monotonically increasing integer, and that's exactly what
+        we typically get from the high bits of a Chunk, since the OS allocates
+        Chunks at unique and increasing addresses.
+        (bmalloc::Chunk::boundaryTags): Deleted.
+        (bmalloc::Chunk::objectType): Deleted.
+        (bmalloc::Chunk::beginTag): Deleted.
+        (bmalloc::Chunk::endTag): Deleted.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::deallocateSlowCase): We no longer know for sure,
+        by looking at its bit pattern, whether a pointer is small or large.
+        Instead, any pointer with large alignment *might* be large, and when
+        we occasionally encounter such an object, we have to consult a hash
+        table in the Heap to find out for sure. This turns out to be just as
+        cheap in practice.
+
+        We don't deallocate large objects on the fast path anymore. We can't,
+        because large objects have out-of-line metadata now.
+
+        (bmalloc::Deallocator::deallocateXLarge): Deleted.
+
+        * bmalloc/Deallocator.h:
+        (bmalloc::Deallocator::deallocateFastCase): See deallocateSlowCase.
+
+        * bmalloc/EndTag.h: Removed.
+        * bmalloc/FreeList.cpp: Removed.
+        * bmalloc/FreeList.h: Removed.
+
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::allocateSmallPage): Be sure to track each chunk in
+        the object type map, so we can distinguish small vs large objects.
+
+        (bmalloc::Heap::deallocateSmallLine): No need to check object type
+        because we know object type now by virtue of being on the small object
+        path.
+
+        (bmalloc::Heap::splitAndAllocate): Be sure to track each chunk in
+        the object type map, so we can distinguish small vs large objects. Large
+        objects can split across chunks, so we need to add each large object's
+        chunk as it is allocated.
+
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::allocateLarge):
+        (bmalloc::Heap::isLarge):
+        (bmalloc::Heap::largeSize):
+        (bmalloc::Heap::shrinkLarge):
+        (bmalloc::Heap::deallocateLarge): Merged in existing XLarge logic for
+        large objects.
+
+        (bmalloc::Heap::scavengeXLargeObjects): Deleted.
+        (bmalloc::Heap::allocateXLarge): Deleted.
+        (bmalloc::Heap::tryAllocateXLarge): Deleted.
+        (bmalloc::Heap::xLargeSize): Deleted.
+        (bmalloc::Heap::shrinkXLarge): Deleted.
+        (bmalloc::Heap::deallocateXLarge): Deleted.
+
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::LargeObjectHash::hash):
+
+        * bmalloc/LargeObject.h: Removed.
+
+        * bmalloc/Map.h: Added.
+        (bmalloc::Map::size):
+        (bmalloc::Map::capacity):
+        (bmalloc::Map::get):
+        (bmalloc::Map::set):
+        (bmalloc::Map::remove):
+        (bmalloc::Map::shouldGrow):
+        (bmalloc::Map::shouldShrink):
+        (bmalloc::Map::find):
+        (bmalloc::Hash>::rehash): Simple hash table.
+
+        * bmalloc/Object.h:
+
+        * bmalloc/ObjectType.cpp:
+        (bmalloc::objectType):
+        * bmalloc/ObjectType.h:
+        (bmalloc::mightBeLarge): See deallocateSlowCase.
+        (bmalloc::isXLarge): Deleted.
+
+        * bmalloc/SegregatedFreeList.cpp: Removed.
+        * bmalloc/SegregatedFreeList.h: Removed.
+
+        * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
+        reasonable, since sizes between 16kB and 32kB share page sizes. I went
+        all the way up to 64kB because the GC uses 64kB blocks, and also just
+        for extra padding to ensure that large allocations are indeed rare.
+
+        * bmalloc/SortedVector.h: Removed.
+
+        * bmalloc/VMHeap.cpp:
+        (bmalloc::VMHeap::tryAllocateLargeChunk):
+        (bmalloc::VMHeap::allocateSmallChunk):
+        (bmalloc::VMHeap::VMHeap): Deleted.
+        (bmalloc::VMHeap::allocateChunk): Deleted.
+        * bmalloc/VMHeap.h:
+        (bmalloc::VMHeap::deallocateSmallPage):
+        (bmalloc::VMHeap::allocateLargeObject): Deleted.
+        (bmalloc::VMHeap::deallocateLargeObject): Deleted. Nixed all the boundary
+        tag logic since metadata is out of line now.
+
+        * bmalloc/VMState.h: Removed. Instead of an abstract state, we track
+        the precise amount of committed physical pages at the head of a VM
+        range. This allows us to merge aggressively without triggering an madvise
+        storm most of the time.
+
+        * bmalloc/Vector.h:
+        (bmalloc::Vector<T>::Vector):
+        (bmalloc::Vector<T>::insert):
+        (bmalloc::Vector<T>::remove):
+        (bmalloc::Vector<T>::resize): Filled out some missing helpers.
+
+        * bmalloc/XLargeMap.cpp:
+        (bmalloc::XLargeMap::remove):
+        (bmalloc::XLargeMap::add):
+        (bmalloc::XLargeMap::removePhysical):
+        (bmalloc::XLargeMap::takeFree): Deleted.
+        (bmalloc::XLargeMap::addFree): Deleted.
+        (bmalloc::XLargeMap::addAllocated): Deleted.
+        (bmalloc::XLargeMap::getAllocated): Deleted.
+        (bmalloc::XLargeMap::takeAllocated): Deleted.
+        (bmalloc::XLargeMap::shrinkToFit): Deleted.
+        (bmalloc::XLargeMap::takePhysical): Deleted.
+        (bmalloc::XLargeMap::addVirtual): Deleted.
+        * bmalloc/XLargeMap.h:
+        (bmalloc::XLargeMap::Allocation::operator<): Deleted. We don't track
+        object sizes anymore -- just free space. (The Heap tracks object sizes.)
+        We use plain old linear search for free space. (See intro.)
+
+        * bmalloc/XLargeRange.h:
+        (bmalloc::XLargeRange::physicalSize):
+        (bmalloc::XLargeRange::setPhysicalSize):
+        (bmalloc::merge):
+        (bmalloc::XLargeRange::split):
+        (bmalloc::XLargeRange::vmState): Deleted.
+        (bmalloc::XLargeRange::setVMState): Deleted. See VMState.h.
+
 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
 
         [CMake] Make FOLDER property INHERITED