[bmalloc] IsoHeap should have lower tier using shared IsoPage
[WebKit-https.git] / Source / bmalloc / ChangeLog
index c188636..0b7b18e 100644 (file)
+2019-04-19  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] IsoHeap should have lower tier using shared IsoPage
+        https://bugs.webkit.org/show_bug.cgi?id=196837
+
+        Reviewed by Filip Pizlo.
+
+        IsoHeap had a scalability problem. Once one instance is allocated from IsoHeap, it immediately allocates 16KB page for this type.
+        But some types allocate only a few instances. It leads to memory wastage, and it also limits the scalability of IsoHeap since
+        we need to carefully select classes which will be confined in IsoHeap due to this characteristics. If we can remove this wastage,
+        we can apply IsoHeap more aggressively without causing memory regression, this is the goal of this patch.
+
+        In this patch, we introduce a slow tier to IsoHeap allocation. Initially, the allocator for a certain type allocates instances from
+        a shared page with the other allocators, and eventually, the allocator tiers up and gets dedicated pages if instances of the type
+        are allocated a lot. This "shared" tier is slow, but it is totally OK because we will tier up to the normal fast tier if allocation
+        frequently happens. Even the instance is allocated from pages shared with the other allocators, we still make the allocated memory
+        region dedicated to the specific type: once a memory region is allocated for a certain type from a shared page, this region continues
+        being used only for this type even after this memory is freed. To summarize the changes:
+
+        1. We introduce "shared" tier to IsoHeap allocation. Up to N (N = 8 for now, but we can pick any power-of-two numbers up to 32) allocations,
+           we continue using this tier. We allocate memory from shared pages so that we do not waste 16KB pages for types which only allocates a few instances.
+
+        2. We eventually tier up to the "fast" tier, and eventually tier down to the "shared" tier too. We measure the period between slow paths,
+           and switch the appropriate tier for the type. Currently, we use 1 seconds as heuristics. We also count # of allocations per cycle to
+           avoid pathological slow downs.
+
+        3. Shared page mechanism must keep the characteristics of IsoHeap. Once a memory region is allocated for a certain type, this memory region
+           must be dedicated to this type. We keep track the allocated memory regions from shared pages in IsoHeapImpl, and ensure that we never
+           reuse a memory region for a different type.
+
+        This patch improves PLUM2 by 1.4% (128.4MB v.s. 126.62MB), and early Speedometer2 results are performance-neutral.
+
+        * CMakeLists.txt:
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/Algorithm.h:
+        (bmalloc::roundUpToMultipleOfImpl):
+        (bmalloc::roundUpToMultipleOf):
+        * bmalloc/BCompiler.h:
+        * bmalloc/BExport.h:
+        * bmalloc/FreeList.h:
+        * bmalloc/IsoAllocator.h:
+        * bmalloc/IsoAllocatorInlines.h:
+        (bmalloc::IsoAllocator<Config>::allocateSlow):
+        * bmalloc/IsoDeallocator.h:
+        * bmalloc/IsoDeallocatorInlines.h:
+        (bmalloc::IsoDeallocator<Config>::deallocate):
+        * bmalloc/IsoHeapImpl.h:
+        * bmalloc/IsoHeapImplInlines.h:
+        (bmalloc::IsoHeapImpl<Config>::scavenge):
+        (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
+        (bmalloc::IsoHeapImpl<Config>::updateAllocationMode):
+        (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
+        * bmalloc/IsoPage.h:
+        (bmalloc::IsoPageBase::IsoPageBase):
+        (bmalloc::IsoPageBase::isShared const):
+        * bmalloc/IsoPageInlines.h:
+        (bmalloc::IsoPage<Config>::IsoPage):
+        (bmalloc::IsoPageBase::pageFor):
+        (bmalloc::IsoPage<Config>::pageFor):
+        (bmalloc::IsoPage<Config>::free):
+        * bmalloc/IsoSharedConfig.h: Copied from Source/bmalloc/bmalloc/BExport.h.
+        * bmalloc/IsoSharedHeap.cpp: Copied from Source/bmalloc/bmalloc/BExport.h.
+        * bmalloc/IsoSharedHeap.h: Copied from Source/bmalloc/bmalloc/IsoAllocator.h.
+        (bmalloc::VariadicBumpAllocator::VariadicBumpAllocator):
+        (bmalloc::IsoSharedHeap::IsoSharedHeap):
+        * bmalloc/IsoSharedHeapInlines.h: Added.
+        (bmalloc::VariadicBumpAllocator::allocate):
+        (bmalloc::IsoSharedHeap::allocateNew):
+        (bmalloc::IsoSharedHeap::allocateSlow):
+        * bmalloc/IsoSharedPage.cpp: Copied from Source/bmalloc/bmalloc/BExport.h.
+        (bmalloc::IsoSharedPage::tryCreate):
+        * bmalloc/IsoSharedPage.h: Copied from Source/bmalloc/bmalloc/IsoDeallocator.h.
+        (bmalloc::IsoSharedPage::IsoSharedPage):
+        (bmalloc::indexSlotFor):
+        * bmalloc/IsoSharedPageInlines.h: Added.
+        (bmalloc::IsoSharedPage::free):
+        (bmalloc::IsoSharedPage::startAllocating):
+        (bmalloc::IsoSharedPage::stopAllocating):
+        * bmalloc/IsoTLS.h:
+        * bmalloc/IsoTLSInlines.h:
+        (bmalloc::IsoTLS::deallocateImpl):
+        (bmalloc::IsoTLS::deallocateFast):
+        (bmalloc::IsoTLS::deallocateSlow):
+        * bmalloc/StdLibExtras.h:
+        (bmalloc::bitwise_cast):
+        * test/testbmalloc.cpp:
+        (testIsoMallocAndFreeFast):
+        (run):
+
+2019-04-18  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        Unreviewed, fix build failure
+        https://bugs.webkit.org/show_bug.cgi?id=195938
+
+        Including <array>.
+
+        * bmalloc/AvailableMemory.cpp:
+
+2019-04-15  Yoshiaki Jitsukawa  <yoshiaki.jitsukawa@sony.com>
+
+        Unreviewed. Build fix after r244244.
+
+        * bmalloc/AvailableMemory.cpp:
+
+2019-04-13  Zan Dobersek  <zdobersek@igalia.com>
+
+        [bmalloc][Linux] Add support for memory status calculation
+        https://bugs.webkit.org/show_bug.cgi?id=195938
+
+        Reviewed by Carlos Garcia Campos.
+
+        Memory status and under-memory-pressure capabilities in bmalloc can be
+        implemented on Linux by reading and parsing the statm file under the
+        proc filesystem.
+
+        We retrieve the resident set size from the statm file and multiply it
+        with the page size. This gives an upper-bound estimate of the memory
+        that's being consumed by the process.
+
+        The statm-based estimate seems preferable to other alternatives. One
+        such alternative would be reading and parsing more-detailed smaps file,
+        also exposed under the proc filesystem. This is at the moment being done
+        in WTF's MemoryFootprint implementation for Linux systems, but on Linux
+        ports this operation is being throttled to only execute once per second
+        because of the big computing expense required to read and parse out the
+        data. A future MemoryFootprint implementation could simply retrieve the
+        memory footprint value from bmalloc.
+
+        Another alternative is the Linux taskstats interface. This one would
+        require utilizing a netlink socket to retrieve the necessary statistics,
+        but it requires the process to have elevated privileges, which is a
+        blocker.
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::LinuxMemory::singleton):
+        (bmalloc::LinuxMemory::footprint const):
+        (bmalloc::computeAvailableMemory):
+        (bmalloc::memoryStatus):
+        * bmalloc/AvailableMemory.h:
+        (bmalloc::isUnderMemoryPressure):
+        * bmalloc/bmalloc.h:
+
+2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [WebCore] Put most of derived classes of ScriptWrappable into IsoHeap
+        https://bugs.webkit.org/show_bug.cgi?id=196475
+
+        Reviewed by Saam Barati.
+
+        Add MAKE_BISO_MALLOCED_IMPL_TEMPLATE, which can be used for explicit specialization for template classes.
+
+        * bmalloc/IsoHeap.h:
+        * bmalloc/IsoHeapInlines.h:
+
+2019-03-22  Keith Rollin  <krollin@apple.com>
+
+        Enable ThinLTO support in Production builds
+        https://bugs.webkit.org/show_bug.cgi?id=190758
+        <rdar://problem/45413233>
+
+        Reviewed by Daniel Bates.
+
+        Enable building with Thin LTO in Production when using Xcode 10.2 or
+        later. This change results in a 1.45% progression in PLT5. Full
+        Production build times increase about 2-3%. Incremental build times
+        are more severely affected, and so LTO is not enabled for local
+        engineering builds.
+
+        LTO is enabled only on macOS for now, until rdar://problem/49013399,
+        which affects ARM builds, is fixed.
+
+        To change the LTO setting when building locally:
+
+        - If building with `make`, specify WK_LTO_MODE={none,thin,full} on the
+          command line.
+        - If building with `build-webkit`, specify --lto-mode={none,thin,full}
+          on the command line.
+        - If building with `build-root`, specify --lto={none,thin,full} on the
+          command line.
+        - If building with Xcode, create a LocalOverrides.xcconfig file at the
+          top level of your repository directory (if needed) and define
+          WK_LTO_MODE to full, thin, or none.
+
+        * Configurations/Base.xcconfig:
+
+2019-03-21  Michael Saboff  <msaboff@apple.com>
+
+        [BMalloc] No need to delay deallocating chunks based on recent use
+        https://bugs.webkit.org/show_bug.cgi?id=196121
+
+        Reviewed by Mark Lam.
+
+        The "used since last scavenge" logic is not needed for small chunks since their memory isn't decommitted directly.
+        We can deallocate small chunks immediately as that adds them to the LargeRange free list.  That free list employs the
+        "used since last scavenge" logic before the scavenger decommits the backing memory.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::Chunk::usedSinceLastScavenge): Deleted.
+        (bmalloc::Chunk::clearUsedSinceLastScavenge): Deleted.
+        (bmalloc::Chunk::setUsedSinceLastScavenge): Deleted.
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::allocateSmallPage):
+
+2019-03-21  Brady Eidson  <beidson@apple.com>
+
+        Certain WebProcesses should opt-out of the freezer.
+        <rdar://problem/42846139> and https://bugs.webkit.org/show_bug.cgi?id=196062
+
+        Reviewed by Andy Estes.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/darwin/MemoryStatusSPI.h:
+
+2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Unreviewed, fix -Wformat warning
+        https://bugs.webkit.org/show_bug.cgi?id=195895
+        <rdar://problem/48517629>
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::threadRunLoop):
+
+2019-03-18  Michael Saboff  <msaboff@apple.com>
+
+        [BMalloc] Scavenger should react to recent memory activity
+        https://bugs.webkit.org/show_bug.cgi?id=195895
+
+        Reviewed by Geoffrey Garen.
+
+        This change adds a recently used bit to objects that are scavenged.  When an object is allocated, that bit is set.
+        When we scavenge, if the bit is set, we clear it.  If the bit was already clear, we decommit the object.  The timing
+        to scavenging has been changed as well.  We perform our first scavne almost immediately after bmalloc is initialized
+        (10ms later).  Subsequent scavenging is done as a multiple of the time it took to scavenge.  We bound this computed
+        time between a minimum and maximum.  Through empirical testing, the multiplier, minimum and maximum are
+        150x, 100ms and 10,000ms respectively.  For mini-mode, when the JIT is disabled, we use much more aggressive values of
+        50x, 25ms and 500ms.
+
+        Eliminated partial scavenging since this change allows for any scavenge to be partial or full based on recent use of
+        the objects on the various free lists.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::Chunk::usedSinceLastScavenge):
+        (bmalloc::Chunk::clearUsedSinceLastScavenge):
+        (bmalloc::Chunk::setUsedSinceLastScavenge):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::scavenge):
+        (bmalloc::Heap::allocateSmallChunk):
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::splitAndAllocate):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::scavengeToHighWatermark): Deleted.
+        * bmalloc/Heap.h:
+        * bmalloc/IsoDirectory.h:
+        * bmalloc/IsoDirectoryInlines.h:
+        (bmalloc::passedNumPages>::takeFirstEligible):
+        (bmalloc::passedNumPages>::scavenge):
+        (bmalloc::passedNumPages>::scavengeToHighWatermark): Deleted.
+        * bmalloc/IsoHeapImpl.h:
+        * bmalloc/IsoHeapImplInlines.h:
+        (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark): Deleted.
+        * bmalloc/LargeRange.h:
+        (bmalloc::LargeRange::LargeRange):
+        (bmalloc::LargeRange::usedSinceLastScavenge):
+        (bmalloc::LargeRange::clearUsedSinceLastScavenge):
+        (bmalloc::LargeRange::setUsedSinceLastScavenge):
+        (): Deleted.
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::Scavenger):
+        (bmalloc::Scavenger::threadRunLoop):
+        (bmalloc::Scavenger::timeSinceLastPartialScavenge): Deleted.
+        (bmalloc::Scavenger::partialScavenge): Deleted.
+        * bmalloc/Scavenger.h:
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::usedSinceLastScavenge):
+        (bmalloc::SmallPage::clearUsedSinceLastScavenge):
+        (bmalloc::SmallPage::setUsedSinceLastScavenge):
+
+2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] Add StaticPerProcess for known types to save pages
+        https://bugs.webkit.org/show_bug.cgi?id=195691
+
+        Reviewed by Mark Lam.
+
+        As initial memory footprint of VM + JSGlobalObject becomes 488KB dirty size in fast malloc memory (w/ JSC_useJIT=0 and Malloc=1), pages for PerProcess is costly.
+        For example, under Malloc=1 mode, we still need to allocate PerProcess<DebugHeap> and PerProcess<Environment>. And sizeof(Environment) is only 1 (bool flag), and
+        sizeof(DebugHeap) is 120. But we are allocating 1 pages for them. Since page size in iOS is 16KB, this 121B consumes 16KB dirty memory, and it is not negligible
+        size if we keep in mind that the current fast malloc heap size is 488KB. Putting them into the __DATA section, close to the other mutable data, we can avoid allocating
+        this page.
+
+        This patch revives the SafePerProcess concept in r228107. We add "StaticPerProcess<T>", which allocates underlying storage statically in the __DATA section instead of
+        allocating it at runtime. And we use this StaticPerProcess<T> for types where (1) T is known a priori, and (2) sizeof(T) is not huge.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/AllIsoHeaps.cpp:
+        * bmalloc/AllIsoHeaps.h:
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::Cache):
+        * bmalloc/CryptoRandom.cpp:
+        (bmalloc::cryptoRandom):
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::Deallocator):
+        * bmalloc/DebugHeap.cpp:
+        * bmalloc/DebugHeap.h:
+        (bmalloc::DebugHeap::tryGet):
+        * bmalloc/Environment.cpp:
+        * bmalloc/Environment.h:
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::Callback::Callback):
+        (Gigacage::Callback::function):
+        (bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
+        (Gigacage::disablePrimitiveGigacage):
+        (Gigacage::addPrimitiveDisableCallback):
+        (Gigacage::removePrimitiveDisableCallback):
+        (Gigacage::shouldBeEnabled):
+        (Gigacage::bmalloc::Callback::Callback): Deleted.
+        (Gigacage::bmalloc::Callback::function): Deleted.
+        (Gigacage::bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::tryAllocateLarge):
+        * bmalloc/IsoDirectoryInlines.h:
+        (bmalloc::passedNumPages>::takeFirstEligible):
+        (bmalloc::passedNumPages>::didBecome):
+        * bmalloc/IsoHeapImpl.cpp:
+        (bmalloc::IsoHeapImplBase::addToAllIsoHeaps):
+        * bmalloc/IsoPage.cpp:
+        (bmalloc::IsoPageBase::allocatePageMemory):
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::IsoTLS):
+        (bmalloc::IsoTLS::ensureEntries):
+        (bmalloc::IsoTLS::forEachEntry):
+        * bmalloc/IsoTLSEntry.cpp:
+        (bmalloc::IsoTLSEntry::IsoTLSEntry):
+        * bmalloc/IsoTLSInlines.h:
+        (bmalloc::IsoTLS::allocateSlow):
+        (bmalloc::IsoTLS::deallocateSlow):
+        * bmalloc/IsoTLSLayout.cpp:
+        * bmalloc/IsoTLSLayout.h:
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::Scavenger):
+        (bmalloc::dumpStats):
+        (bmalloc::Scavenger::scavenge):
+        (bmalloc::Scavenger::partialScavenge):
+        (bmalloc::Scavenger::freeableMemory):
+        (bmalloc::Scavenger::footprint):
+        * bmalloc/Scavenger.h:
+        * bmalloc/StaticPerProcess.h: Added.
+        * bmalloc/VMHeap.cpp:
+        * bmalloc/VMHeap.h:
+        * bmalloc/Zone.h:
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::scavenge):
+        (bmalloc::api::isEnabled):
+        (bmalloc::api::setScavengerThreadQOSClass):
+        (bmalloc::api::enableMiniMode):
+        * test/testbmalloc.cpp:
+        (assertEmptyPointerSet):
+        (assertHasObjects):
+        (assertHasOnlyObjects):
+        (assertClean):
+
+2019-03-13  Yoshiaki Jitsukawa  <yoshiaki.jitsukawa@sony.com>
+
+        [bmalloc] Use MADV_FREE on FreeBSD
+        https://bugs.webkit.org/show_bug.cgi?id=195665
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc/BPlatform.h:
+
+        Introduce BOS_FREEBSD, which is equivalent to WTF_OS_FREEBSD
+
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmDeallocatePhysicalPages):
+
+        Use MADV_FREE instead of MADV_DONTNEED if BOS(FREEBSD), since on FreeBSD,
+        unlike on Linux, MADV_DONTNEED doesn't let the OS discard the contents of
+        the pages.
+
+2019-03-13  Sam Weinig  <sam@webkit.org>
+
+        Fix testbmalloc build
+        https://bugs.webkit.org/show_bug.cgi?id=195660
+
+        Reviewed by Geoffrey Garen.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        Link Foundation in when building testbmalloc. Since bmalloc requires Foundation, and is a static
+        library, all clients of bmalloc are required to link it themselves.
+        
+        * bmalloc/IsoPageInlines.h:
+        * bmalloc/StdLibExtras.h: Added.
+        (bmalloc::bitwise_cast):
+        Add bitwise_cast implementation, and use it in IsoPageInlines.h. It is a layering violation
+        to expect the one from WTF to be available, as seems to have been the case.
+
+2019-03-12  Robin Morisset  <rmorisset@apple.com>
+
+        A lot more classes have padding that can be reduced by reordering their fields
+        https://bugs.webkit.org/show_bug.cgi?id=195579
+
+        Reviewed by Mark Lam.
+
+        * bmalloc/Heap.h:
+        * bmalloc/Scavenger.h:
+
+2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] Bmalloc DebugHeap should have dump and scavenge features
+        https://bugs.webkit.org/show_bug.cgi?id=195305
+
+        Reviewed by Saam Barati.
+
+        As the same to bmalloc, bmalloc::DebugHeap should have scavenge feature to make it scavengable if we want.
+        We also add DebugHeap::dump feature which dumps system malloc data in the WebKit Malloc zone.
+
+        * bmalloc/DebugHeap.cpp:
+        (bmalloc::DebugHeap::scavenge):
+        (bmalloc::DebugHeap::dump):
+        * bmalloc/DebugHeap.h:
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::scavenge):
+
+2019-02-23  Keith Miller  <keith_miller@apple.com>
+
+        Add new mac target numbers
+        https://bugs.webkit.org/show_bug.cgi?id=194955
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/DebugRelease.xcconfig:
+
+2019-02-19  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] bmalloc::Heap is allocated even though we use system malloc mode
+        https://bugs.webkit.org/show_bug.cgi?id=194836
+
+        Reviewed by Mark Lam.
+
+        Previously, bmalloc::Heap holds DebugHeap, and delegates allocation and deallocation to debug heap.
+        However, bmalloc::Heap is large. We would like to avoid initialization of bmalloc::Heap under the
+        system malloc mode.
+
+        This patch extracts out DebugHeap from bmalloc::Heap, and logically puts this in a boundary of
+        bmalloc::api. bmalloc::api delegates allocation and deallocation to DebugHeap if DebugHeap is enabled.
+        Otherwise, using bmalloc's usual mechanism. The challenge is that we would like to keep bmalloc fast
+        path fast.
+
+        1. For IsoHeaps, we use the similar techniques done in Cache. If the debug mode is enabled, we always go
+           to the slow path of the IsoHeap allocation, and keep IsoTLS::get() returning nullptr. In the slow path,
+           we just fallback to the usual bmalloc::api::tryMalloc implementation. This is efficient because bmalloc
+           continues using the fast path.
+
+        2. For the other APIs, like freeLargeVirtual, we just put DebugHeap check because this API itself takes fair
+           amount of time. Then debug heap check does not matter.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocateImpl):
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        (bmalloc::Cache::deallocateSlowCaseNullCache):
+        (bmalloc::Cache::tryReallocateSlowCaseNullCache):
+        (bmalloc::Cache::reallocateSlowCaseNullCache):
+        (): Deleted.
+        (bmalloc::debugHeap): Deleted.
+        * bmalloc/DebugHeap.cpp:
+        * bmalloc/DebugHeap.h:
+        (bmalloc::DebugHeap::tryGet):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        (bmalloc::Heap::footprint):
+        (bmalloc::Heap::tryAllocateLarge):
+        (bmalloc::Heap::deallocateLarge):
+        * bmalloc/Heap.h:
+        (bmalloc::Heap::debugHeap): Deleted.
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::IsoTLS):
+        (bmalloc::IsoTLS::isUsingDebugHeap): Deleted.
+        (bmalloc::IsoTLS::debugMalloc): Deleted.
+        (bmalloc::IsoTLS::debugFree): Deleted.
+        * bmalloc/IsoTLS.h:
+        * bmalloc/IsoTLSInlines.h:
+        (bmalloc::IsoTLS::allocateSlow):
+        (bmalloc::IsoTLS::deallocateSlow):
+        * bmalloc/ObjectType.cpp:
+        (bmalloc::objectType):
+        * bmalloc/ObjectType.h:
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::Scavenger):
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::tryLargeZeroedMemalignVirtual):
+        (bmalloc::api::freeLargeVirtual):
+        (bmalloc::api::scavenge):
+        (bmalloc::api::isEnabled):
+        (bmalloc::api::setScavengerThreadQOSClass):
+        (bmalloc::api::commitAlignedPhysical):
+        (bmalloc::api::decommitAlignedPhysical):
+        (bmalloc::api::enableMiniMode):
+
+2019-02-20  Andy Estes  <aestes@apple.com>
+
+        [Xcode] Add SDKVariant.xcconfig to various Xcode projects
+        https://bugs.webkit.org/show_bug.cgi?id=194869
+
+        Rubber-stamped by Jer Noble.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+
+2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] DebugHeap::malloc does not have "try" version.
+        https://bugs.webkit.org/show_bug.cgi?id=194837
+
+        Reviewed by Mark Lam.
+
+        Since DebugHeap::malloc does not have "try" version, our tryAllocate implementation does not work well with DebugHeap.
+        This patch adds crashOnFailure flag to DebugHeap::malloc.
+
+        * bmalloc/Cache.cpp:
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        * bmalloc/DebugHeap.cpp:
+        (bmalloc::DebugHeap::malloc):
+        * bmalloc/DebugHeap.h:
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::debugMalloc):
+
+2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] bmalloc::Cache should not be instantiated if we are using system malloc
+        https://bugs.webkit.org/show_bug.cgi?id=194811
+
+        Reviewed by Mark Lam.
+
+        bmalloc::Cache is very large. It is 13KB. Since it exists per HeapKind, it takes 40KB.
+        But this is meaningless if we are under the system malloc mode by using "Malloc=1". We
+        found that it continues using so much dirty memory region even under the system malloc mode.
+        This patch avoids instantiation of bmalloc::Cache under the system malloc mode.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocateImpl):
+        (bmalloc::Allocator::allocateSlowCase):
+        Allocator is a per Cache object. So we no longer need to keep m_debugHeap. If debug heap is enabled,
+        Allocator is never created.
+
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.cpp:
+        (bmalloc::debugHeap):
+        (bmalloc::Cache::Cache):
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        (bmalloc::Cache::deallocateSlowCaseNullCache):
+        (bmalloc::Cache::tryReallocateSlowCaseNullCache):
+        (bmalloc::Cache::reallocateSlowCaseNullCache):
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate):
+        (bmalloc::Cache::tryReallocate):
+        If the debug heap mode is enabled, we keep Cache::getFast() returning nullptr. And in the slow path case, we use debugHeap.
+        This makes bmalloc fast path fast, while we avoid Cache instantiation.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::Deallocator):
+        (bmalloc::Deallocator::scavenge):
+        (bmalloc::Deallocator::deallocateSlowCase):
+        * bmalloc/Deallocator.h:
+        Ditto for Deallocator.
+
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::isEnabled):
+        We used `getFastCase()` for Heap. But it is basically wrong since we do not have any guarantee that someone already initializes
+        Heap when this is called. Previously, luckily, Cache is initialized, and Cache initialized Heap. But Cache initialization is removed
+        for system malloc mode and now PerProcess<PerHeapKind<Heap>>::getFastCase() returns nullptr at an early phase. This patch just uses
+        Environment::isDebugHeapEnabled() instead.
+
+2019-02-20  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r241789.
+        https://bugs.webkit.org/show_bug.cgi?id=194856
+
+        GuardMalloc crashes (Requested by yusukesuzuki on #webkit).
+
+        Reverted changeset:
+
+        "[bmalloc] bmalloc::Cache should not be instantiated if we are
+        using system malloc"
+        https://bugs.webkit.org/show_bug.cgi?id=194811
+        https://trac.webkit.org/changeset/241789
+
+2019-02-19  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] bmalloc::Cache should not be instantiated if we are using system malloc
+        https://bugs.webkit.org/show_bug.cgi?id=194811
+
+        Reviewed by Mark Lam.
+
+        bmalloc::Cache is very large. It is 13KB. Since it exists per HeapKind, it takes 40KB.
+        But this is meaningless if we are under the system malloc mode by using "Malloc=1". We
+        found that it continues using so much dirty memory region even under the system malloc mode.
+        This patch avoids instantiation of bmalloc::Cache under the system malloc mode.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::Allocator):
+        (bmalloc::Allocator::tryAllocate):
+        (bmalloc::Allocator::allocateImpl):
+        (bmalloc::Allocator::reallocateImpl):
+        (bmalloc::Allocator::allocateSlowCase):
+        Allocator is a per Cache object. So we no longer need to keep m_debugHeap. If debug heap is enabled,
+        Allocator is never created.
+
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.cpp:
+        (bmalloc::debugHeap):
+        (bmalloc::Cache::Cache):
+        (bmalloc::Cache::tryAllocateSlowCaseNullCache):
+        (bmalloc::Cache::allocateSlowCaseNullCache):
+        (bmalloc::Cache::deallocateSlowCaseNullCache):
+        (bmalloc::Cache::tryReallocateSlowCaseNullCache):
+        (bmalloc::Cache::reallocateSlowCaseNullCache):
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryAllocate):
+        (bmalloc::Cache::tryReallocate):
+        If the debug heap mode is enabled, we keep Cache::getFast() returning nullptr. And in the slow path case, we use debugHeap.
+        This makes bmalloc fast path fast, while we avoid Cache instantiation.
+
+        * bmalloc/Deallocator.cpp:
+        (bmalloc::Deallocator::Deallocator):
+        (bmalloc::Deallocator::scavenge):
+        (bmalloc::Deallocator::deallocateSlowCase):
+        * bmalloc/Deallocator.h:
+        Ditto for Deallocator.
+
+2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] NSBundle-based application name check should be executed after debug-heap environment variable check
+        https://bugs.webkit.org/show_bug.cgi?id=194694
+
+        Reviewed by Mark Lam.
+
+        Interestingly, NSBundle allocates fair amount of memory and keeps it for a process-long time. For example, it
+        allocates global NSConcreteHashTable, which takes 2.5KB. This patch changes the order of gigacage-check, we
+        first check "Malloc=1" status, and then check the process name through NSBundle. This allows us to remove NSBundle
+        related allocation in JSC initialization in the system malloc mode.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::shouldBeEnabled):
+
+2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [bmalloc] Do not start scavenger thread if we use system malloc
+        https://bugs.webkit.org/show_bug.cgi?id=194674
+
+        Reviewed by Mark Lam.
+
+        We always start the scavenger thread even if system malloc is used by the environment variable like "Malloc=1".
+        Because bmalloc allocation goes to the system malloc if "Malloc=1" is set, we do not need to scavenge. This patch
+        changes it not to start the scavenger thread.
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::Scavenger):
+
+2019-02-12  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r241182.
+        https://bugs.webkit.org/show_bug.cgi?id=194547
+
+        causes a 2-3% Speedometer2 regression. (Requested by
+        keith_miller on #webkit).
+
+        Reverted changeset:
+
+        "bmalloc uses more memory on iOS compared to macOS due to
+        physical page size differences"
+        https://bugs.webkit.org/show_bug.cgi?id=192389
+        https://trac.webkit.org/changeset/241182
+
+2019-02-07  Michael Saboff  <msaboff@apple.com>
+
+        bmalloc uses more memory on iOS compared to macOS due to physical page size differences
+        https://bugs.webkit.org/show_bug.cgi?id=192389
+
+        Reviewed by Geoffrey Garen.
+
+        Changed small line allocations to be in smallPageSize "virtual page" multiples instead of physical
+        page size increments for sizes less that the physical page size.  This required changing the small
+        page commit / decommit code to work in full physical page increments.  For page classes that are
+        physical page size and larger, there isn't any functional change.
+
+        When scavenging page classes smaller than the physical page size, we need to consider whether or
+        not the adjacent small pages on the same physical page are also free before decommiting that
+        containing page.  When we need to commit more memory, we commit the whole page, and add any
+        adjacent virtual pages that were fully committed as well.
+
+        * bmalloc/Chunk.h:
+        (bmalloc::forEachPage):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::initializeLineMetadata):
+        (bmalloc::Heap::initializePageMetadata):
+        (bmalloc::Heap::scavenge):
+        (bmalloc::__attribute__):
+        (bmalloc::Heap::commitSmallPagesInPhysicalPage):
+        (bmalloc::Heap::allocateSmallPage):
+        (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
+        * bmalloc/Heap.h:
+        * bmalloc/SmallPage.h:
+        (bmalloc::SmallPage::refCount):
+
+2019-01-18  Keith Miller  <keith_miller@apple.com>
+
+        gigacage slide should randomize both start and end
+        https://bugs.webkit.org/show_bug.cgi?id=193601
+
+        Reviewed by Yusuke Suzuki.
+
+        This patch makes it so that the gigacade slide has an arbitrary
+        distance from the end as well as the start. This is done by
+        picking a random size then based on that size picking an random
+        starting offset.
+
+        * bmalloc/Gigacage.h:
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+
+2019-01-18  Jer Noble  <jer.noble@apple.com>
+
+        SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
+        https://bugs.webkit.org/show_bug.cgi?id=189553
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/SDKVariant.xcconfig: Added.
+
+2019-01-18  Keith Miller  <keith_miller@apple.com>
+
+        Gigacages should start allocations from a slide
+        https://bugs.webkit.org/show_bug.cgi?id=193523
+
+        Reviewed by Mark Lam.
+
+        This patch makes it so that Gigacage Heaps slide the start of the
+        cage by some random amount. We still ensure that there is always
+        at least 4/2GB, on MacOS/iOS respectively, of VA space available
+        for allocation.
+
+        Also, this patch changes some macros into constants since macros
+        are the devil.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::bmalloc::protectGigacageBasePtrs):
+        (Gigacage::bmalloc::unprotectGigacageBasePtrs):
+        (Gigacage::bmalloc::runwaySize):
+        (Gigacage::ensureGigacage):
+        (Gigacage::shouldBeEnabled):
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::gigacageSizeToMask):
+        (Gigacage::size):
+        (Gigacage::mask):
+        (Gigacage::basePtr):
+        (Gigacage::ensureGigacage):
+        (Gigacage::wasEnabled):
+        (Gigacage::isCaged):
+        (Gigacage::isEnabled):
+        (Gigacage::caged):
+        (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
+        (Gigacage::canPrimitiveGigacageBeDisabled):
+        (Gigacage::disablePrimitiveGigacage):
+        (Gigacage::addPrimitiveDisableCallback):
+        (Gigacage::removePrimitiveDisableCallback):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        * bmalloc/Sizes.h:
+        (bmalloc::Sizes::maskSizeClass):
+        (bmalloc::Sizes::maskObjectSize):
+        (bmalloc::Sizes::logSizeClass):
+        (bmalloc::Sizes::logObjectSize):
+        (bmalloc::Sizes::sizeClass):
+        (bmalloc::Sizes::objectSize):
+        (bmalloc::Sizes::pageSize):
+
+2019-01-18  Matt Lewis  <jlewis3@apple.com>
+
+        Unreviewed, rolling out r240160.
+
+        This broke multiple internal builds.
+
+        Reverted changeset:
+
+        "Gigacages should start allocations from a slide"
+        https://bugs.webkit.org/show_bug.cgi?id=193523
+        https://trac.webkit.org/changeset/240160
+
+2019-01-18  Keith Miller  <keith_miller@apple.com>
+
+        Gigacages should start allocations from a slide
+        https://bugs.webkit.org/show_bug.cgi?id=193523
+
+        Reviewed by Mark Lam.
+
+        This patch makes it so that Gigacage Heaps slide the start of the
+        cage by some random amount. We still ensure that there is always
+        at least 4/2GB, on MacOS/iOS respectively, of VA space available
+        for allocation.
+
+        Also, this patch changes some macros into constants since macros
+        are the devil.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::bmalloc::protectGigacageBasePtrs):
+        (Gigacage::bmalloc::unprotectGigacageBasePtrs):
+        (Gigacage::bmalloc::runwaySize):
+        (Gigacage::ensureGigacage):
+        (Gigacage::shouldBeEnabled):
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::gigacageSizeToMask):
+        (Gigacage::size):
+        (Gigacage::mask):
+        (Gigacage::basePtr):
+        (Gigacage::ensureGigacage):
+        (Gigacage::wasEnabled):
+        (Gigacage::isCaged):
+        (Gigacage::caged):
+        (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
+        (Gigacage::disablePrimitiveGigacage):
+        (Gigacage::addPrimitiveDisableCallback):
+        (Gigacage::removePrimitiveDisableCallback):
+        * bmalloc/Heap.cpp:
+        (bmalloc::Heap::Heap):
+        * bmalloc/Sizes.h:
+        (bmalloc::Sizes::maskSizeClass):
+        (bmalloc::Sizes::maskObjectSize):
+        (bmalloc::Sizes::logSizeClass):
+        (bmalloc::Sizes::logObjectSize):
+        (bmalloc::Sizes::sizeClass):
+        (bmalloc::Sizes::objectSize):
+        (bmalloc::Sizes::pageSize):
+
+2019-01-17  Truitt Savell  <tsavell@apple.com>
+
+        Unreviewed, rolling out r240124.
+
+        This commit broke an internal build.
+
+        Reverted changeset:
+
+        "SDK_VARIANT build destinations should be separate from non-
+        SDK_VARIANT builds"
+        https://bugs.webkit.org/show_bug.cgi?id=189553
+        https://trac.webkit.org/changeset/240124
+
+2019-01-17  Jer Noble  <jer.noble@apple.com>
+
+        SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
+        https://bugs.webkit.org/show_bug.cgi?id=189553
+
+        Reviewed by Tim Horton.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/SDKVariant.xcconfig: Added.
+
+2019-01-16  Keith Miller  <keith_miller@apple.com>
+
+        bmalloc should use JSC VM tag for gigacage
+        https://bugs.webkit.org/show_bug.cgi?id=193496
+
+        Reviewed by Mark Lam.
+
+        This patch moves the VMTag info from WTF to bmalloc so that we can
+        tag gigacage memory with the unused JSC memory tag. The JSC memory
+        tag was previously used for wasm but since wasm is now allocated
+        out of the primitive cage it was unused.
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/BVMTags.h: Copied from Source/WTF/wtf/VMTags.h.
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+        * bmalloc/VMAllocate.h:
+        (bmalloc::tryVMAllocate):
+        (bmalloc::vmZeroAndPurge):
+
+2019-01-09  Mark Lam  <mark.lam@apple.com>
+
+        Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly.
+        https://bugs.webkit.org/show_bug.cgi?id=193292
+        <rdar://problem/46485450>
+
+        Reviewed by Yusuke Suzuki.
+
+        Previously, when GIGACAGE_ALLOCATION_CAN_FAIL is true, we allow the Gigacage to
+        be disabled if we fail to allocate memory for it.  However, Gigacage::primitiveGigacageDisabled()
+        still always assumes that the Gigacage is always enabled after ensureGigacage() is
+        called.
+
+        This patch updates Gigacage::primitiveGigacageDisabled() to allow the Gigacage to
+        already be disabled if GIGACAGE_ALLOCATION_CAN_FAIL is true and wasEnabled() is
+        false.
+
+        In this patch, we also put the wasEnabled flag in the 0th slot of the
+        g_gigacageBasePtrs buffer to ensure that it is also protected against writes just
+        like the Gigacage base pointers.
+
+        To achieve this, we do the following:
+        1. Added a reservedForFlags field in struct BasePtrs.
+        2. Added a ReservedForFlagsAndNotABasePtr Gigacage::Kind.
+        3. Added assertions to ensure that the BasePtrs::primitive is at the offset
+           matching the offset computed from Gigacage::Primitive.  Ditto for
+           BasePtrs::jsValue and Gigacage::JSValue.
+        4. Added assertions to ensure that Gigacage::ReservedForFlagsAndNotABasePtr is not
+           used for fetching a Gigacage base pointer.
+        5. Added RELEASE_BASSERT_NOT_REACHED() to implement such assertions in bmalloc.
+
+        No test added because this issue requires Gigacage allocation to fail in order to
+        manifest.  I've tested it manually by modifying the code locally to force an
+        allocation failure.
+
+        * bmalloc/BAssert.h:
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+        (Gigacage::primitiveGigacageDisabled):
+        * bmalloc/Gigacage.h:
+        (Gigacage::wasEnabled):
+        (Gigacage::setWasEnabled):
+        (Gigacage::name):
+        (Gigacage::basePtr):
+        (Gigacage::size):
+        * bmalloc/HeapKind.h:
+        (bmalloc::heapKind):
+
+2018-12-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>
+
+        Unreviewed, suppress warnings in Linux
+
+        * bmalloc/Gigacage.cpp:
+
+2018-12-14  Keith Miller  <keith_miller@apple.com>
+
+        Gigacage runway should immediately follow the primitive cage
+        https://bugs.webkit.org/show_bug.cgi?id=192733
+
+        Reviewed by Saam Barati.
+
+        This patch makes sure that the Gigacage runway is always
+        immediately after the primitive cage. Since writing outside the
+        primitive gigacage is likely to be more dangerous than the JSValue
+        cage. The ordering of the cages is still random however.
+
+        * bmalloc/Gigacage.cpp:
+        (Gigacage::ensureGigacage):
+
+2018-12-13  Mark Lam  <mark.lam@apple.com>
+
+        Verify that tryLargeZeroedMemalignVirtual()'s aligned size and alignment values are valid.
+        https://bugs.webkit.org/show_bug.cgi?id=192682
+        <rdar://problem/37751522>
+
+        Reviewed by Saam Barati.
+
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::tryLargeZeroedMemalignVirtual):
+
+2018-11-21  Dominik Infuehr  <dinfuehr@igalia.com>
+
+        Enable JIT on ARM/Linux
+        https://bugs.webkit.org/show_bug.cgi?id=191548
+
+        Reviewed by Yusuke Suzuki.
+
+        * bmalloc/IsoPageInlines.h:
+        (bmalloc::IsoPage<Config>::startAllocating):
+
+2018-11-01  Jiewen Tan  <jiewen_tan@apple.com>
+
+        Replace CommonRandom SPI with API
+        https://bugs.webkit.org/show_bug.cgi?id=191178
+        <rdar://problem/45722391>
+
+        Reviewed by Brent Fulgham.
+
+        * bmalloc/CryptoRandom.cpp:
+        (bmalloc::ARC4RandomNumberGenerator::stir):
+
+2018-10-29  Mark Lam  <mark.lam@apple.com>
+
+        Correctly detect string overflow when using the 'Function' constructor.
+        https://bugs.webkit.org/show_bug.cgi?id=184883
+        <rdar://problem/36320331>
+
+        Reviewed by Saam Barati.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate):
+        (bmalloc::Allocator::tryReallocate):
+        (bmalloc::Allocator::reallocateImpl):
+        * bmalloc/Allocator.h:
+        * bmalloc/Cache.h:
+        (bmalloc::Cache::tryReallocate):
+        * bmalloc/DebugHeap.cpp:
+        (bmalloc::DebugHeap::realloc):
+        * bmalloc/DebugHeap.h:
+        * bmalloc/bmalloc.h:
+        (bmalloc::api::tryRealloc):
+
+2018-10-25  Ross Kirsling  <ross.kirsling@sony.com>
+
+        Cleanup: inline constexpr is redundant as constexpr implies inline
+        https://bugs.webkit.org/show_bug.cgi?id=190819
+
+        Reviewed by Mark Lam.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::max):
+        (bmalloc::min):
+        (bmalloc::mask):
+        (bmalloc::test):
+        (bmalloc::isPowerOfTwo):
+        (bmalloc::roundDownToMultipleOf):
+        (bmalloc::sizeOf):
+        (bmalloc::bitCount):
+        (bmalloc::log2):
+        * bmalloc/Bits.h:
+        (bmalloc::bitsArrayLength):
+        * bmalloc/Sizes.h:
+        (bmalloc::Sizes::maskSizeClass):
+
+2018-10-24  Alexey Proskuryakov  <ap@apple.com>
+
+        Add BPLATFORM(IOS_FAMILY)
+        https://bugs.webkit.org/show_bug.cgi?id=190878
+
+        Reviewed by Saam Barati.
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::memorySizeAccordingToKernel):
+        (bmalloc::computeAvailableMemory):
+        * bmalloc/AvailableMemory.h:
+        (bmalloc::isUnderMemoryPressure):
+        * bmalloc/BPlatform.h:
+        * bmalloc/Gigacage.h:
+        * bmalloc/Logging.cpp:
+        (bmalloc::logVMFailure):
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmPageSizePhysical):
+        * bmalloc/bmalloc.h:
+        * bmalloc/darwin/MemoryStatusSPI.h:
+
+2018-10-12  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r237063.
+
+        Caused layout test fast/dom/Window/window-postmessage-clone-
+        deep-array.html to fail on macOS and iOS Debug bots.
+
+        Reverted changeset:
+
+        "[JSC] Remove gcc warnings on mips and armv7"
+        https://bugs.webkit.org/show_bug.cgi?id=188598
+        https://trac.webkit.org/changeset/237063
+
+2018-10-11  Guillaume Emont  <guijemont@igalia.com>
+
+        [JSC] Remove gcc warnings on mips and armv7
+        https://bugs.webkit.org/show_bug.cgi?id=188598
+
+        Reviewed by Mark Lam.
+
+        Add bitwise_cast (from WTF) and use it instead of reinterpret_cast in
+        a couple places where reinterpret_cast triggers a warning about
+        alignment even though we know that alignment is correct.
+
+        * bmalloc/Algorithm.h:
+        (bmalloc::bitwise_cast): Copied from WTF/wtf/StdLibextras.h
+        * bmalloc/IsoDirectoryPageInlines.h:
+        (bmalloc::IsoDirectoryPage<Config>::pageFor):
+        * bmalloc/IsoPageInlines.h:
+        (bmalloc::IsoPage<Config>::startAllocating):
+
+2018-10-03  Dan Bernstein  <mitz@apple.com>
+
+        bmalloc part of [Xcode] Update some build settings as recommended by Xcode 10
+        https://bugs.webkit.org/show_bug.cgi?id=190250
+
+        Reviewed by Alex Christensen.
+
+        * Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS,
+          and CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF.
+
+        * bmalloc.xcodeproj/project.pbxproj: Let Xcode update LastUpgradeCheck.
+
+2018-09-25  Alex Christensen  <achristensen@webkit.org>
+
+        Allow for suffixes to com.apple.WebKit.WebContent
+        https://bugs.webkit.org/show_bug.cgi?id=189972
+
+        Reviewed by Chris Dumez.
+
+        * bmalloc/ProcessCheck.mm:
+        (bmalloc::gigacageEnabledForProcess):
+
+2018-09-24  Fujii Hironori  <Hironori.Fujii@sony.com>
+
+        Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
+        https://bugs.webkit.org/show_bug.cgi?id=189733
+
+        Reviewed by Michael Catanzaro.
+
+        * bmalloc/BCompiler.h:
+
+2018-08-27  Keith Rollin  <krollin@apple.com>
+
+        Unreviewed build fix -- disable LTO for production builds
+
+        * Configurations/Base.xcconfig:
+
+2018-08-27  Keith Rollin  <krollin@apple.com>
+
+        Build system support for LTO
+        https://bugs.webkit.org/show_bug.cgi?id=187785
+        <rdar://problem/42353132>
+
+        Reviewed by Dan Bernstein.
+
+        Update Base.xcconfig and DebugRelease.xcconfig to optionally enable
+        LTO.
+
+        * Configurations/Base.xcconfig:
+        * Configurations/DebugRelease.xcconfig:
+
+2018-08-16  Tomas Popela  <tpopela@redhat.com>
+
+        bmalloc: Coverity scan issues
+        https://bugs.webkit.org/show_bug.cgi?id=186763
+
+        Reviewed by Saam Barati.
+
+        * bmalloc/DebugHeap.h: Initialize the m_pageSize variable.
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::ensureEntries): Check the return value of
+        pthread_key_create return().
+        * bmalloc/VMAllocate.h:
+        (bmalloc::vmPageSize): Correctly check the return value of sysconf().
+
+2018-07-27  Mark Lam  <mark.lam@apple.com>
+
+        Initialize bmalloc::DebugHeap::m_pageSize for non-Darwin builds.
+        https://bugs.webkit.org/show_bug.cgi?id=188132
+        <rdar://problem/40401599>
+
+        Reviewed by Saam Barati.
+
+        * bmalloc/DebugHeap.cpp:
+        (bmalloc::DebugHeap::DebugHeap):
+
+2018-07-27  Saam Barati  <sbarati@apple.com>
+
+        Explicitly handle memlimit_active < 0
+        https://bugs.webkit.org/show_bug.cgi?id=188125
+
+        Reviewed by Mark Lam.
+
+        This may come up during development when someone wants the limit
+        to be "infinite".
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::jetsamLimit):
+
+2018-07-27  Saam Barati  <sbarati@apple.com>
+
+        Use SPI to compute the jetsam limit on iOS instead of hardcoding 840MB
+        https://bugs.webkit.org/show_bug.cgi?id=188091
+        <rdar://problem/42647697>
+
+        Reviewed by Simon Fraser.
+
+        We want bmalloc to dynamically adapt to the jetsam limit of the process
+        it's running in. WTF::ramSize() is based off bmalloc's availableMemory,
+        so it will now reflect the result of the real jetsam limit when we can
+        read it.
+        
+        Reading the jetsam limit requires an entitlement, so this patch opts in
+        the WebContent/Storage/Network processes. We fall back to 840MB (the
+        old hard coded value) when the SPI call fails (e.g, when we're in a
+        process without the proper entitlement).
+
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::jetsamLimit):
+        (bmalloc::computeAvailableMemory):
+        * bmalloc/darwin/MemoryStatusSPI.h: Added.
+
+2018-07-24  Saam Barati  <sbarati@apple.com>
+
+        Revert back to using phys_footprint to calculate isUnderMemoryPressure()
+        https://bugs.webkit.org/show_bug.cgi?id=187919
+        <rdar://problem/42552888>
+
+        Reviewed by Simon Fraser.
+
+        Currently on iOS, bmalloc will run the scavenger more frequently when it detects
+        that the process is under memory pressure. However, it only uses bmalloc's
+        own footprint as a percentage of the HW available memory to determine if
+        the process is under memory pressure. This is a change I recently made
+        in an effort to run the scavenger less when bmalloc wasn't contributing
+        to the dirty footprint in the process. However, this fails to run the
+        scavenger eagerly when the process in question has a heap split
+        between a lot of dirty bmalloc memory as well as a lot of dirty memory
+        from elsewhere. We also have evidence that we may have increased jetsams
+        in the Web Content process. Since my original change was not a measurable
+        speedup, this patch reverts isUnderMemoryPressure() to its previous
+        behavior of using phys_footprint to determine if 75% of the available 
+        HW memory is being used.
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::memoryStatus):
+
+2019-07-12  Michael Saboff  <msaboff@apple.com>
+
+        Disable IsoHeaps when Gigacage is off
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+
+        Reviewed by Saam Barati.
+
+        Relanding change sets 233547 and 233550 with the added fix that Gigacage is also
+        enabled for DumpRenderTree.
+
+        Updated determineMallocFallbackState to base enabling of Iso Heaps on Gigacage 
+        being enabled.  We do this because if Gigacage is disabled, it may be due to lack
+        of address space.
+
+        To work around a compiler issue uncovered by the change above, I added explicit
+        instantiation of PerThread's static variables.  Defined the same explicit
+        instantiated static variables with export scope in the new file PerThread.cpp
+        to eliminate separate variables allocations in each linked framework / library.
+
+        * CMakeLists.txt:
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::determineMallocFallbackState):
+        * bmalloc/PerThread.cpp: Added.
+        * bmalloc/PerThread.h:
+        * bmalloc/ProcessCheck.mm:
+        (bmalloc::gigacageEnabledForProcess):
+
+2018-07-09  Commit Queue  <commit-queue@webkit.org>
+
+        Unreviewed, rolling out r233547 and r233550.
+        https://bugs.webkit.org/show_bug.cgi?id=187497
+
+        Introduced flakiness for media/fullscreen-* tests on mac-wk1
+        (Requested by ryanhaddad on #webkit).
+
+        Reverted changesets:
+
+        "Disable IsoHeaps when Gigacage is off"
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+        https://trac.webkit.org/changeset/233547
+
+        "Build fix (r233547): Disable IsoHeaps when Gigacage is off"
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+        https://trac.webkit.org/changeset/233550
+
+2018-07-05  David Kilzer  <ddkilzer@apple.com>
+
+        Build fix (r233547): Disable IsoHeaps when Gigacage is off
+        <https://webkit.org/b/187160>
+
+        * bmalloc/PerThread.cpp: Add #if !HAVE_PTHREAD_MACHDEP_H/#endif
+        around variables only used when that macro is 0.  Include what
+        you use: Cache.h and Heap.h.
+        * bmalloc/PerThread.h: Include <memory> for std::once_flag.
+
+2018-07-05  Michael Saboff  <msaboff@apple.com>
+
+        Disable IsoHeaps when Gigacage is off
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+
+        Reviewed by Saam Barati.
+
+        Updated determineMallocFallbackState to base enabling of Iso Heaps on Gigacage 
+        being enabled.  We do this because if Gigacage is disabled, it may be due to lack
+        of address space.
+
+        To work around a compiler issue uncovered by the change above, I added explicit
+        instantiation of PerThread's static variables.  Defined the same explicit
+        instantiated static variables with export scope in the new file PerThread.cpp
+        to eliminate separate variables allocations in each linked framework / library.
+
+        * CMakeLists.txt:
+        * bmalloc.xcodeproj/project.pbxproj:
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::determineMallocFallbackState):
+        * bmalloc/PerThread.cpp: Added.
+        * bmalloc/PerThread.h:
+
+2018-07-04  Tim Horton  <timothy_horton@apple.com>
+
+        Introduce PLATFORM(IOSMAC)
+        https://bugs.webkit.org/show_bug.cgi?id=187315
+
+        Reviewed by Dan Bernstein.
+
+        * Configurations/Base.xcconfig:
+
+2018-06-29  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r233347.
+
+        Causes crashes during WK1 tests.
+
+        Reverted changeset:
+
+        "Disable IsoHeaps when Gigacage is off"
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+        https://trac.webkit.org/changeset/233347
+
+2018-06-28  Michael Saboff  <msaboff@apple.com>
+
+        Disable IsoHeaps when Gigacage is off
+        https://bugs.webkit.org/show_bug.cgi?id=187160
+
+        Reviewed by Saam Barati.
+
+        If Gigacage is disabled, it may be due to lack of address space.
+        Therefore we should also turn off IsoHeaps since it uses more virtual
+        address space as well.
+
+        * bmalloc/IsoTLS.cpp:
+        (bmalloc::IsoTLS::determineMallocFallbackState):
+
+2018-06-27  Simon Fraser  <simon.fraser@apple.com>
+
+        https://hackernoon.com/ uses lots of layer backing store
+        https://bugs.webkit.org/show_bug.cgi?id=186909
+        rdar://problem/40257540
+
+        Reviewed by Tim Horton.
+        
+        Drive-by typo fix.
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::dumpStats):
+
+2018-06-26  Saam Barati  <sbarati@apple.com>
+
+        Unreviewed followup. Fix the watchos build after r233192.
+
+        This patch also correct the changelog entry below to have the correct
+        bug and title info.
+
+        * bmalloc/ProcessCheck.mm:
+
+2018-06-26  Saam Barati  <sbarati@apple.com>
+
+        Switch to system malloc on iOS when nano malloc is disabled
+        https://bugs.webkit.org/show_bug.cgi?id=186322
+        <rdar://problem/41140257>
+
+        Reviewed by Keith Miller.
+
+        We have evidence showing that processes with small heaps using the
+        JS API are more space efficient when using system malloc. Our main
+        hypothesis as to why this is, is that when dealing with small heaps,
+        one malloc can be more efficient at optimizing memory usage than
+        two mallocs.
+
+        * bmalloc/BPlatform.h:
+        * bmalloc/Environment.cpp:
+        (bmalloc::isNanoMallocEnabled):
+        (bmalloc::Environment::computeIsDebugHeapEnabled):
+        * bmalloc/ProcessCheck.h:
+        (bmalloc::shouldProcessUnconditionallyUseBmalloc):
+        * bmalloc/ProcessCheck.mm:
+        (bmalloc::shouldProcessUnconditionallyUseBmalloc):
+
+2018-06-24  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        [bmalloc][Linux] Remove static initializers for PerProcess<>::s_object
+        https://bugs.webkit.org/show_bug.cgi?id=186966
+
+        Reviewed by Anders Carlsson.
+
+        chrome/tools/linux/dump-static-initializers.py can dump static initializers
+        in the binary and we found that PerProcess<>::s_object initialization is done
+        by static initializers in GCC + Linux environments. The example is the following.
+
+        Scavenger.cpp (initializer offset 0x38c210 size 0x3e)
+            _GLOBAL__sub_I_Scavenger.cpp+0x1e
+            _GLOBAL__sub_I_Scavenger.cpp+0x2d
+            _GLOBAL__sub_I_Scavenger.cpp+0x3c
+            _GLOBAL__sub_I_Scavenger.cpp+0xf
+            guard variable for bmalloc::PerProcess<bmalloc::AllIsoHeaps>::s_object@@Base-0x3f0d8
+            guard variable for bmalloc::PerProcess<bmalloc::Environment>::s_object@@Base-0x3f0e8
+            guard variable for bmalloc::PerProcess<bmalloc::PerHeapKind<bmalloc::Heap> >::s_object@@Base-0x3c600
+            guard variable for bmalloc::PerProcess<bmalloc::Scavenger>::s_object@@Base-0x38ce8
+
+        We can remove this by initializing `nullptr`, which leads to constexpr initialization.
+        After this change, Linux JSCOnly libJavaScriptCore.so has no static initializers.
+
+        * bmalloc/PerProcess.h:
+
+2018-06-09  Dan Bernstein  <mitz@apple.com>
+
+        [Xcode] Clean up and modernize some build setting definitions
+        https://bugs.webkit.org/show_bug.cgi?id=186463
+
+        Reviewed by Sam Weinig.
+
+        * Configurations/Base.xcconfig: Removed definition for macOS 10.11.
+        * Configurations/DebugRelease.xcconfig: Ditto.
+
+2018-06-07  Darin Adler  <darin@apple.com>
+
+        [Cocoa] Turn on ARC for the single Objective-C++ source file in bmalloc
+        https://bugs.webkit.org/show_bug.cgi?id=186398
+
+        Reviewed by Saam Barati.
+
+        * Configurations/Base.xcconfig: Turn on ARC.
+        * bmalloc/ProcessCheck.mm:
+        (bmalloc::gigacageEnabledForProcess): Removed the globals from this function,
+        since it's only called once. If it was called more than once, we could optimize
+        that with a single boolean global rather than two strings and two booleans.
+
+2018-06-07  David Kilzer  <ddkilzer@apple.com>
+
+        bmalloc: Fix 'noreturn' warnings when compiling with -std=gnu++17
+        <https://webkit.org/b/186400>
+
+        Reviewed by Saam Barati.
+
+        Fixes the following warnings when compiling with gnu++17:
+
+            Source/bmalloc/bmalloc/Scavenger.cpp:363:1: error: function 'threadRunLoop' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
+            {
+            ^
+            Source/bmalloc/bmalloc/Scavenger.cpp:358:1: error: function 'threadEntryPoint' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
+            {
+            ^
+
+        * bmalloc/BCompiler.h:
+        (BCOMPILER): Add support for the BCOMPILER() macro, then add
+        BCOMPILER(GCC_OR_CLANG).  Taken from Source/WTF/wtf/Compiler.h.
+        (BNO_RETURN): Implement 'norerturn' support using the new
+        BCOMPILER() macros.  Taken from Source/WTF/wtf/Compiler.h.
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::threadRunLoop): Remove the workaround that
+        tricked older compilers into thinking the while() loop wasn't
+        infinite.
+        * bmalloc/Scavenger.h:
+        (bmalloc::Scavenger::threadEntryPoint): Add BNO_RETURN attribute.
+        (bmalloc::Scavenger::threadRunLoop): Ditto.
+
+2018-05-29  Saam Barati  <sbarati@apple.com>
+
+        JSC should put bmalloc's scavenger into mini mode
+        https://bugs.webkit.org/show_bug.cgi?id=185988
+
+        Reviewed by Michael Saboff.
+
+        We expose an API for putting bmalloc into mini mode. All that means now
+        is that we'll run the scavenger more aggressively.
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::enableMiniMode):
+        (bmalloc::Scavenger::threadRunLoop):
+        * bmalloc/Scavenger.h:
+        * bmalloc/Sizes.h:
+        * bmalloc/bmalloc.cpp:
+        (bmalloc::api::enableMiniMode):
+        * bmalloc/bmalloc.h:
+
+2018-05-29  Geoffrey Garen  <ggaren@apple.com>
+
+        Fixed the bmalloc build
+        https://bugs.webkit.org/show_bug.cgi?id=186025
+
+        Reviewed by Sam Weinig.
+
+        * bmalloc.xcodeproj/project.pbxproj: Link Foundation because the 
+        gigacage check needs it.
+
+2018-05-23  Antti Koivisto  <antti@apple.com>
+
+        Increase the simulated memory size on PLATFORM(IOS_SIMULATOR) from 512MB to 1024MB
+        https://bugs.webkit.org/show_bug.cgi?id=185908
+
+        Reviewed by Geoffrey Garen.
+
+        We don't support 512MB devices anymore. This will make the simulator behave more
+        like a real device.
+
+        * bmalloc/AvailableMemory.cpp:
+        (bmalloc::memorySizeAccordingToKernel):
+
+        Factor to a function.
+        Don't use availableMemoryGuess for the simulator value as it is not a guess.
+
+        (bmalloc::computeAvailableMemory):
+
+        Apply the same adjustments to the simulated value too.
+
+2018-05-22  Ryan Haddad  <ryanhaddad@apple.com>
+
+        Unreviewed, rolling out r232052.
+
+        Breaks internal builds.
+
+        Reverted changeset:
+
+        "Use more C++17"
+        https://bugs.webkit.org/show_bug.cgi?id=185176
+        https://trac.webkit.org/changeset/232052
+
+2018-05-22  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Define GIGACAGE_ALLOCATION_CAN_FAIL on Linux
+        https://bugs.webkit.org/show_bug.cgi?id=183329
+
+        Reviewed by Michael Catanzaro.
+
+        We specify `GIGACAGE_ALLOCATION_CAN_FAIL 1` in Linux since
+        Linux can fail to `mmap` if `vm.overcommit_memory = 2`.
+        Users can enable Gigacage if users enable overcommit_memory.
+
+        * bmalloc/Gigacage.h:
+
+2018-05-21  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Use more C++17
+        https://bugs.webkit.org/show_bug.cgi?id=185176
+
+        Reviewed by JF Bastien.
+
+        Add BNO_RETURN.
+
+        * Configurations/Base.xcconfig:
+        * bmalloc/BCompiler.h:
+        * bmalloc/Scavenger.h:
+
+2018-05-06  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        [JSC] Remove "using namespace std;" from JSC, bmalloc, WTF
+        https://bugs.webkit.org/show_bug.cgi?id=185362
+
+        Reviewed by Sam Weinig.
+
+        * bmalloc/Allocator.cpp:
+        * bmalloc/Deallocator.cpp:
+
+2018-05-03  Filip Pizlo  <fpizlo@apple.com>
+
+        Strings should not be allocated in a gigacage
+        https://bugs.webkit.org/show_bug.cgi?id=185218
+
+        Reviewed by Saam Barati.
+        
+        This removes the string gigacage.
+        
+        Putting strings in a gigacage prevents read gadgets. The other things that get to be in gigacages
+        are there to prevent read-write gadgets.
+        
+        Also, putting strings in a gigacage seems to have been a bigger regression than putting other
+        things in gigacages.
+        
+        Therefore, to maximize the benefit/cost ratio of gigacages, we should evict strings from them. If
+        we want to throw away perf for security, there are more beneficial things to sacrifice.
+
+        * bmalloc/Gigacage.h:
+        (Gigacage::name):
+        (Gigacage::basePtr):
+        (Gigacage::size):
+        (Gigacage::forEachKind):
+        * bmalloc/HeapKind.h:
+        (bmalloc::isGigacage):
+        (bmalloc::gigacageKind):
+        (bmalloc::heapKind):
+        (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
+        (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
+
+2018-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Use WordLock instead of std::mutex for Threading
+        https://bugs.webkit.org/show_bug.cgi?id=185121
+
+        Reviewed by Geoffrey Garen.
+
+        Add constexpr to explicitly describe that bmalloc::Mutex constructor is constexpr.
+
+        * bmalloc/Mutex.h:
+
+2018-04-23  Ting-Wei Lan  <lantw44@gmail.com>
+
+        Include stdio.h before using stderr
+        https://bugs.webkit.org/show_bug.cgi?id=184872
+
+        Reviewed by Yusuke Suzuki.
+
+        * bmalloc/PerProcess.cpp:
+        * bmalloc/Scavenger.cpp:
+
+2018-04-21  Yusuke Suzuki  <utatane.tea@gmail.com>
+
+        Unreviewed, follow-up patch after r230474
+        https://bugs.webkit.org/show_bug.cgi?id=166684
+
+        Add "JavaScriptCore" to Darwin name. And use short name "BMScavenger"
+        for Linux since adding "JavaScriptCore" makes the name too long for Linux.
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::threadRunLoop):
+
+2018-04-18  Jer Noble  <jer.noble@apple.com>
+
+        Don't put build products into WK_ALTERNATE_WEBKIT_SDK_PATH for engineering builds
+        https://bugs.webkit.org/show_bug.cgi?id=184762
+
+        Reviewed by Dan Bernstein.
+
+        * Configurations/Base.xcconfig:
+
+2018-04-20  Daniel Bates  <dabates@apple.com>
+
+        Remove code for compilers that did not support NSDMI for aggregates
+        https://bugs.webkit.org/show_bug.cgi?id=184599
+
+        Reviewed by Per Arne Vollan.
+
+        Remove workaround for earlier Visual Studio versions that did not support non-static data
+        member initializers (NSDMI) for aggregates. We have since updated all the build.webkit.org
+        and EWS bots to a newer version that supports this feature.
+
+        * bmalloc/BPlatform.h:
+        * bmalloc/List.h:
+        (bmalloc::ListNode::ListNode): Deleted.
+        (bmalloc::List::iterator::iterator): Deleted.
+
+2018-04-19  David Kilzer  <ddkilzer@apple.com>
+
+        Enable Objective-C weak references
+        <https://webkit.org/b/184789>
+        <rdar://problem/39571716>
+
+        Reviewed by Dan Bernstein.
+
+        * Configurations/Base.xcconfig:
+        (CLANG_ENABLE_OBJC_WEAK): Enable.
+
+2018-04-12  Saam Barati  <sbarati@apple.com>
+
+        Lessen partial scavenge interval on x86-64
+        https://bugs.webkit.org/show_bug.cgi?id=184577
+
+        Rubber-stamped by Filip Pizlo.
+
+        I initially made the scavenge interval longer because I had thought the
+        shorter interval caused a JetStream regression. I was mistaken though.
+        I was looking at the wrong commit range when analyzing perf data.
+        
+        This patch shortens the interval, but still keeps x86-64 50% longer than
+        other architectures. We know that scavenging frequently on Mac is less
+        important to overall system performance than it is on iOS.
+
+        * bmalloc/Scavenger.cpp:
+        (bmalloc::Scavenger::threadRunLoop):
+
 2018-04-12  Saam Barati  <sbarati@apple.com>
 
         Raise the partial scavenge interval even more on x86-64