haikuwebkit/Source/bmalloc/bmalloc/AvailableMemory.cpp

237 lines
7.5 KiB
C++
Raw Permalink Normal View History

[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
/*
* Copyright (C) 2012-2017 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE INC. AND ITS CONTRIBUTORS ``AS IS''
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR ITS CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGE.
*/
#include "AvailableMemory.h"
bmalloc should compute its own estimate of its footprint https://bugs.webkit.org/show_bug.cgi?id=184121 Reviewed by Filip Pizlo. Source/bmalloc: This patch makes it so that bmalloc keeps track of its own physical footprint. Doing this for IsoHeaps is trivial. It allocates/deallocates fixed page sizes at a time. IsoHeapImpl just updates a count every time a page is committed/decommitted. Making Heap keep its footprint was a bit trickier because of how LargeRange is constructed. Before this patch, LargeRange kept track of the amount of physical memory at the start of its range. This patch extends large range to also keep track of the total physical memory in the range just for footprint bookkeeping. This was needed to make Heap's footprint come close to resembling reality, because as we merge and split large ranges, the start physical size often becomes wildly inaccurate. The total physical size number stored in LargeRange is still just an estimate. It's possible that as ranges are split, that the total physical size split amongst the two ranges doesn't resemble reality. This can happen when the total physical size is really all in one end of the split, but we mark it as being proportionally split amongst the resulting two ranges. In practice, I did not notice this being a problem. The footprint estimate tracks reality very closely (in my testing, within less than 1MB for heaps with sizes upwards of 1GB). The other nice thing about total physical size is that even if it diverges from reality in terms of how memory is using up physical RAM, it stays internally consistent inside bmalloc's own data structures. The main oversight of this patch is how it deals with Wasm memory. All Wasm memory will be viewed by bmalloc as taking up physical space even when it may not be. Wasm memory starts off as taking up purely virtual pages. When a page is first accessed, only then will the OS page it in and cause it to use physical RAM. I opened a bug to come up with a solution to this problem: https://bugs.webkit.org/show_bug.cgi?id=184207 * bmalloc.xcodeproj/project.pbxproj: * bmalloc/AvailableMemory.cpp: (bmalloc::memoryStatus): * bmalloc/BPlatform.h: * bmalloc/Heap.cpp: (bmalloc::Heap::Heap): (bmalloc::Heap::freeableMemory): (bmalloc::Heap::footprint): (bmalloc::Heap::scavenge): (bmalloc::Heap::deallocateSmallChunk): (bmalloc::Heap::allocateSmallPage): (bmalloc::Heap::splitAndAllocate): (bmalloc::Heap::tryAllocateLarge): (bmalloc::Heap::shrinkLarge): (bmalloc::Heap::deallocateLarge): (bmalloc::Heap::externalCommit): (bmalloc::Heap::externalDecommit): * bmalloc/Heap.h: * bmalloc/IsoDirectory.h: * bmalloc/IsoDirectoryInlines.h: (bmalloc::passedNumPages>::takeFirstEligible): (bmalloc::passedNumPages>::didDecommit): (bmalloc::passedNumPages>::freeableMemory): * bmalloc/IsoHeapImpl.h: * bmalloc/IsoHeapImplInlines.h: (bmalloc::IsoHeapImpl<Config>::freeableMemory): (bmalloc::IsoHeapImpl<Config>::footprint): (bmalloc::IsoHeapImpl<Config>::didCommit): (bmalloc::IsoHeapImpl<Config>::didDecommit): * bmalloc/LargeRange.h: (bmalloc::LargeRange::LargeRange): (bmalloc::LargeRange::startPhysicalSize const): (bmalloc::LargeRange::setStartPhysicalSize): (bmalloc::LargeRange::totalPhysicalSize const): (bmalloc::LargeRange::setTotalPhysicalSize): (bmalloc::merge): (bmalloc::LargeRange::split const): (bmalloc::LargeRange::physicalSize const): Deleted. (bmalloc::LargeRange::setPhysicalSize): Deleted. * bmalloc/PhysicalPageMap.h: Added. This class is added for debugging purposes. It's useful when hacking on the code that calculates the footprint to use this map as a sanity check. It's just a simple implementation that has a set of all the committed pages. (bmalloc::PhysicalPageMap::commit): (bmalloc::PhysicalPageMap::decommit): (bmalloc::PhysicalPageMap::footprint): (bmalloc::PhysicalPageMap::forEachPhysicalPage): * bmalloc/Scavenger.cpp: (bmalloc::dumpStats): (bmalloc::Scavenger::scavenge): (bmalloc::Scavenger::freeableMemory): This is here just for debugging for now. But we should implement an efficient version of this to use when driving when to run the scavenger. (bmalloc::Scavenger::footprint): (bmalloc::Scavenger::threadRunLoop): * bmalloc/Scavenger.h: * bmalloc/VMAllocate.h: (bmalloc::physicalPageSizeSloppy): * bmalloc/VMHeap.cpp: (bmalloc::VMHeap::tryAllocateLargeChunk): * bmalloc/bmalloc.cpp: (bmalloc::api::commitAlignedPhysical): (bmalloc::api::decommitAlignedPhysical): * bmalloc/bmalloc.h: Source/JavaScriptCore: * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): Source/WTF: * wtf/FastMalloc.cpp: (WTF::fastCommitAlignedMemory): (WTF::fastDecommitAlignedMemory): * wtf/FastMalloc.h: Canonical link: https://commits.webkit.org/199798@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-02 21:09:45 +00:00
#include "Environment.h"
#if BPLATFORM(IOS_FAMILY)
#include "MemoryStatusSPI.h"
#endif
bmalloc should compute its own estimate of its footprint https://bugs.webkit.org/show_bug.cgi?id=184121 Reviewed by Filip Pizlo. Source/bmalloc: This patch makes it so that bmalloc keeps track of its own physical footprint. Doing this for IsoHeaps is trivial. It allocates/deallocates fixed page sizes at a time. IsoHeapImpl just updates a count every time a page is committed/decommitted. Making Heap keep its footprint was a bit trickier because of how LargeRange is constructed. Before this patch, LargeRange kept track of the amount of physical memory at the start of its range. This patch extends large range to also keep track of the total physical memory in the range just for footprint bookkeeping. This was needed to make Heap's footprint come close to resembling reality, because as we merge and split large ranges, the start physical size often becomes wildly inaccurate. The total physical size number stored in LargeRange is still just an estimate. It's possible that as ranges are split, that the total physical size split amongst the two ranges doesn't resemble reality. This can happen when the total physical size is really all in one end of the split, but we mark it as being proportionally split amongst the resulting two ranges. In practice, I did not notice this being a problem. The footprint estimate tracks reality very closely (in my testing, within less than 1MB for heaps with sizes upwards of 1GB). The other nice thing about total physical size is that even if it diverges from reality in terms of how memory is using up physical RAM, it stays internally consistent inside bmalloc's own data structures. The main oversight of this patch is how it deals with Wasm memory. All Wasm memory will be viewed by bmalloc as taking up physical space even when it may not be. Wasm memory starts off as taking up purely virtual pages. When a page is first accessed, only then will the OS page it in and cause it to use physical RAM. I opened a bug to come up with a solution to this problem: https://bugs.webkit.org/show_bug.cgi?id=184207 * bmalloc.xcodeproj/project.pbxproj: * bmalloc/AvailableMemory.cpp: (bmalloc::memoryStatus): * bmalloc/BPlatform.h: * bmalloc/Heap.cpp: (bmalloc::Heap::Heap): (bmalloc::Heap::freeableMemory): (bmalloc::Heap::footprint): (bmalloc::Heap::scavenge): (bmalloc::Heap::deallocateSmallChunk): (bmalloc::Heap::allocateSmallPage): (bmalloc::Heap::splitAndAllocate): (bmalloc::Heap::tryAllocateLarge): (bmalloc::Heap::shrinkLarge): (bmalloc::Heap::deallocateLarge): (bmalloc::Heap::externalCommit): (bmalloc::Heap::externalDecommit): * bmalloc/Heap.h: * bmalloc/IsoDirectory.h: * bmalloc/IsoDirectoryInlines.h: (bmalloc::passedNumPages>::takeFirstEligible): (bmalloc::passedNumPages>::didDecommit): (bmalloc::passedNumPages>::freeableMemory): * bmalloc/IsoHeapImpl.h: * bmalloc/IsoHeapImplInlines.h: (bmalloc::IsoHeapImpl<Config>::freeableMemory): (bmalloc::IsoHeapImpl<Config>::footprint): (bmalloc::IsoHeapImpl<Config>::didCommit): (bmalloc::IsoHeapImpl<Config>::didDecommit): * bmalloc/LargeRange.h: (bmalloc::LargeRange::LargeRange): (bmalloc::LargeRange::startPhysicalSize const): (bmalloc::LargeRange::setStartPhysicalSize): (bmalloc::LargeRange::totalPhysicalSize const): (bmalloc::LargeRange::setTotalPhysicalSize): (bmalloc::merge): (bmalloc::LargeRange::split const): (bmalloc::LargeRange::physicalSize const): Deleted. (bmalloc::LargeRange::setPhysicalSize): Deleted. * bmalloc/PhysicalPageMap.h: Added. This class is added for debugging purposes. It's useful when hacking on the code that calculates the footprint to use this map as a sanity check. It's just a simple implementation that has a set of all the committed pages. (bmalloc::PhysicalPageMap::commit): (bmalloc::PhysicalPageMap::decommit): (bmalloc::PhysicalPageMap::footprint): (bmalloc::PhysicalPageMap::forEachPhysicalPage): * bmalloc/Scavenger.cpp: (bmalloc::dumpStats): (bmalloc::Scavenger::scavenge): (bmalloc::Scavenger::freeableMemory): This is here just for debugging for now. But we should implement an efficient version of this to use when driving when to run the scavenger. (bmalloc::Scavenger::footprint): (bmalloc::Scavenger::threadRunLoop): * bmalloc/Scavenger.h: * bmalloc/VMAllocate.h: (bmalloc::physicalPageSizeSloppy): * bmalloc/VMHeap.cpp: (bmalloc::VMHeap::tryAllocateLargeChunk): * bmalloc/bmalloc.cpp: (bmalloc::api::commitAlignedPhysical): (bmalloc::api::decommitAlignedPhysical): * bmalloc/bmalloc.h: Source/JavaScriptCore: * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): Source/WTF: * wtf/FastMalloc.cpp: (WTF::fastCommitAlignedMemory): (WTF::fastDecommitAlignedMemory): * wtf/FastMalloc.h: Canonical link: https://commits.webkit.org/199798@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2018-04-02 21:09:45 +00:00
#include "PerProcess.h"
#include "Scavenger.h"
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#include "Sizes.h"
#include <array>
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#include <mutex>
#if BOS(DARWIN)
#if BPLATFORM(IOS_FAMILY)
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#import <algorithm>
#endif
#import <dispatch/dispatch.h>
#import <mach/host_info.h>
#import <mach/mach.h>
#import <mach/mach_error.h>
#import <math.h>
#elif BOS(UNIX)
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#if BOS(LINUX)
#include <algorithm>
#include <fcntl.h>
#elif BOS(FREEBSD)
#include "VMAllocate.h"
#include <sys/sysctl.h>
#include <sys/sysinfo.h>
#include <sys/types.h>
#include <sys/user.h>
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#endif
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#include <unistd.h>
#endif
namespace bmalloc {
Use constexpr instead of const in symbol definitions that are obviously constexpr. https://bugs.webkit.org/show_bug.cgi?id=201879 Rubber-stamped by Joseph Pecoraro. Source/bmalloc: * bmalloc/AvailableMemory.cpp: * bmalloc/IsoTLS.h: * bmalloc/Map.h: * bmalloc/Mutex.cpp: (bmalloc::Mutex::lockSlowCase): * bmalloc/PerThread.h: * bmalloc/Vector.h: * bmalloc/Zone.h: Source/JavaScriptCore: const may require external storage (at the compiler's whim) though these currently do not. constexpr makes it clear that the value is a literal constant that can be inlined. In most cases in the code, when we say static const, we actually mean static constexpr. I'm changing the code to reflect this. * API/JSAPIValueWrapper.h: * API/JSCallbackConstructor.h: * API/JSCallbackObject.h: * API/JSContextRef.cpp: * API/JSWrapperMap.mm: * API/tests/CompareAndSwapTest.cpp: * API/tests/TypedArrayCTest.cpp: * API/tests/testapi.mm: (testObjectiveCAPIMain): * KeywordLookupGenerator.py: (Trie.printAsC): * assembler/ARMv7Assembler.h: * assembler/AssemblerBuffer.h: * assembler/AssemblerCommon.h: * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARM64E.h: * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerCodeRef.h: * assembler/MacroAssemblerMIPS.h: * assembler/MacroAssemblerX86.h: * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::absDouble): (JSC::MacroAssemblerX86Common::negateDouble): * assembler/MacroAssemblerX86_64.h: * assembler/X86Assembler.h: * b3/B3Bank.h: * b3/B3CheckSpecial.h: * b3/B3DuplicateTails.cpp: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: * b3/B3FoldPathConstants.cpp: * b3/B3InferSwitches.cpp: * b3/B3Kind.h: * b3/B3LowerToAir.cpp: * b3/B3NativeTraits.h: * b3/B3ReduceDoubleToFloat.cpp: * b3/B3ReduceLoopStrength.cpp: * b3/B3ReduceStrength.cpp: * b3/B3ValueKey.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirAllocateStackByGraphColoring.cpp: * b3/air/AirArg.h: * b3/air/AirCCallSpecial.h: * b3/air/AirEmitShuffle.cpp: * b3/air/AirFixObviousSpills.cpp: * b3/air/AirFormTable.h: * b3/air/AirLowerAfterRegAlloc.cpp: * b3/air/AirPrintSpecial.h: * b3/air/AirStackAllocation.cpp: * b3/air/AirTmp.h: * b3/testb3_6.cpp: (testInterpreter): * bytecode/AccessCase.cpp: * bytecode/CallLinkStatus.cpp: * bytecode/CallVariant.h: * bytecode/CodeBlock.h: * bytecode/CodeOrigin.h: * bytecode/DFGExitProfile.h: * bytecode/DirectEvalCodeCache.h: * bytecode/ExecutableToCodeBlockEdge.h: * bytecode/GetterSetterAccessCase.cpp: * bytecode/LazyOperandValueProfile.h: * bytecode/ObjectPropertyCondition.h: * bytecode/ObjectPropertyConditionSet.cpp: * bytecode/PolymorphicAccess.cpp: * bytecode/PropertyCondition.h: * bytecode/SpeculatedType.h: * bytecode/StructureStubInfo.cpp: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): * bytecode/UnlinkedCodeBlock.h: * bytecode/UnlinkedEvalCodeBlock.h: * bytecode/UnlinkedFunctionCodeBlock.h: * bytecode/UnlinkedFunctionExecutable.h: * bytecode/UnlinkedModuleProgramCodeBlock.h: * bytecode/UnlinkedProgramCodeBlock.h: * bytecode/ValueProfile.h: * bytecode/VirtualRegister.h: * bytecode/Watchpoint.h: * bytecompiler/BytecodeGenerator.h: * bytecompiler/Label.h: * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): * bytecompiler/RegisterID.h: * debugger/Breakpoint.h: * debugger/DebuggerParseData.cpp: * debugger/DebuggerPrimitives.h: * debugger/DebuggerScope.h: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractValue.h: * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCSEPhase.cpp: * dfg/DFGCommon.h: * dfg/DFGCompilationKey.h: * dfg/DFGDesiredGlobalProperty.h: * dfg/DFGEdgeDominates.h: * dfg/DFGEpoch.h: * dfg/DFGForAllKills.h: (JSC::DFG::forAllKilledNodesAtNodeIndex): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * dfg/DFGHeapLocation.h: * dfg/DFGInPlaceAbstractState.cpp: * dfg/DFGIntegerCheckCombiningPhase.cpp: * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGInvalidationPointInjectionPhase.cpp: * dfg/DFGLICMPhase.cpp: * dfg/DFGLazyNode.h: * dfg/DFGMinifiedID.h: * dfg/DFGMovHintRemovalPhase.cpp: * dfg/DFGNodeFlowProjection.h: * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPhantomInsertionPhase.cpp: * dfg/DFGPromotedHeapLocation.h: * dfg/DFGPropertyTypeKey.h: * dfg/DFGPureValue.h: * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGRegisterBank.h: * dfg/DFGSSAConversionPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::compileClampDoubleToByte): (JSC::DFG::SpeculativeJIT::compileArithRounding): (JSC::DFG::compileArithPowIntegerFastPath): (JSC::DFG::SpeculativeJIT::compileArithPow): (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse): * dfg/DFGStackLayoutPhase.cpp: * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGStrengthReductionPhase.cpp: * dfg/DFGStructureAbstractValue.h: * dfg/DFGVarargsForwardingPhase.cpp: * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct const): * dfg/DFGWatchpointCollectionPhase.cpp: * disassembler/ARM64/A64DOpcode.h: * ftl/FTLLocation.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithRandom): * ftl/FTLSlowPathCall.cpp: * ftl/FTLSlowPathCallKey.h: * heap/CellContainer.h: * heap/CellState.h: * heap/ConservativeRoots.h: * heap/GCSegmentedArray.h: * heap/HandleBlock.h: * heap/Heap.cpp: (JSC::Heap::updateAllocationLimits): * heap/Heap.h: * heap/HeapSnapshot.h: * heap/HeapUtil.h: (JSC::HeapUtil::findGCObjectPointersForMarking): * heap/IncrementalSweeper.cpp: * heap/LargeAllocation.h: * heap/MarkedBlock.cpp: * heap/Strong.h: * heap/VisitRaceKey.h: * heap/Weak.h: * heap/WeakBlock.h: * inspector/JSInjectedScriptHost.h: * inspector/JSInjectedScriptHostPrototype.h: * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.h: * inspector/agents/InspectorConsoleAgent.cpp: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator._generate_versions): * inspector/scripts/tests/generic/expected/version.json-result: * interpreter/Interpreter.h: * interpreter/ShadowChicken.cpp: * jit/BinarySwitch.cpp: * jit/CallFrameShuffler.h: * jit/ExecutableAllocator.h: * jit/FPRInfo.h: * jit/GPRInfo.h: * jit/ICStats.h: * jit/JITThunks.h: * jit/Reg.h: * jit/RegisterSet.h: * jit/TempRegisterSet.h: * jsc.cpp: * parser/ASTBuilder.h: * parser/Nodes.h: * parser/SourceCodeKey.h: * parser/SyntaxChecker.h: * parser/VariableEnvironment.h: * profiler/ProfilerOrigin.h: * profiler/ProfilerOriginStack.h: * profiler/ProfilerUID.h: * runtime/AbstractModuleRecord.cpp: * runtime/ArrayBufferNeuteringWatchpointSet.h: * runtime/ArrayConstructor.h: * runtime/ArrayConventions.h: * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.cpp: (JSC::setLength): * runtime/AsyncFromSyncIteratorPrototype.h: * runtime/AsyncGeneratorFunctionPrototype.h: * runtime/AsyncGeneratorPrototype.h: * runtime/AsyncIteratorPrototype.h: * runtime/AtomicsObject.cpp: * runtime/BigIntConstructor.h: * runtime/BigIntPrototype.h: * runtime/BooleanPrototype.h: * runtime/ClonedArguments.h: * runtime/CodeCache.h: * runtime/ControlFlowProfiler.h: * runtime/CustomGetterSetter.h: * runtime/DateConstructor.h: * runtime/DatePrototype.h: * runtime/DefinePropertyAttributes.h: * runtime/ErrorPrototype.h: * runtime/EvalExecutable.h: * runtime/Exception.h: * runtime/ExceptionHelpers.cpp: (JSC::invalidParameterInSourceAppender): (JSC::invalidParameterInstanceofSourceAppender): * runtime/ExceptionHelpers.h: * runtime/ExecutableBase.h: * runtime/FunctionExecutable.h: * runtime/FunctionRareData.h: * runtime/GeneratorPrototype.h: * runtime/GenericArguments.h: * runtime/GenericOffset.h: * runtime/GetPutInfo.h: * runtime/GetterSetter.h: * runtime/GlobalExecutable.h: * runtime/Identifier.h: * runtime/InspectorInstrumentationObject.h: * runtime/InternalFunction.h: * runtime/IntlCollatorConstructor.h: * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormatConstructor.h: * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.h: * runtime/IntlPluralRulesConstructor.h: * runtime/IntlPluralRulesPrototype.h: * runtime/IteratorPrototype.h: * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): * runtime/JSArray.h: * runtime/JSArrayBuffer.h: * runtime/JSArrayBufferView.h: * runtime/JSBigInt.h: * runtime/JSCJSValue.h: * runtime/JSCell.h: * runtime/JSCustomGetterSetterFunction.h: * runtime/JSDataView.h: * runtime/JSDataViewPrototype.h: * runtime/JSDestructibleObject.h: * runtime/JSFixedArray.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSGlobalObject.h: * runtime/JSImmutableButterfly.h: * runtime/JSInternalPromiseConstructor.h: * runtime/JSInternalPromiseDeferred.h: * runtime/JSInternalPromisePrototype.h: * runtime/JSLexicalEnvironment.h: * runtime/JSModuleEnvironment.h: * runtime/JSModuleLoader.h: * runtime/JSModuleNamespaceObject.h: * runtime/JSNonDestructibleProxy.h: * runtime/JSONObject.cpp: * runtime/JSONObject.h: * runtime/JSObject.h: * runtime/JSPromiseConstructor.h: * runtime/JSPromiseDeferred.h: * runtime/JSPromisePrototype.h: * runtime/JSPropertyNameEnumerator.h: * runtime/JSProxy.h: * runtime/JSScope.h: * runtime/JSScriptFetchParameters.h: * runtime/JSScriptFetcher.h: * runtime/JSSegmentedVariableObject.h: * runtime/JSSourceCode.h: * runtime/JSString.cpp: * runtime/JSString.h: * runtime/JSSymbolTableObject.h: * runtime/JSTemplateObjectDescriptor.h: * runtime/JSTypeInfo.h: * runtime/MapPrototype.h: * runtime/MinimumReservedZoneSize.h: * runtime/ModuleProgramExecutable.h: * runtime/NativeExecutable.h: * runtime/NativeFunction.h: * runtime/NativeStdFunctionCell.h: * runtime/NumberConstructor.h: * runtime/NumberPrototype.h: * runtime/ObjectConstructor.h: * runtime/ObjectPrototype.h: * runtime/ProgramExecutable.h: * runtime/PromiseDeferredTimer.cpp: * runtime/PropertyMapHashTable.h: * runtime/PropertyNameArray.h: (JSC::PropertyNameArray::add): * runtime/PrototypeKey.h: * runtime/ProxyConstructor.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): * runtime/ProxyRevoke.h: * runtime/ReflectObject.h: * runtime/RegExp.h: * runtime/RegExpCache.h: * runtime/RegExpConstructor.h: * runtime/RegExpKey.h: * runtime/RegExpObject.h: * runtime/RegExpPrototype.h: * runtime/RegExpStringIteratorPrototype.h: * runtime/SamplingProfiler.cpp: * runtime/ScopedArgumentsTable.h: * runtime/ScriptExecutable.h: * runtime/SetPrototype.h: * runtime/SmallStrings.h: * runtime/SparseArrayValueMap.h: * runtime/StringConstructor.h: * runtime/StringIteratorPrototype.h: * runtime/StringObject.h: * runtime/StringPrototype.h: * runtime/Structure.h: * runtime/StructureChain.h: * runtime/StructureRareData.h: * runtime/StructureTransitionTable.h: * runtime/Symbol.h: * runtime/SymbolConstructor.h: * runtime/SymbolPrototype.h: * runtime/SymbolTable.h: * runtime/TemplateObjectDescriptor.h: * runtime/TypeProfiler.cpp: * runtime/TypeProfiler.h: * runtime/TypeProfilerLog.cpp: * runtime/VarOffset.h: * testRegExp.cpp: * tools/HeapVerifier.cpp: (JSC::HeapVerifier::checkIfRecorded): * tools/JSDollarVM.cpp: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmBBQPlan.cpp: * wasm/WasmFaultSignalHandler.cpp: * wasm/WasmFunctionParser.h: * wasm/WasmOMGForOSREntryPlan.cpp: * wasm/WasmOMGPlan.cpp: * wasm/WasmPlan.cpp: * wasm/WasmSignature.cpp: * wasm/WasmSignature.h: * wasm/WasmWorklist.cpp: * wasm/js/JSWebAssembly.h: * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/WebAssemblyCompileErrorConstructor.h: * wasm/js/WebAssemblyCompileErrorPrototype.h: * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyInstanceConstructor.h: * wasm/js/WebAssemblyInstancePrototype.h: * wasm/js/WebAssemblyLinkErrorConstructor.h: * wasm/js/WebAssemblyLinkErrorPrototype.h: * wasm/js/WebAssemblyMemoryConstructor.h: * wasm/js/WebAssemblyMemoryPrototype.h: * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyModulePrototype.h: * wasm/js/WebAssemblyRuntimeErrorConstructor.h: * wasm/js/WebAssemblyRuntimeErrorPrototype.h: * wasm/js/WebAssemblyTableConstructor.h: * wasm/js/WebAssemblyTablePrototype.h: * wasm/js/WebAssemblyToJSCallee.h: * yarr/Yarr.h: * yarr/YarrParser.h: * yarr/generateYarrCanonicalizeUnicode: Source/WebCore: No new tests. Covered by existing tests. * bindings/js/JSDOMConstructorBase.h: * bindings/js/JSDOMWindowProperties.h: * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): (GeneratePrototypeDeclaration): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: * bindings/scripts/test/JS/JSTestEnabledBySetting.h: * bindings/scripts/test/JS/JSTestEnabledForContext.h: * bindings/scripts/test/JS/JSTestEventTarget.h: * bindings/scripts/test/JS/JSTestGlobalObject.h: * bindings/scripts/test/JS/JSTestIndexedSetterNoIdentifier.h: * bindings/scripts/test/JS/JSTestIndexedSetterThrowingException.h: * bindings/scripts/test/JS/JSTestIndexedSetterWithIdentifier.h: * bindings/scripts/test/JS/JSTestNamedAndIndexedSetterNoIdentifier.h: * bindings/scripts/test/JS/JSTestNamedAndIndexedSetterThrowingException.h: * bindings/scripts/test/JS/JSTestNamedAndIndexedSetterWithIdentifier.h: * bindings/scripts/test/JS/JSTestNamedDeleterNoIdentifier.h: * bindings/scripts/test/JS/JSTestNamedDeleterThrowingException.h: * bindings/scripts/test/JS/JSTestNamedDeleterWithIdentifier.h: * bindings/scripts/test/JS/JSTestNamedDeleterWithIndexedGetter.h: * bindings/scripts/test/JS/JSTestNamedGetterCallWith.h: * bindings/scripts/test/JS/JSTestNamedGetterNoIdentifier.h: * bindings/scripts/test/JS/JSTestNamedGetterWithIdentifier.h: * bindings/scripts/test/JS/JSTestNamedSetterNoIdentifier.h: * bindings/scripts/test/JS/JSTestNamedSetterThrowingException.h: * bindings/scripts/test/JS/JSTestNamedSetterWithIdentifier.h: * bindings/scripts/test/JS/JSTestNamedSetterWithIndexedGetter.h: * bindings/scripts/test/JS/JSTestNamedSetterWithIndexedGetterAndSetter.h: * bindings/scripts/test/JS/JSTestNamedSetterWithOverrideBuiltins.h: * bindings/scripts/test/JS/JSTestNamedSetterWithUnforgableProperties.h: * bindings/scripts/test/JS/JSTestNamedSetterWithUnforgablePropertiesAndOverrideBuiltins.h: * bindings/scripts/test/JS/JSTestObj.h: * bindings/scripts/test/JS/JSTestOverrideBuiltins.h: * bindings/scripts/test/JS/JSTestPluginInterface.h: * bindings/scripts/test/JS/JSTestTypedefs.h: * bridge/objc/objc_runtime.h: * bridge/runtime_array.h: * bridge/runtime_method.h: * bridge/runtime_object.h: Source/WebKit: * WebProcess/Plugins/Netscape/JSNPObject.h: Source/WTF: * wtf/Assertions.cpp: * wtf/AutomaticThread.cpp: * wtf/BitVector.h: * wtf/Bitmap.h: * wtf/BloomFilter.h: * wtf/Brigand.h: * wtf/CheckedArithmetic.h: * wtf/CrossThreadCopier.h: * wtf/CurrentTime.cpp: * wtf/DataLog.cpp: * wtf/DateMath.cpp: (WTF::daysFrom1970ToYear): * wtf/DeferrableRefCounted.h: * wtf/GetPtr.h: * wtf/HashFunctions.h: * wtf/HashMap.h: * wtf/HashTable.h: * wtf/HashTraits.h: * wtf/JSONValues.cpp: * wtf/JSONValues.h: * wtf/ListHashSet.h: * wtf/Lock.h: * wtf/LockAlgorithm.h: * wtf/LockAlgorithmInlines.h: (WTF::Hooks>::lockSlow): * wtf/Logger.h: * wtf/LoggerHelper.h: (WTF::LoggerHelper::childLogIdentifier const): * wtf/MainThread.cpp: * wtf/MetaAllocatorPtr.h: * wtf/MonotonicTime.h: * wtf/NaturalLoops.h: (WTF::NaturalLoops::NaturalLoops): * wtf/ObjectIdentifier.h: * wtf/RAMSize.cpp: * wtf/Ref.h: * wtf/RefPtr.h: * wtf/RetainPtr.h: * wtf/SchedulePair.h: * wtf/StackShot.h: * wtf/StdLibExtras.h: * wtf/TinyPtrSet.h: * wtf/URL.cpp: * wtf/URLHash.h: * wtf/URLParser.cpp: (WTF::URLParser::defaultPortForProtocol): * wtf/Vector.h: * wtf/VectorTraits.h: * wtf/WallTime.h: * wtf/WeakHashSet.h: * wtf/WordLock.h: * wtf/cocoa/CPUTimeCocoa.cpp: * wtf/cocoa/MemoryPressureHandlerCocoa.mm: * wtf/persistence/PersistentDecoder.h: * wtf/persistence/PersistentEncoder.h: * wtf/text/AtomStringHash.h: * wtf/text/CString.h: * wtf/text/StringBuilder.cpp: (WTF::expandedCapacity): * wtf/text/StringHash.h: * wtf/text/StringImpl.h: * wtf/text/StringToIntegerConversion.h: (WTF::toIntegralType): * wtf/text/SymbolRegistry.h: * wtf/text/TextStream.cpp: (WTF::hasFractions): * wtf/text/WTFString.h: * wtf/text/cocoa/TextBreakIteratorInternalICUCocoa.cpp: Canonical link: https://commits.webkit.org/215538@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250005 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-09-18 00:36:19 +00:00
static constexpr size_t availableMemoryGuess = 512 * bmalloc::MB;
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#if BOS(DARWIN)
static size_t memorySizeAccordingToKernel()
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
{
#if BPLATFORM(IOS_FAMILY_SIMULATOR)
BUNUSED_PARAM(availableMemoryGuess);
// Pretend we have 1024MB of memory to make cache sizes behave like on device.
return 1024 * bmalloc::MB;
#else
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
host_basic_info_data_t hostInfo;
mach_port_t host = mach_host_self();
mach_msg_type_number_t count = HOST_BASIC_INFO_COUNT;
kern_return_t r = host_info(host, HOST_BASIC_INFO, (host_info_t)&hostInfo, &count);
mach_port_deallocate(mach_task_self(), host);
if (r != KERN_SUCCESS)
return availableMemoryGuess;
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
if (hostInfo.max_mem > std::numeric_limits<size_t>::max())
return std::numeric_limits<size_t>::max();
return static_cast<size_t>(hostInfo.max_mem);
#endif
}
#endif
#if BPLATFORM(IOS_FAMILY)
static size_t jetsamLimit()
{
memorystatus_memlimit_properties_t properties;
pid_t pid = getpid();
if (memorystatus_control(MEMORYSTATUS_CMD_GET_MEMLIMIT_PROPERTIES, pid, 0, &properties, sizeof(properties)))
return 840 * bmalloc::MB;
if (properties.memlimit_active < 0)
return std::numeric_limits<size_t>::max();
return static_cast<size_t>(properties.memlimit_active) * bmalloc::MB;
}
#endif
#if BOS(LINUX)
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
struct LinuxMemory {
static const LinuxMemory& singleton()
{
static LinuxMemory s_singleton;
static std::once_flag s_onceFlag;
std::call_once(s_onceFlag,
[] {
long numPages = sysconf(_SC_PHYS_PAGES);
s_singleton.pageSize = sysconf(_SC_PAGE_SIZE);
if (numPages == -1 || s_singleton.pageSize == -1)
s_singleton.availableMemory = availableMemoryGuess;
else
s_singleton.availableMemory = numPages * s_singleton.pageSize;
s_singleton.statmFd = open("/proc/self/statm", O_RDONLY | O_CLOEXEC);
});
return s_singleton;
}
size_t footprint() const
{
if (statmFd == -1)
return 0;
std::array<char, 256> statmBuffer;
ssize_t numBytes = pread(statmFd, statmBuffer.data(), statmBuffer.size(), 0);
if (numBytes <= 0)
return 0;
std::array<char, 32> rssBuffer;
{
auto begin = std::find(statmBuffer.begin(), statmBuffer.end(), ' ');
if (begin == statmBuffer.end())
return 0;
std::advance(begin, 1);
auto end = std::find(begin, statmBuffer.end(), ' ');
if (end == statmBuffer.end())
return 0;
auto last = std::copy_n(begin, std::min<size_t>(31, std::distance(begin, end)), rssBuffer.begin());
*last = '\0';
}
unsigned long dirtyPages = strtoul(rssBuffer.data(), nullptr, 10);
return dirtyPages * pageSize;
}
long pageSize { 0 };
size_t availableMemory { 0 };
int statmFd { -1 };
};
#endif
static size_t computeAvailableMemory()
{
#if BOS(DARWIN)
size_t sizeAccordingToKernel = memorySizeAccordingToKernel();
#if BPLATFORM(IOS_FAMILY)
sizeAccordingToKernel = std::min(sizeAccordingToKernel, jetsamLimit());
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#endif
size_t multiple = 128 * bmalloc::MB;
// Round up the memory size to a multiple of 128MB because max_mem may not be exactly 512MB
// (for example) and we have code that depends on those boundaries.
return ((sizeAccordingToKernel + multiple - 1) / multiple) * multiple;
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#elif BOS(LINUX)
return LinuxMemory::singleton().availableMemory;
#elif BOS(FREEBSD)
struct sysinfo info;
if (!sysinfo(&info))
return info.totalram * info.mem_unit;
return availableMemoryGuess;
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
#elif BOS(UNIX)
long pages = sysconf(_SC_PHYS_PAGES);
long pageSize = sysconf(_SC_PAGE_SIZE);
if (pages == -1 || pageSize == -1)
return availableMemoryGuess;
return pages * pageSize;
#else
return availableMemoryGuess;
#endif
}
size_t availableMemory()
{
static size_t availableMemory;
static std::once_flag onceFlag;
std::call_once(onceFlag, [] {
availableMemory = computeAvailableMemory();
});
return availableMemory;
}
#if BPLATFORM(IOS_FAMILY) || BOS(LINUX) || BOS(FREEBSD)
MemoryStatus memoryStatus()
{
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#if BPLATFORM(IOS_FAMILY)
task_vm_info_data_t vmInfo;
mach_msg_type_number_t vmSize = TASK_VM_INFO_COUNT;
size_t memoryFootprint = 0;
if (KERN_SUCCESS == task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)(&vmInfo), &vmSize))
memoryFootprint = static_cast<size_t>(vmInfo.phys_footprint);
double percentInUse = static_cast<double>(memoryFootprint) / static_cast<double>(availableMemory());
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#elif BOS(LINUX)
auto& memory = LinuxMemory::singleton();
size_t memoryFootprint = memory.footprint();
double percentInUse = static_cast<double>(memoryFootprint) / static_cast<double>(memory.availableMemory);
#elif BOS(FREEBSD)
struct kinfo_proc info;
size_t infolen = sizeof(info);
int mib[4];
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = KERN_PROC_PID;
mib[3] = getpid();
size_t memoryFootprint = 0;
if (!sysctl(mib, 4, &info, &infolen, nullptr, 0))
memoryFootprint = static_cast<size_t>(info.ki_rssize) * vmPageSize();
double percentInUse = static_cast<double>(memoryFootprint) / static_cast<double>(availableMemory());
[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: Canonical link: https://commits.webkit.org/211152@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244244 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-04-14 06:46:17 +00:00
#endif
double percentAvailableMemoryInUse = std::min(percentInUse, 1.0);
return MemoryStatus(memoryFootprint, percentAvailableMemoryInUse);
}
#endif
[iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. Source/bmalloc: 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. Source/JavaScriptCore: This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: Source/WTF: Moved the non-Windows implementation of RAMSize() to bmalloc/AvailableMemory.cpp and called the function availableMemory(). * wtf/RAMSize.cpp: (WTF::computeRAMSize): Canonical link: https://commits.webkit.org/188967@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@216763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-05-12 14:15:08 +00:00
} // namespace bmalloc