[Linux] Port MallocBench
[WebKit-https.git] / Source / bmalloc / ChangeLog
index e38b8b1..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