[bmalloc] IsoHeap should have lower tier using shared IsoPage
[WebKit-https.git] / Source / bmalloc / ChangeLog
index d2fbbc4..0b7b18e 100644 (file)
@@ -1,3 +1,217 @@
+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