2011-02-15 23:54:06 +00:00
|
|
|
/*
|
2016-01-26 08:17:31 +00:00
|
|
|
* Copyright (C) 2011, 2016 Apple Inc. All rights reserved.
|
2011-02-15 23:54:06 +00:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
// A SentinelLinkedList is a linked list with dummy head and tail sentinels,
|
|
|
|
// which allow for branch-less insertion and removal, and removal without a
|
|
|
|
// pointer to the list.
|
|
|
|
//
|
|
|
|
// Requires: Node is a concrete class with:
|
|
|
|
// Node(SentinelTag);
|
|
|
|
// void setPrev(Node*);
|
|
|
|
// Node* prev();
|
|
|
|
// void setNext(Node*);
|
|
|
|
// Node* next();
|
|
|
|
|
2018-10-15 14:24:49 +00:00
|
|
|
#pragma once
|
2011-02-15 23:54:06 +00:00
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
#include <wtf/Packed.h>
|
|
|
|
|
2011-02-15 23:54:06 +00:00
|
|
|
namespace WTF {
|
|
|
|
|
|
|
|
enum SentinelTag { Sentinel };
|
|
|
|
|
2020-10-26 20:08:01 +00:00
|
|
|
template<typename T, typename PassedPtrTraits = RawPtrTraits<T>>
|
2011-09-06 09:23:55 +00:00
|
|
|
class BasicRawSentinelNode {
|
2015-07-30 16:25:36 +00:00
|
|
|
WTF_MAKE_FAST_ALLOCATED;
|
2011-02-15 23:54:06 +00:00
|
|
|
public:
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
using PtrTraits = typename PassedPtrTraits::template RebindTraits<BasicRawSentinelNode>;
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
BasicRawSentinelNode(SentinelTag)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
BasicRawSentinelNode() = default;
|
2011-09-06 09:23:55 +00:00
|
|
|
|
|
|
|
void setPrev(BasicRawSentinelNode* prev) { m_prev = prev; }
|
|
|
|
void setNext(BasicRawSentinelNode* next) { m_next = next; }
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
T* prev() { return static_cast<T*>(PtrTraits::unwrap(m_prev)); }
|
|
|
|
T* next() { return static_cast<T*>(PtrTraits::unwrap(m_next)); }
|
2011-09-06 09:23:55 +00:00
|
|
|
|
|
|
|
bool isOnList() const
|
|
|
|
{
|
|
|
|
ASSERT(!!m_prev == !!m_next);
|
|
|
|
return !!m_prev;
|
|
|
|
}
|
|
|
|
|
|
|
|
void remove();
|
2016-01-26 08:17:31 +00:00
|
|
|
|
|
|
|
void prepend(BasicRawSentinelNode*);
|
|
|
|
void append(BasicRawSentinelNode*);
|
2011-09-06 09:23:55 +00:00
|
|
|
|
|
|
|
private:
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
typename PtrTraits::StorageType m_next { nullptr };
|
|
|
|
typename PtrTraits::StorageType m_prev { nullptr };
|
2011-09-06 09:23:55 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
template <typename T, typename RawNode = T> class SentinelLinkedList {
|
|
|
|
public:
|
|
|
|
typedef T* iterator;
|
2011-02-15 23:54:06 +00:00
|
|
|
|
|
|
|
SentinelLinkedList();
|
|
|
|
|
2016-01-26 08:17:31 +00:00
|
|
|
// Pushes to the front of the list. It's totally backwards from what you'd expect.
|
2011-09-06 09:23:55 +00:00
|
|
|
void push(T*);
|
2016-01-26 08:17:31 +00:00
|
|
|
|
|
|
|
// Appends to the end of the list.
|
|
|
|
void append(T*);
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
static void remove(T*);
|
2016-01-26 08:17:31 +00:00
|
|
|
static void prepend(T* existingNode, T* newNode);
|
|
|
|
static void append(T* existingNode, T* newNode);
|
2012-11-21 02:34:46 +00:00
|
|
|
|
|
|
|
bool isOnList(T*);
|
2011-02-15 23:54:06 +00:00
|
|
|
|
|
|
|
iterator begin();
|
|
|
|
iterator end();
|
JSC should be a triple-tier VM
https://bugs.webkit.org/show_bug.cgi?id=75812
<rdar://problem/10079694>
Source/JavaScriptCore:
Reviewed by Gavin Barraclough.
Implemented an interpreter that uses the JIT's calling convention. This
interpreter is called LLInt, or the Low Level Interpreter. JSC will now
will start by executing code in LLInt and will only tier up to the old
JIT after the code is proven hot.
LLInt is written in a modified form of our macro assembly. This new macro
assembly is compiled by an offline assembler (see offlineasm), which
implements many modern conveniences such as a Turing-complete CPS-based
macro language and direct access to relevant C++ type information
(basically offsets of fields and sizes of structs/classes).
Code executing in LLInt appears to the rest of the JSC world "as if" it
were executing in the old JIT. Hence, things like exception handling and
cross-execution-engine calls just work and require pretty much no
additional overhead.
This interpreter is 2-2.5x faster than our old interpreter on SunSpider,
V8, and Kraken. With triple-tiering turned on, we're neutral on SunSpider,
V8, and Kraken, but appear to get a double-digit improvement on real-world
websites due to a huge reduction in the amount of JIT'ing.
* CMakeLists.txt:
* GNUmakefile.am:
* GNUmakefile.list.am:
* JavaScriptCore.pri:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
* JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* assembler/LinkBuffer.h:
* assembler/MacroAssemblerCodeRef.h:
(MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* bytecode/BytecodeConventions.h: Added.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
(JSC):
(JSC::CallLinkStatus::computeFor):
* bytecode/CallLinkStatus.h:
(JSC::CallLinkStatus::isSet):
(JSC::CallLinkStatus::operator!):
(CallLinkStatus):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dump):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC):
(JSC::CodeBlock::unlinkCalls):
(JSC::CodeBlock::unlinkIncomingCalls):
(JSC::CodeBlock::bytecodeOffset):
(JSC::ProgramCodeBlock::jettison):
(JSC::EvalCodeBlock::jettison):
(JSC::FunctionCodeBlock::jettison):
(JSC::ProgramCodeBlock::jitCompileImpl):
(JSC::EvalCodeBlock::jitCompileImpl):
(JSC::FunctionCodeBlock::jitCompileImpl):
* bytecode/CodeBlock.h:
(JSC):
(CodeBlock):
(JSC::CodeBlock::baselineVersion):
(JSC::CodeBlock::linkIncomingCall):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::jitCompile):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::CodeBlock::addPropertyAccessInstruction):
(JSC::CodeBlock::addGlobalResolveInstruction):
(JSC::CodeBlock::addLLIntCallLinkInfo):
(JSC::CodeBlock::addGlobalResolveInfo):
(JSC::CodeBlock::numberOfMethodCallLinkInfos):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::likelyToTakeSlowCase):
(JSC::CodeBlock::couldTakeSlowCase):
(JSC::CodeBlock::likelyToTakeSpecialFastCase):
(JSC::CodeBlock::likelyToTakeDeepestSlowCase):
(JSC::CodeBlock::likelyToTakeAnySlowCase):
(JSC::CodeBlock::addFrequentExitSite):
(JSC::CodeBlock::dontJITAnytimeSoon):
(JSC::CodeBlock::jitAfterWarmUp):
(JSC::CodeBlock::jitSoon):
(JSC::CodeBlock::llintExecuteCounter):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::wasSeenInJIT):
(GetByIdStatus):
* bytecode/Instruction.h:
(JSC):
(JSC::Instruction::Instruction):
(Instruction):
* bytecode/LLIntCallLinkInfo.h: Added.
(JSC):
(JSC::LLIntCallLinkInfo::LLIntCallLinkInfo):
(LLIntCallLinkInfo):
(JSC::LLIntCallLinkInfo::~LLIntCallLinkInfo):
(JSC::LLIntCallLinkInfo::isLinked):
(JSC::LLIntCallLinkInfo::unlink):
* bytecode/MethodCallLinkStatus.cpp:
(JSC::MethodCallLinkStatus::computeFor):
* bytecode/Opcode.cpp:
(JSC):
* bytecode/Opcode.h:
(JSC):
(JSC::padOpcodeName):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
(PutByIdStatus):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitResolve):
(JSC::BytecodeGenerator::emitResolveWithBase):
(JSC::BytecodeGenerator::emitGetById):
(JSC::BytecodeGenerator::emitPutById):
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitCatch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOperations.cpp:
* heap/Heap.h:
(JSC):
(JSC::Heap::firstAllocatorWithoutDestructors):
(Heap):
* heap/MarkStack.cpp:
(JSC::visitChildren):
* heap/MarkedAllocator.h:
(JSC):
(MarkedAllocator):
* heap/MarkedSpace.h:
(JSC):
(MarkedSpace):
(JSC::MarkedSpace::firstAllocator):
* interpreter/CallFrame.cpp:
(JSC):
(JSC::CallFrame::bytecodeOffsetForNonDFGCode):
(JSC::CallFrame::setBytecodeOffsetForNonDFGCode):
(JSC::CallFrame::currentVPC):
(JSC::CallFrame::setCurrentVPC):
(JSC::CallFrame::trueCallerFrame):
* interpreter/CallFrame.h:
(JSC::ExecState::hasReturnPC):
(JSC::ExecState::clearReturnPC):
(ExecState):
(JSC::ExecState::bytecodeOffsetForNonDFGCode):
(JSC::ExecState::currentVPC):
(JSC::ExecState::setCurrentVPC):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::Interpreter):
(JSC::Interpreter::~Interpreter):
(JSC):
(JSC::Interpreter::initialize):
(JSC::Interpreter::isOpcode):
(JSC::Interpreter::unwindCallFrame):
(JSC::getCallerInfo):
(JSC::Interpreter::privateExecute):
(JSC::Interpreter::retrieveLastCaller):
* interpreter/Interpreter.h:
(JSC):
(Interpreter):
(JSC::Interpreter::getOpcode):
(JSC::Interpreter::getOpcodeID):
(JSC::Interpreter::classicEnabled):
* interpreter/RegisterFile.h:
(JSC):
(RegisterFile):
* jit/ExecutableAllocator.h:
(JSC):
* jit/HostCallReturnValue.cpp: Added.
(JSC):
(JSC::getHostCallReturnValueWithExecState):
* jit/HostCallReturnValue.h: Added.
(JSC):
(JSC::initializeHostCallReturnValue):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::privateCompile):
* jit/JITCode.h:
(JSC::JITCode::isOptimizingJIT):
(JITCode):
(JSC::JITCode::isBaselineCode):
(JSC::JITCode::JITCode):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITExceptions.cpp:
(JSC::jitThrow):
* jit/JITInlineMethods.h:
(JSC::JIT::updateTopCallFrame):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
(JSC):
* jit/JITStubs.h:
(JSC):
* jit/JSInterfaceJIT.h:
* llint: Added.
* llint/LLIntCommon.h: Added.
* llint/LLIntData.cpp: Added.
(LLInt):
(JSC::LLInt::Data::Data):
(JSC::LLInt::Data::performAssertions):
(JSC::LLInt::Data::~Data):
* llint/LLIntData.h: Added.
(JSC):
(LLInt):
(Data):
(JSC::LLInt::Data::exceptionInstructions):
(JSC::LLInt::Data::opcodeMap):
(JSC::LLInt::Data::performAssertions):
* llint/LLIntEntrypoints.cpp: Added.
(LLInt):
(JSC::LLInt::getFunctionEntrypoint):
(JSC::LLInt::getEvalEntrypoint):
(JSC::LLInt::getProgramEntrypoint):
* llint/LLIntEntrypoints.h: Added.
(JSC):
(LLInt):
(JSC::LLInt::getEntrypoint):
* llint/LLIntExceptions.cpp: Added.
(LLInt):
(JSC::LLInt::interpreterThrowInCaller):
(JSC::LLInt::returnToThrowForThrownException):
(JSC::LLInt::returnToThrow):
(JSC::LLInt::callToThrow):
* llint/LLIntExceptions.h: Added.
(JSC):
(LLInt):
* llint/LLIntOfflineAsmConfig.h: Added.
* llint/LLIntOffsetsExtractor.cpp: Added.
(JSC):
(LLIntOffsetsExtractor):
(JSC::LLIntOffsetsExtractor::dummy):
(main):
* llint/LLIntSlowPaths.cpp: Added.
(LLInt):
(JSC::LLInt::llint_trace_operand):
(JSC::LLInt::llint_trace_value):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::traceFunctionPrologue):
(JSC::LLInt::shouldJIT):
(JSC::LLInt::entryOSR):
(JSC::LLInt::resolveGlobal):
(JSC::LLInt::getByVal):
(JSC::LLInt::handleHostCall):
(JSC::LLInt::setUpCall):
(JSC::LLInt::genericCall):
* llint/LLIntSlowPaths.h: Added.
(JSC):
(LLInt):
* llint/LLIntThunks.cpp: Added.
(LLInt):
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::functionForCallEntryThunkGenerator):
(JSC::LLInt::functionForConstructEntryThunkGenerator):
(JSC::LLInt::functionForCallArityCheckThunkGenerator):
(JSC::LLInt::functionForConstructArityCheckThunkGenerator):
(JSC::LLInt::evalEntryThunkGenerator):
(JSC::LLInt::programEntryThunkGenerator):
* llint/LLIntThunks.h: Added.
(JSC):
(LLInt):
* llint/LowLevelInterpreter.asm: Added.
* llint/LowLevelInterpreter.cpp: Added.
* llint/LowLevelInterpreter.h: Added.
* offlineasm: Added.
* offlineasm/armv7.rb: Added.
* offlineasm/asm.rb: Added.
* offlineasm/ast.rb: Added.
* offlineasm/backends.rb: Added.
* offlineasm/generate_offset_extractor.rb: Added.
* offlineasm/instructions.rb: Added.
* offlineasm/offset_extractor_constants.rb: Added.
* offlineasm/offsets.rb: Added.
* offlineasm/opt.rb: Added.
* offlineasm/parser.rb: Added.
* offlineasm/registers.rb: Added.
* offlineasm/self_hash.rb: Added.
* offlineasm/settings.rb: Added.
* offlineasm/transform.rb: Added.
* offlineasm/x86.rb: Added.
* runtime/CodeSpecializationKind.h: Added.
(JSC):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
(CommonSlowPaths):
* runtime/Executable.cpp:
(JSC::jettisonCodeBlock):
(JSC):
(JSC::EvalExecutable::jitCompile):
(JSC::samplingDescription):
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::jitCompile):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::baselineCodeBlockFor):
(JSC::FunctionExecutable::jitCompileForCall):
(JSC::FunctionExecutable::jitCompileForConstruct):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(JSC):
(EvalExecutable):
(ProgramExecutable):
(FunctionExecutable):
(JSC::FunctionExecutable::jitCompileFor):
* runtime/ExecutionHarness.h: Added.
(JSC):
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
* runtime/JSArray.h:
(JSC):
(JSArray):
* runtime/JSCell.h:
(JSC):
(JSCell):
* runtime/JSFunction.h:
(JSC):
(JSFunction):
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::JSGlobalData):
* runtime/JSGlobalData.h:
(JSC):
(JSGlobalData):
* runtime/JSGlobalObject.h:
(JSC):
(JSGlobalObject):
* runtime/JSObject.h:
(JSC):
(JSObject):
(JSFinalObject):
* runtime/JSPropertyNameIterator.h:
(JSC):
(JSPropertyNameIterator):
* runtime/JSString.h:
(JSC):
(JSString):
* runtime/JSTypeInfo.h:
(JSC):
(TypeInfo):
* runtime/JSValue.cpp:
(JSC::JSValue::description):
* runtime/JSValue.h:
(LLInt):
(JSValue):
* runtime/JSVariableObject.h:
(JSC):
(JSVariableObject):
* runtime/Options.cpp:
(Options):
(JSC::Options::initializeOptions):
* runtime/Options.h:
(Options):
* runtime/ScopeChain.h:
(JSC):
(ScopeChainNode):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransition):
* runtime/Structure.h:
(JSC):
(Structure):
* runtime/StructureChain.h:
(JSC):
(StructureChain):
* wtf/InlineASM.h:
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(SentinelLinkedList):
(WTF::SentinelLinkedList::isEmpty):
* wtf/text/StringImpl.h:
(JSC):
(StringImpl):
Source/WebCore:
Reviewed by Gavin Barraclough.
No new tests, because there is no change in behavior.
* CMakeLists.txt:
Source/WebKit:
Reviewed by Gavin Barraclough.
Changed EFL's build system to include a new directory in JavaScriptCore.
* CMakeLists.txt:
Tools:
Reviewed by Gavin Barraclough.
Changed EFL's build system to include a new directory in JavaScriptCore.
* DumpRenderTree/efl/CMakeLists.txt:
Canonical link: https://commits.webkit.org/96248@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@108444 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2012-02-22 05:23:19 +00:00
|
|
|
|
|
|
|
bool isEmpty() { return begin() == end(); }
|
Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
https://bugs.webkit.org/show_bug.cgi?id=160125
Reviewed by Geoffrey Garen and Keith Miller.
JSTests:
Most of the things I did properly covered by existing tests, but I found some simple cases of
unshifting that had sketchy coverage.
* stress/array-storage-array-unshift.js: Added.
* stress/contiguous-array-unshift.js: Added.
* stress/double-array-unshift.js: Added.
* stress/int32-array-unshift.js: Added.
Source/bmalloc:
I needed to tryMemalign, so I added such a thing.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::allocate):
(bmalloc::Allocator::tryAllocate):
(bmalloc::Allocator::allocateImpl):
* bmalloc/Allocator.h:
* bmalloc/Cache.h:
(bmalloc::Cache::tryAllocate):
* bmalloc/bmalloc.h:
(bmalloc::api::tryMemalign):
Source/JavaScriptCore:
In order to make the GC concurrent (bug 149432), we would either need to enable concurrent
copying or we would need to not copy. Concurrent copying carries a 1-2% throughput overhead
from the barriers alone. Considering that MarkedSpace does a decent job of avoiding
fragmentation, it's unlikely that it's worth paying 1-2% throughput for copying. So, we want
to get rid of copied space. This change moves copied space's biggest client over to marked
space.
Moving butterflies to marked space means having them use the new Auxiliary HeapCell
allocation path. This is a fairly mechanical change, but it caused performance regressions
everywhere, so this change also fixes MarkedSpace's performance issues.
At a high level the mechanical changes are:
- We use AuxiliaryBarrier instead of CopyBarrier.
- We use tryAllocateAuxiliary instead of tryAllocateStorage. I got rid of the silly
CheckedBoolean stuff, since it's so much more trouble than it's worth.
- The JITs have to emit inlined marked space allocations instead of inline copy space
allocations.
- Everyone has to get used to zeroing their butterflies after allocation instead of relying
on them being pre-zeroed by the GC. Copied space would zero things for you, while marked
space doesn't.
That's about 1/3 of this change. But this led to performance problems, which I fixed with
optimizations that amounted to a major MarkedSpace rewrite:
- MarkedSpace always causes internal fragmentation for array allocations because the vector
length we choose when we resize usually leads to a cell size that doesn't correspond to any
size class. I got around this by making array allocations usually round up vectorLength to
the maximum allowed by the size class that we would have allocated in. Also,
ensureLengthSlow() and friends first make sure that the requested length can't just be
fulfilled with the current allocation size. This safeguard means that not every array
allocation has to do size class queries. For example, the fast path of new Array(length)
never does any size class queries, under the assumption that (1) the speed gained from
avoiding an ensureLengthSlow() call, which then just changes the vectorLength by doing the
size class query, is too small to offset the speed lost by doing the query on every
allocation and (2) new Array(length) is a pretty good hint that resizing is not very
likely.
- Size classes in MarkedSpace were way too precise, which led to external fragmentation. This
changes MarkedSpace size classes to use a linear progression for very small sizes followed
by a geometric progression that naturally transitions to a hyperbolic progression. We want
hyperbolic sizes when we get close to blockSize: for example the largest size we want is
payloadSize / 2 rounded down, to ensure we get exactly two cells with minimal slop. The
next size down should be payloadSize / 3 rounded down, and so on. After the last precise
size (80 bytes), we proceed using a geometric progression, but round up each size to
minimize slop at the end of the block. This naturally causes the geometric progression to
turn hyperbolic for large sizes. The size class configuration happens at VM start-up, so
it can be controlled with runtime options. I found that a base of 1.4 works pretty well.
- Large allocations caused massive internal fragmentation, since the smallest large
allocation had to use exactly blockSize, and the largest small allocation used
blockSize / 2. The next size up - the first large allocation size to require two blocks -
also had 50% internal fragmentation. This is because we required large allocations to be
blockSize aligned, so that MarkedBlock::blockFor() would work. I decided to rewrite all of
that. Cells no longer have to be owned by a MarkedBlock. They can now alternatively be
owned by a LargeAllocation. These two things are abstracted as CellContainer. You know that
a cell is owned by a LargeAllocation if the MarkedBlock::atomSize / 2 bit is set.
Basically, large allocations are deliberately misaligned by 8 bytes. This actually works
out great since (1) typed arrays won't use large allocations anyway since they have their
own malloc fallback and (2) large array butterflies already have a 8 byte header, which
means that the 8 byte base misalignment aligns the large array payload on a 16 byte
boundary. I took extreme care to make sure that the isLargeAllocation bit checks are as
rare as possible; for example, ExecState::vm() skips the check because we know that callees
must be small allocations. It's also possible to use template tricks to do one check for
cell container kind, and then invoke a function specialized for MarkedBlock or a function
specialized for LargeAllocation. LargeAllocation includes stubs for all MarkedBlock methods
that get used from functions that are template-specialized like this. That's mostly to
speed up the GC marking code. Most other code can use CellContainer API or HeapCell API
directly. That's another thing: HeapCell, the common base of JSCell and auxiliary
allocations, is now smart enough to do a lot of things for you, like HeapCell::vm(),
HeapCell::heap(), HeapCell::isLargeAllocation(), and HeapCell::cellContainer(). The size
cutoff for large allocations is runtime-configurable, so long as you don't choose something
so small that callees end up large. I found that 400 bytes is roughly optimal. This means
that the MarkedBlock size classes end up being:
16, 32, 48, 64, 80, 112, 160, 224, 320
The next size class would have been 432, but that's above the 400 byte cutoff. All of this
is configurable with --sizeClassProgression and --largeAllocationCutoff. You can see what
size classes you end up with by doing --dumpSizeClasses=true.
- Copied space uses 64KB blocks, while marked space used to use 16KB blocks. Allocating a lot
of stuff in 16KB blocks was slower than allocating it in 64KB blocks because the GC had a
lot of per-block overhead. I removed this overhead: It's now 2x faster to scan all
MarkedBlocks because the list that contains the interesting meta-data is allocated on the
side, for better locality during a sequential walk. It's no longer necessary to scan
MarkedBlocks to find WeakSets, since the sets of WeakSets for eden scan and full scan are
maintained on-the-fly. It's no longer necessary to scan all MarkedBlocks to clear mark
bits because we now use versioned mark bits: to clear then, just increment the 64-bit
heap version. It's no longer necessary to scan retired MarkedBlocks while allocating
because marking retires them on-the-fly. It's no longer necessary to sort all blocks in
the IncrementalSweeper's snapshot because blocks now know if they are in the snapshot. Put
together, these optimizations allowed me to reduce block size to 16KB without losing much
performance. There is some small perf loss on JetStream/splay, but not enough to hurt
JetStream overall. I tried reducing block sizes further, to 4KB, since that is a
progression on membuster. That's not possible yet, since there is still enough per-block
overhead yet that such a reduction hurts JetStream too much. I filed a bug about improving
this further: https://bugs.webkit.org/show_bug.cgi?id=161581.
- Even after all of that, copying butterflies was still faster because it allowed us to skip
sweeping dead space. A good GC allocates over dead bytes without explicitly freeing them,
so the GC pause is O(size of live), not O(size of live + dead). O(dead) is usually much
larger than O(live), especially in an eden collection. Copying satisfies this premise while
mark+sweep does not. So, I invented a new kind of allocator: bump'n'pop. Previously, our
MarkedSpace allocator was a freelist pop. That's simple and easy to inline but requires
that we walk the block to build a free list. This means walking dead space. The new
allocator allows totally free MarkedBlocks to simply set up a bump-pointer arena instead.
The allocator is a hybrid of bump-pointer and freelist pop. It tries bump first. The bump
pointer always bumps by cellSize, so the result of filling a block with bumping looks as if
we had used freelist popping to fill it. Additionally, each MarkedBlock now has a bit to
quickly tell if the block is entirely free. This makes sweeping O(1) whenever a MarkedBlock
is completely empty, which is the common case because of the generational hypothesis: the
number of objects that survive an eden collection is a tiny fraction of the number of
objects that had been allocated, and this fraction is so small that there are typically
fewer than one survivors per MarkedBlock. This change was enough to make this change a net
win over tip-of-tree.
- FTL now shares the same allocation fast paths as everything else, which is great, because
bump'n'pop has gnarly control flow. We don't really want B3 to have to think about that
control flow, since it won't be able to improve the machine code we write ourselves. GC
fast paths are best written in assembly. So, I've empowered B3 to have even better support
for Patchpoint terminals. It's now totally fine for a Patchpoint terminal to be non-Void.
So, the new FTL allocation fast paths are just Patchpoint terminals that call through to
AssemblyHelpers::emitAllocate(). B3 still reasons about things like constant-folding the
size class calculation and constant-hoisting the allocator. Also, I gave the FTL the
ability to constant-fold some allocator logic (in case we first assume that we're doing a
variable-length allocation but then realize that the length is known). I think it makes
sense to have constant folding rules in FTL::Output, or whatever the B3 IR builder is,
since this makes lowering easier (you can constant fold during lowering more easily) and it
reduces the amount of malloc traffic. In the future, we could teach B3 how to better
constant-fold this code. That would require allowing loads to be constant-folded, which is
doable but hella tricky.
- It used to be that if a logical object allocation required two physical allocations (first
the butterfly and then the cell), then the JIT would emit the code in such a way that a
failure in the second fast path would cause us to forget the successful first physical
allocation. This was pointlessly wasteful. It turns out that it's very cheap to devote a
register to storing either the butterfly or null, because the butterfly register is anyway
going to be free inside the first allocation. The only overhead here is zeroing the
butterfly register. With that in place, we can just pass the butterfly-or-null to the slow
path, which can then either allocate a butterfly or not. So now we never waste a successful
allocation. This patch implements such a solution both in DFG (where it's easy to do this
since we control registers already) and in FTL (where it's annoying, because mutable
"butterfly-or-null" variables are hard to say in SSA; also I realized that we had code
duplicated the JSArray allocation utility, so I deduplicated it). This came up because in
one version of this patch, this wastage would resonate with some Kraken benchmark: the
benchmark would always allocate N small things followed by one bigger thing. The problem
was I accidentally adjusted the various fixed overheads in MarkedBlock in such a way that
the JSObject size class, which both the small and big thing shared for their cell, could
hold exactly N cells per MarkedBlock. Then the benchmark would always call slow path when
it allocated the big thing. So, it would end up having to allocate the big thing's large
butterfly twice, every single time! Ouch!
- It used to be that we zeroed CopiedBlocks using memset, and so array allocations enjoyed
amortization of the cost of zeroing. This doesn't work anymore - it's now up to the client
of the allocator to initialize the object to whatever state they need. It used to be that
we would just use a dumb loop. I initially changed this so that we would end up in memset
for large allocations, but this didn't actually help performance that much. I got a much
better result by playing with different memsets written in assembly. First I wrote one
using non-temporal stores. That was a small speed-up over memset. Then I tried the classic
"rep stos" approach, and holy cow that version was fast. It's a ~20% speed-up on array
allocation microbenchmarks. So, this patch adds code paths to do "rep stos" on x86_64, or
memset, or use a loop, as appropriate, for both "contiguous" arrays (holes are zero) and
double arrays (holes are PNaN). Note that the JIT always emits either a loop or a flat slab
of stores (if the size is known), but those paths in the JIT won't trigger for
NewArrayWithSize() if the size is large, since that takes us to the
operationNewArrayWithSize() slow path, which calls into JSArray::create(). That's why the
optimizations here are all in JSArray::create() - that's the hot place for large arrays
that need to be filled with holes.
All of this put together gives us neutral perf on JetStream, membuster, and PLT3, a ~1%
regression on Speedometer, and up to a 4% regression Kraken. The Kraken regression is
because Kraken was allocating exactly 1024 element arrays at a rate of 400MB/sec. This is a
best-case scenario for bump allocation. I think that we should fix bmalloc to make up the
difference, but take the hit for now because it's a crazy corner case. By comparison, the
alternative approach of using a copy barrier would have cost us 1-2%. That's the real
apples-to-apples comparison if your premise is that we should have a concurrent GC. After we
finish removing copied space, we will be barrier-ready for concurrent GC: we already have a
marking barrier and we simply won't need a copying barrier. This change gets us there for
the purposes of our benchmarks, since the remaining clients of copied space are not very
important. On the other hand, if we keep copying, then getting barrier-ready would mean
adding back the copy barrier, which costs more perf.
We might get bigger speed-ups once we remove CopiedSpace altogether. That requires moving
typed arrays and a few other weird things over to Aux MarkedSpace.
This also includes some header sanitization. The introduction of AuxiliaryBarrier, HeapCell,
and CellContainer meant that I had to include those files from everywhere. Fortunately,
just including JSCInlines.h (instead of manually including the files that includes) is
usually enough. So, I made most of JSC's cpp files include JSCInlines.h, which is something
that we were already basically doing. In places where JSCInlines.h would be too much, I just
included HeapInlines.h. This got weird, because we previously included HeapInlines.h from
JSObject.h. That's bad because it led to some circular dependencies, so I fixed it - but that
meant having to manually include HeapInlines.h from the places that previously got it
implicitly via JSObject.h. But that led to more problems for some reason: I started getting
build errors because non-JSC files were having trouble including Opcode.h. That's just silly,
since Opcode.h is meant to be an internal JSC header. So, I made it an internal header and
made it impossible to include it from outside JSC. This was a lot of work, but it was
necessary to get the patch to build on all ports. It's also a net win. There were many places
in WebCore that were transitively including a *ton* of JSC headers just because of the
JSObject.h->HeapInlines.h edge and a bunch of dependency edges that arose from some public
(for WebCore) JSC headers needing Interpreter.h or Opcode.h for bad reasons.
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* API/JSTypedArray.cpp:
* API/ObjCCallbackFunction.mm:
* API/tests/testapi.mm:
(testObjectiveCAPI):
(testWeakValue): Deleted.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/builtins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
* Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
* Scripts/builtins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::JumpList::link):
(JSC::AbstractMacroAssembler::JumpList::linkTo):
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
* assembler/MacroAssemblerCodeRef.cpp: Added.
(JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
(JSC::MacroAssemblerCodePtr::dumpWithName):
(JSC::MacroAssemblerCodePtr::dump):
(JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
(JSC::MacroAssemblerCodeRef::dump):
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::createLLIntCodePtr): Deleted.
(JSC::MacroAssemblerCodePtr::dumpWithName): Deleted.
(JSC::MacroAssemblerCodePtr::dump): Deleted.
(JSC::MacroAssemblerCodeRef::createLLIntCodeRef): Deleted.
(JSC::MacroAssemblerCodeRef::dump): Deleted.
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::appendBoolConstant):
* b3/B3BasicBlock.h:
* b3/B3DuplicateTails.cpp:
* b3/B3StackmapGenerationParams.h:
* b3/testb3.cpp:
(JSC::B3::testPatchpointTerminalReturnValue):
(JSC::B3::run):
* bindings/ScriptValue.cpp:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
* bytecode/BytecodeBasicBlock.cpp:
* bytecode/BytecodeLivenessAnalysis.cpp:
* bytecode/BytecodeUseDef.h:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::callTypeFor):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor): Deleted.
* bytecode/CallLinkStatus.cpp:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::clearLLIntGetByIdCache):
(JSC::CodeBlock::predictedMachineCodeSize):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::clearLLIntGetByIdCache): Deleted.
* bytecode/ExecutionCounter.h:
* bytecode/Instruction.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::isNull):
(JSC::ObjectAllocationProfile::initialize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/PreciseJumpTargets.cpp:
* bytecode/StructureStubInfo.cpp:
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::vm): Deleted.
* bytecode/UnlinkedCodeBlock.h:
* bytecode/UnlinkedInstructionStream.cpp:
* bytecode/UnlinkedInstructionStream.h:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCompile.cpp:
* ftl/FTLJITFinalizer.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::allocateArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize): Deleted.
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::add):
(JSC::FTL::Output::shl):
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::aboveOrEqual):
(JSC::FTL::Output::below):
(JSC::FTL::Output::belowOrEqual):
(JSC::FTL::Output::greaterThan):
(JSC::FTL::Output::greaterThanOrEqual):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::select):
(JSC::FTL::Output::appendSuccessor):
(JSC::FTL::Output::addIncomingToPhi):
* ftl/FTLOutput.h:
* ftl/FTLValueFromBlock.h:
(JSC::FTL::ValueFromBlock::operator bool):
(JSC::FTL::ValueFromBlock::ValueFromBlock): Deleted.
* ftl/FTLWeightedTarget.h:
(JSC::FTL::WeightedTarget::frequentedBlock):
* heap/CellContainer.h: Added.
(JSC::CellContainer::CellContainer):
(JSC::CellContainer::operator bool):
(JSC::CellContainer::isMarkedBlock):
(JSC::CellContainer::isLargeAllocation):
(JSC::CellContainer::markedBlock):
(JSC::CellContainer::largeAllocation):
* heap/CellContainerInlines.h: Added.
(JSC::CellContainer::isMarked):
(JSC::CellContainer::isMarkedOrNewlyAllocated):
(JSC::CellContainer::noteMarked):
(JSC::CellContainer::cellSize):
(JSC::CellContainer::weakSet):
(JSC::CellContainer::flipIfNecessary):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::~ConservativeRoots):
(JSC::ConservativeRoots::grow):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::genericAddSpan):
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots):
* heap/CopyToken.h:
* heap/FreeList.cpp: Added.
(JSC::FreeList::dump):
* heap/FreeList.h: Added.
(JSC::FreeList::FreeList):
(JSC::FreeList::list):
(JSC::FreeList::bump):
(JSC::FreeList::operator==):
(JSC::FreeList::operator!=):
(JSC::FreeList::operator bool):
(JSC::FreeList::allocationWillFail):
(JSC::FreeList::allocationWillSucceed):
* heap/GCTypeMap.h: Added.
(JSC::GCTypeMap::operator[]):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::finalizeUnconditionalFinalizers):
(JSC::Heap::markRoots):
(JSC::Heap::copyBackingStores):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::gatherJSStackRoots):
(JSC::Heap::gatherScratchBufferRoots):
(JSC::Heap::clearLivenessData):
(JSC::Heap::visitSmallStrings):
(JSC::Heap::visitConservativeRoots):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::gatherExtraHeapSnapshotData):
(JSC::Heap::removeDeadHeapSnapshotNodes):
(JSC::Heap::visitProtectedObjects):
(JSC::Heap::visitArgumentBuffers):
(JSC::Heap::visitException):
(JSC::Heap::visitStrongHandles):
(JSC::Heap::visitHandleStack):
(JSC::Heap::visitSamplingProfiler):
(JSC::Heap::traceCodeBlocksAndJITStubRoutines):
(JSC::Heap::converge):
(JSC::Heap::visitWeakHandles):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::clearUnmarkedExecutables):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collect):
(JSC::Heap::collectWithoutAnySweep):
(JSC::Heap::collectImpl):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::willStartCollection):
(JSC::Heap::flushOldStructureIDTables):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::stopAllocation):
(JSC::Heap::prepareForMarking):
(JSC::Heap::reapWeakHandles):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::sweepArrayBuffers):
(JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
(JSC::MarkedBlockSnapshotFunctor::operator()):
(JSC::Heap::snapshotMarkedSpace):
(JSC::Heap::deleteSourceProviderCaches):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::Heap::resetAllocators):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::resumeCompilerThreads):
(JSC::Zombify::visit):
(JSC::Heap::forEachCodeBlockImpl):
* heap/Heap.h:
(JSC::Heap::allocatorForObjectWithoutDestructor):
(JSC::Heap::allocatorForObjectWithDestructor):
(JSC::Heap::allocatorForAuxiliaryData):
(JSC::Heap::jitStubRoutines):
(JSC::Heap::codeBlockSet):
(JSC::Heap::storageAllocator): Deleted.
* heap/HeapCell.h:
(JSC::HeapCell::isZapped): Deleted.
* heap/HeapCellInlines.h: Added.
(JSC::HeapCell::isLargeAllocation):
(JSC::HeapCell::cellContainer):
(JSC::HeapCell::markedBlock):
(JSC::HeapCell::largeAllocation):
(JSC::HeapCell::heap):
(JSC::HeapCell::vm):
(JSC::HeapCell::cellSize):
(JSC::HeapCell::allocatorAttributes):
(JSC::HeapCell::destructionMode):
(JSC::HeapCell::cellKind):
* heap/HeapInlines.h:
(JSC::Heap::heap):
(JSC::Heap::isLive):
(JSC::Heap::isMarked):
(JSC::Heap::testAndSetMarked):
(JSC::Heap::setMarked):
(JSC::Heap::cellSize):
(JSC::Heap::forEachCodeBlock):
(JSC::Heap::allocateObjectOfType):
(JSC::Heap::subspaceForObjectOfType):
(JSC::Heap::allocatorForObjectOfType):
(JSC::Heap::allocateAuxiliary):
(JSC::Heap::tryAllocateAuxiliary):
(JSC::Heap::tryReallocateAuxiliary):
(JSC::Heap::isPointerGCObject): Deleted.
(JSC::Heap::isValueGCObject): Deleted.
* heap/HeapOperation.cpp: Added.
(WTF::printInternal):
* heap/HeapOperation.h:
* heap/HeapUtil.h: Added.
(JSC::HeapUtil::findGCObjectPointersForMarking):
(JSC::HeapUtil::isPointerGCObjectJSCell):
(JSC::HeapUtil::isValueGCObject):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::sweepNextBlock):
* heap/IncrementalSweeper.h:
* heap/LargeAllocation.cpp: Added.
(JSC::LargeAllocation::tryCreate):
(JSC::LargeAllocation::LargeAllocation):
(JSC::LargeAllocation::lastChanceToFinalize):
(JSC::LargeAllocation::shrink):
(JSC::LargeAllocation::visitWeakSet):
(JSC::LargeAllocation::reapWeakSet):
(JSC::LargeAllocation::flip):
(JSC::LargeAllocation::isEmpty):
(JSC::LargeAllocation::sweep):
(JSC::LargeAllocation::destroy):
(JSC::LargeAllocation::dump):
* heap/LargeAllocation.h: Added.
(JSC::LargeAllocation::fromCell):
(JSC::LargeAllocation::cell):
(JSC::LargeAllocation::isLargeAllocation):
(JSC::LargeAllocation::heap):
(JSC::LargeAllocation::vm):
(JSC::LargeAllocation::weakSet):
(JSC::LargeAllocation::clearNewlyAllocated):
(JSC::LargeAllocation::isNewlyAllocated):
(JSC::LargeAllocation::isMarked):
(JSC::LargeAllocation::isMarkedOrNewlyAllocated):
(JSC::LargeAllocation::isLive):
(JSC::LargeAllocation::hasValidCell):
(JSC::LargeAllocation::cellSize):
(JSC::LargeAllocation::aboveLowerBound):
(JSC::LargeAllocation::belowUpperBound):
(JSC::LargeAllocation::contains):
(JSC::LargeAllocation::attributes):
(JSC::LargeAllocation::flipIfNecessary):
(JSC::LargeAllocation::flipIfNecessaryConcurrently):
(JSC::LargeAllocation::testAndSetMarked):
(JSC::LargeAllocation::setMarked):
(JSC::LargeAllocation::clearMarked):
(JSC::LargeAllocation::noteMarked):
(JSC::LargeAllocation::headerSize):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::MarkedAllocator):
(JSC::MarkedAllocator::isPagedOut):
(JSC::MarkedAllocator::retire):
(JSC::MarkedAllocator::filterNextBlock):
(JSC::MarkedAllocator::setNextBlockToSweep):
(JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
(JSC::MarkedAllocator::tryAllocateWithoutCollecting):
(JSC::MarkedAllocator::allocateSlowCase):
(JSC::MarkedAllocator::tryAllocateSlowCase):
(JSC::MarkedAllocator::allocateSlowCaseImpl):
(JSC::blockHeaderSize):
(JSC::MarkedAllocator::blockSizeForBytes):
(JSC::MarkedAllocator::tryAllocateBlock):
(JSC::MarkedAllocator::addBlock):
(JSC::MarkedAllocator::removeBlock):
(JSC::MarkedAllocator::stopAllocating):
(JSC::MarkedAllocator::reset):
(JSC::MarkedAllocator::lastChanceToFinalize):
(JSC::MarkedAllocator::setFreeList):
(JSC::isListPagedOut): Deleted.
(JSC::MarkedAllocator::tryAllocateHelper): Deleted.
(JSC::MarkedAllocator::tryPopFreeList): Deleted.
(JSC::MarkedAllocator::tryAllocate): Deleted.
(JSC::MarkedAllocator::allocateBlock): Deleted.
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::takeLastActiveBlock):
(JSC::MarkedAllocator::offsetOfFreeList):
(JSC::MarkedAllocator::offsetOfCellSize):
(JSC::MarkedAllocator::tryAllocate):
(JSC::MarkedAllocator::allocate):
(JSC::MarkedAllocator::forEachBlock):
(JSC::MarkedAllocator::offsetOfFreeListHead): Deleted.
(JSC::MarkedAllocator::MarkedAllocator): Deleted.
(JSC::MarkedAllocator::init): Deleted.
(JSC::MarkedAllocator::stopAllocating): Deleted.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::tryCreate):
(JSC::MarkedBlock::Handle::Handle):
(JSC::MarkedBlock::Handle::~Handle):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
(JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode):
(JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
(JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
(JSC::SetNewlyAllocatedFunctor::operator()):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::lastChanceToFinalize):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::Handle::zap):
(JSC::MarkedBlock::Handle::forEachFreeCell):
(JSC::MarkedBlock::flipIfNecessary):
(JSC::MarkedBlock::Handle::flipIfNecessary):
(JSC::MarkedBlock::flipIfNecessarySlow):
(JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
(JSC::MarkedBlock::clearMarks):
(JSC::MarkedBlock::assertFlipped):
(JSC::MarkedBlock::needsFlip):
(JSC::MarkedBlock::Handle::needsFlip):
(JSC::MarkedBlock::Handle::willRemoveBlock):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::markCount):
(JSC::MarkedBlock::Handle::isEmpty):
(JSC::MarkedBlock::clearHasAnyMarked):
(JSC::MarkedBlock::noteMarkedSlow):
(WTF::printInternal):
(JSC::MarkedBlock::create): Deleted.
(JSC::MarkedBlock::destroy): Deleted.
(JSC::MarkedBlock::callDestructor): Deleted.
(JSC::MarkedBlock::specializedSweep): Deleted.
(JSC::MarkedBlock::sweep): Deleted.
(JSC::MarkedBlock::sweepHelper): Deleted.
(JSC::MarkedBlock::stopAllocating): Deleted.
(JSC::MarkedBlock::clearMarksWithCollectionType): Deleted.
(JSC::MarkedBlock::lastChanceToFinalize): Deleted.
(JSC::MarkedBlock::resumeAllocating): Deleted.
(JSC::MarkedBlock::didRetireBlock): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::VoidFunctor::returnValue):
(JSC::MarkedBlock::CountFunctor::CountFunctor):
(JSC::MarkedBlock::CountFunctor::count):
(JSC::MarkedBlock::CountFunctor::returnValue):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
(JSC::MarkedBlock::Handle::isOnBlocksToSweep):
(JSC::MarkedBlock::Handle::setIsOnBlocksToSweep):
(JSC::MarkedBlock::Handle::state):
(JSC::MarkedBlock::needsDestruction):
(JSC::MarkedBlock::handle):
(JSC::MarkedBlock::Handle::block):
(JSC::MarkedBlock::firstAtom):
(JSC::MarkedBlock::atoms):
(JSC::MarkedBlock::isAtomAligned):
(JSC::MarkedBlock::Handle::cellAlign):
(JSC::MarkedBlock::blockFor):
(JSC::MarkedBlock::Handle::allocator):
(JSC::MarkedBlock::Handle::heap):
(JSC::MarkedBlock::Handle::vm):
(JSC::MarkedBlock::vm):
(JSC::MarkedBlock::Handle::weakSet):
(JSC::MarkedBlock::weakSet):
(JSC::MarkedBlock::Handle::shrink):
(JSC::MarkedBlock::Handle::visitWeakSet):
(JSC::MarkedBlock::Handle::reapWeakSet):
(JSC::MarkedBlock::Handle::cellSize):
(JSC::MarkedBlock::cellSize):
(JSC::MarkedBlock::Handle::attributes):
(JSC::MarkedBlock::attributes):
(JSC::MarkedBlock::Handle::needsDestruction):
(JSC::MarkedBlock::Handle::destruction):
(JSC::MarkedBlock::Handle::cellKind):
(JSC::MarkedBlock::Handle::markCount):
(JSC::MarkedBlock::Handle::size):
(JSC::MarkedBlock::atomNumber):
(JSC::MarkedBlock::flipIfNecessary):
(JSC::MarkedBlock::flipIfNecessaryConcurrently):
(JSC::MarkedBlock::Handle::flipIfNecessary):
(JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
(JSC::MarkedBlock::Handle::flipForEdenCollection):
(JSC::MarkedBlock::assertFlipped):
(JSC::MarkedBlock::Handle::assertFlipped):
(JSC::MarkedBlock::isMarked):
(JSC::MarkedBlock::testAndSetMarked):
(JSC::MarkedBlock::Handle::isNewlyAllocated):
(JSC::MarkedBlock::Handle::setNewlyAllocated):
(JSC::MarkedBlock::Handle::clearNewlyAllocated):
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
(JSC::MarkedBlock::isMarkedOrNewlyAllocated):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::isAtom):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::Handle::forEachCell):
(JSC::MarkedBlock::Handle::forEachLiveCell):
(JSC::MarkedBlock::Handle::forEachDeadCell):
(JSC::MarkedBlock::Handle::needsSweeping):
(JSC::MarkedBlock::Handle::isAllocated):
(JSC::MarkedBlock::Handle::isMarked):
(JSC::MarkedBlock::Handle::isFreeListed):
(JSC::MarkedBlock::hasAnyMarked):
(JSC::MarkedBlock::noteMarked):
(WTF::MarkedBlockHash::hash):
(JSC::MarkedBlock::FreeList::FreeList): Deleted.
(JSC::MarkedBlock::allocator): Deleted.
(JSC::MarkedBlock::heap): Deleted.
(JSC::MarkedBlock::shrink): Deleted.
(JSC::MarkedBlock::visitWeakSet): Deleted.
(JSC::MarkedBlock::reapWeakSet): Deleted.
(JSC::MarkedBlock::willRemoveBlock): Deleted.
(JSC::MarkedBlock::didConsumeFreeList): Deleted.
(JSC::MarkedBlock::markCount): Deleted.
(JSC::MarkedBlock::isEmpty): Deleted.
(JSC::MarkedBlock::destruction): Deleted.
(JSC::MarkedBlock::cellKind): Deleted.
(JSC::MarkedBlock::size): Deleted.
(JSC::MarkedBlock::capacity): Deleted.
(JSC::MarkedBlock::setMarked): Deleted.
(JSC::MarkedBlock::clearMarked): Deleted.
(JSC::MarkedBlock::isNewlyAllocated): Deleted.
(JSC::MarkedBlock::setNewlyAllocated): Deleted.
(JSC::MarkedBlock::clearNewlyAllocated): Deleted.
(JSC::MarkedBlock::isLive): Deleted.
(JSC::MarkedBlock::isLiveCell): Deleted.
(JSC::MarkedBlock::forEachCell): Deleted.
(JSC::MarkedBlock::forEachLiveCell): Deleted.
(JSC::MarkedBlock::forEachDeadCell): Deleted.
(JSC::MarkedBlock::needsSweeping): Deleted.
(JSC::MarkedBlock::isAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrRetired): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::initializeSizeClassForStepSize):
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::~MarkedSpace):
(JSC::MarkedSpace::lastChanceToFinalize):
(JSC::MarkedSpace::allocate):
(JSC::MarkedSpace::tryAllocate):
(JSC::MarkedSpace::allocateLarge):
(JSC::MarkedSpace::tryAllocateLarge):
(JSC::MarkedSpace::sweep):
(JSC::MarkedSpace::sweepLargeAllocations):
(JSC::MarkedSpace::zombifySweep):
(JSC::MarkedSpace::resetAllocators):
(JSC::MarkedSpace::visitWeakSets):
(JSC::MarkedSpace::reapWeakSets):
(JSC::MarkedSpace::stopAllocating):
(JSC::MarkedSpace::prepareForMarking):
(JSC::MarkedSpace::resumeAllocating):
(JSC::MarkedSpace::isPagedOut):
(JSC::MarkedSpace::freeBlock):
(JSC::MarkedSpace::freeOrShrinkBlock):
(JSC::MarkedSpace::shrink):
(JSC::MarkedSpace::clearNewlyAllocated):
(JSC::VerifyMarked::operator()):
(JSC::MarkedSpace::flip):
(JSC::MarkedSpace::objectCount):
(JSC::MarkedSpace::size):
(JSC::MarkedSpace::capacity):
(JSC::MarkedSpace::addActiveWeakSet):
(JSC::MarkedSpace::didAddBlock):
(JSC::MarkedSpace::didAllocateInBlock):
(JSC::MarkedSpace::forEachAllocator): Deleted.
(JSC::VerifyMarkedOrRetired::operator()): Deleted.
(JSC::MarkedSpace::clearMarks): Deleted.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::sizeClassToIndex):
(JSC::MarkedSpace::indexToSizeClass):
(JSC::MarkedSpace::version):
(JSC::MarkedSpace::blocksWithNewObjects):
(JSC::MarkedSpace::largeAllocations):
(JSC::MarkedSpace::largeAllocationsNurseryOffset):
(JSC::MarkedSpace::largeAllocationsOffsetForThisCollection):
(JSC::MarkedSpace::largeAllocationsForThisCollectionBegin):
(JSC::MarkedSpace::largeAllocationsForThisCollectionEnd):
(JSC::MarkedSpace::largeAllocationsForThisCollectionSize):
(JSC::MarkedSpace::forEachLiveCell):
(JSC::MarkedSpace::forEachDeadCell):
(JSC::MarkedSpace::allocatorFor):
(JSC::MarkedSpace::destructorAllocatorFor):
(JSC::MarkedSpace::auxiliaryAllocatorFor):
(JSC::MarkedSpace::allocateWithoutDestructor):
(JSC::MarkedSpace::allocateWithDestructor):
(JSC::MarkedSpace::allocateAuxiliary):
(JSC::MarkedSpace::tryAllocateAuxiliary):
(JSC::MarkedSpace::forEachBlock):
(JSC::MarkedSpace::forEachAllocator):
(JSC::MarkedSpace::optimalSizeFor):
(JSC::MarkedSpace::didAddBlock): Deleted.
(JSC::MarkedSpace::didAllocateInBlock): Deleted.
(JSC::MarkedSpace::objectCount): Deleted.
(JSC::MarkedSpace::size): Deleted.
(JSC::MarkedSpace::capacity): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::markAuxiliary):
(JSC::SlotVisitor::noteLiveAuxiliaryCell):
(JSC::SlotVisitor::visitChildren):
* heap/SlotVisitor.h:
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::WeakBlock):
(JSC::WeakBlock::visit):
(JSC::WeakBlock::reap):
* heap/WeakBlock.h:
(JSC::WeakBlock::disconnectContainer):
(JSC::WeakBlock::disconnectMarkedBlock): Deleted.
* heap/WeakSet.cpp:
(JSC::WeakSet::~WeakSet):
(JSC::WeakSet::sweep):
(JSC::WeakSet::shrink):
(JSC::WeakSet::addAllocator):
* heap/WeakSet.h:
(JSC::WeakSet::container):
(JSC::WeakSet::setContainer):
(JSC::WeakSet::WeakSet):
(JSC::WeakSet::visit):
(JSC::WeakSet::shrink): Deleted.
* heap/WeakSetInlines.h:
(JSC::WeakSet::allocate):
* inspector/InjectedScriptManager.cpp:
* inspector/JSGlobalObjectInspectorController.cpp:
* inspector/JSJavaScriptCallFrame.cpp:
* inspector/ScriptDebugServer.cpp:
* inspector/agents/InspectorDebuggerAgent.cpp:
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
(JSC::StackFrame::sourceID): Deleted.
(JSC::StackFrame::sourceURL): Deleted.
(JSC::StackFrame::functionName): Deleted.
(JSC::StackFrame::computeLineAndColumn): Deleted.
(JSC::StackFrame::toString): Deleted.
* interpreter/Interpreter.h:
(JSC::StackFrame::isNative): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
(JSC::AssemblyHelpers::emitAllocate):
(JSC::AssemblyHelpers::emitAllocateJSCell):
(JSC::AssemblyHelpers::emitAllocateJSObject):
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
* jit/JIT.cpp:
(JSC::JIT::compileCTINativeCall):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::JIT::compileCTINativeCall): Deleted.
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
* jit/JITThunks.cpp:
* jit/JITThunks.h:
* jsc.cpp:
(functionDescribeArray):
(main):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntExceptions.cpp:
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ModuleAnalyzer.cpp:
* parser/NodeConstructors.h:
* parser/Nodes.h:
* profiler/ProfilerBytecode.cpp:
* profiler/ProfilerBytecode.h:
* profiler/ProfilerBytecodeSequence.cpp:
* runtime/ArrayConventions.h:
(JSC::indexingHeaderForArrayStorage):
(JSC::baseIndexingHeaderForArrayStorage):
(JSC::indexingHeaderForArray): Deleted.
(JSC::baseIndexingHeaderForArray): Deleted.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
(JSC::concatAppendOne):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/ArrayStorage.h:
(JSC::ArrayStorage::vectorLength):
(JSC::ArrayStorage::totalSizeFor):
(JSC::ArrayStorage::totalSize):
(JSC::ArrayStorage::availableVectorLength):
(JSC::ArrayStorage::optimalVectorLength):
(JSC::ArrayStorage::sizeFor): Deleted.
* runtime/AuxiliaryBarrier.h: Added.
(JSC::AuxiliaryBarrier::AuxiliaryBarrier):
(JSC::AuxiliaryBarrier::clear):
(JSC::AuxiliaryBarrier::get):
(JSC::AuxiliaryBarrier::slot):
(JSC::AuxiliaryBarrier::operator bool):
(JSC::AuxiliaryBarrier::setWithoutBarrier):
* runtime/AuxiliaryBarrierInlines.h: Added.
(JSC::AuxiliaryBarrier<T>::AuxiliaryBarrier):
(JSC::AuxiliaryBarrier<T>::set):
* runtime/Butterfly.h:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::availableContiguousVectorLength):
(JSC::Butterfly::optimalContiguousVectorLength):
(JSC::Butterfly::createUninitialized):
(JSC::Butterfly::growArrayRight):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createEmpty):
* runtime/CommonSlowPathsExceptions.cpp:
* runtime/CommonSlowPathsExceptions.h:
* runtime/DataView.cpp:
* runtime/DirectArguments.h:
* runtime/ECMAScriptSpecInternalFunctions.cpp:
* runtime/Error.cpp:
* runtime/Error.h:
* runtime/ErrorInstance.cpp:
* runtime/ErrorInstance.h:
* runtime/Exception.cpp:
* runtime/Exception.h:
* runtime/GeneratorFrame.cpp:
* runtime/GeneratorPrototype.cpp:
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::InternalFunction):
* runtime/IntlCollator.cpp:
* runtime/IntlCollatorConstructor.cpp:
* runtime/IntlCollatorPrototype.cpp:
* runtime/IntlDateTimeFormat.cpp:
* runtime/IntlDateTimeFormatConstructor.cpp:
* runtime/IntlDateTimeFormatPrototype.cpp:
* runtime/IntlNumberFormat.cpp:
* runtime/IntlNumberFormatConstructor.cpp:
* runtime/IntlNumberFormatPrototype.cpp:
* runtime/IntlObject.cpp:
* runtime/IteratorPrototype.cpp:
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateUninitialized):
(JSC::JSArray::setLengthWritable):
(JSC::JSArray::unshiftCountSlowCase):
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::appendMemcpy):
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::push):
(JSC::JSArray::fastSlice):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithArrayStorage):
(JSC::JSArray::fillArgList):
(JSC::JSArray::copyToArguments):
* runtime/JSArray.h:
(JSC::createContiguousArrayButterfly):
(JSC::createArrayButterfly):
(JSC::JSArray::create):
(JSC::JSArray::tryCreateUninitialized): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSCInlines.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContextAssumingStructure):
* runtime/JSCallee.cpp:
(JSC::JSCallee::JSCallee):
* runtime/JSCell.cpp:
(JSC::JSCell::estimatedSize):
* runtime/JSCell.h:
(JSC::JSCell::cellStateOffset): Deleted.
* runtime/JSCellInlines.h:
(JSC::ExecState::vm):
(JSC::JSCell::classInfo):
(JSC::JSCell::callDestructor):
(JSC::JSCell::vm): Deleted.
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
(JSC::JSFunction::setFunctionName):
(JSC::JSFunction::reifyLength):
(JSC::JSFunction::reifyName):
(JSC::JSFunction::reifyLazyPropertyIfNeeded):
(JSC::JSFunction::reifyBoundNameIfNeeded):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
(JSC::JSFunction::JSFunction):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
* runtime/JSInternalPromise.cpp:
* runtime/JSInternalPromiseConstructor.cpp:
* runtime/JSInternalPromiseDeferred.cpp:
* runtime/JSInternalPromisePrototype.cpp:
* runtime/JSJob.cpp:
* runtime/JSMapIterator.cpp:
* runtime/JSModuleNamespaceObject.cpp:
* runtime/JSModuleRecord.cpp:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::createInitialArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::putByIndexBeyondVectorLength):
(JSC::JSObject::putDirectIndexBeyondVectorLength):
(JSC::JSObject::getNewVectorLength):
(JSC::JSObject::increaseVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::growOutOfLineStorage):
(JSC::JSObject::copyButterfly): Deleted.
(JSC::JSObject::copyBackingStore): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::globalObject):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary): Deleted.
* runtime/JSObjectInlines.h:
* runtime/JSPromise.cpp:
* runtime/JSPromiseConstructor.cpp:
* runtime/JSPromiseDeferred.cpp:
* runtime/JSPromisePrototype.cpp:
* runtime/JSPropertyNameIterator.cpp:
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
* runtime/JSScope.h:
(JSC::JSScope::globalObject):
(JSC::JSScope::vm): Deleted.
* runtime/JSSetIterator.cpp:
* runtime/JSStringIterator.cpp:
* runtime/JSTemplateRegistryKey.cpp:
* runtime/JSTypedArrayViewConstructor.cpp:
* runtime/JSTypedArrayViewPrototype.cpp:
* runtime/JSWeakMap.cpp:
* runtime/JSWeakSet.cpp:
* runtime/MapConstructor.cpp:
* runtime/MapIteratorPrototype.cpp:
* runtime/MapPrototype.cpp:
* runtime/NativeErrorConstructor.cpp:
* runtime/NativeStdFunctionCell.cpp:
* runtime/Operations.h:
(JSC::scribbleFreeCells):
(JSC::scribble):
* runtime/Options.h:
* runtime/PropertyTable.cpp:
* runtime/ProxyConstructor.cpp:
* runtime/ProxyObject.cpp:
* runtime/ProxyRevoke.cpp:
* runtime/RegExp.cpp:
(JSC::RegExp::match):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::matchCompareWithInterpreter):
* runtime/RegExp.h:
* runtime/RegExpConstructor.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
(JSC::createRegExpMatchesArray):
* runtime/RegExpPrototype.cpp:
(JSC::genericSplit):
* runtime/RuntimeType.cpp:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SetConstructor.cpp:
* runtime/SetIteratorPrototype.cpp:
* runtime/SetPrototype.cpp:
* runtime/StackFrame.cpp: Added.
(JSC::StackFrame::sourceID):
(JSC::StackFrame::sourceURL):
(JSC::StackFrame::functionName):
(JSC::StackFrame::computeLineAndColumn):
(JSC::StackFrame::toString):
* runtime/StackFrame.h: Added.
(JSC::StackFrame::isNative):
* runtime/StringConstructor.cpp:
* runtime/StringIteratorPrototype.cpp:
* runtime/StructureInlines.h:
(JSC::Structure::propertyTable):
* runtime/TemplateRegistry.cpp:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
* runtime/TestRunnerUtils.h:
* runtime/TypeProfilerLog.cpp:
* runtime/TypeSet.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureStackCapacityForCLoop):
(JSC::VM::isSafeToRecurseSoftCLoop):
* runtime/VM.h:
* runtime/VMEntryScope.h:
* runtime/VMInlines.h:
(JSC::VM::ensureStackCapacityFor):
(JSC::VM::isSafeToRecurseSoft):
* runtime/WeakMapConstructor.cpp:
* runtime/WeakMapData.cpp:
* runtime/WeakMapPrototype.cpp:
* runtime/WeakSetConstructor.cpp:
* runtime/WeakSetPrototype.cpp:
* testRegExp.cpp:
(testOneRegExp):
* tools/JSDollarVM.cpp:
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::isInObjectSpace):
Source/WebCore:
No new tests because no new WebCore behavior.
Just rewiring #includes.
* ForwardingHeaders/heap/HeapInlines.h: Added.
* ForwardingHeaders/interpreter/Interpreter.h: Removed.
* ForwardingHeaders/runtime/AuxiliaryBarrierInlines.h: Added.
* Modules/indexeddb/IDBCursorWithValue.cpp:
* Modules/indexeddb/client/TransactionOperation.cpp:
* Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:
* Modules/indexeddb/server/UniqueIDBDatabase.cpp:
* bindings/js/JSApplePayPaymentAuthorizedEventCustom.cpp:
* bindings/js/JSApplePayPaymentMethodSelectedEventCustom.cpp:
* bindings/js/JSApplePayShippingContactSelectedEventCustom.cpp:
* bindings/js/JSApplePayShippingMethodSelectedEventCustom.cpp:
* bindings/js/JSClientRectCustom.cpp:
* bindings/js/JSDOMBinding.cpp:
* bindings/js/JSDOMBinding.h:
* bindings/js/JSDeviceMotionEventCustom.cpp:
* bindings/js/JSDeviceOrientationEventCustom.cpp:
* bindings/js/JSErrorEventCustom.cpp:
* bindings/js/JSIDBCursorWithValueCustom.cpp:
* bindings/js/JSIDBIndexCustom.cpp:
* bindings/js/JSPopStateEventCustom.cpp:
* bindings/js/JSWebGL2RenderingContextCustom.cpp:
* bindings/js/JSWorkerGlobalScopeCustom.cpp:
* bindings/js/WorkerScriptController.cpp:
* contentextensions/ContentExtensionParser.cpp:
* dom/ErrorEvent.cpp:
* html/HTMLCanvasElement.cpp:
* html/MediaDocument.cpp:
* inspector/CommandLineAPIModule.cpp:
* loader/EmptyClients.cpp:
* page/CaptionUserPreferences.cpp:
* page/Frame.cpp:
* page/PageGroup.cpp:
* page/UserContentController.cpp:
* platform/mock/mediasource/MockBox.cpp:
* testing/GCObservation.cpp:
Source/WebKit2:
Just rewiring some #includes.
* UIProcess/ViewGestureController.cpp:
* UIProcess/WebPageProxy.cpp:
* UIProcess/WebProcessPool.cpp:
* UIProcess/WebProcessProxy.cpp:
* WebProcess/InjectedBundle/DOM/InjectedBundleRangeHandle.cpp:
* WebProcess/Plugins/Netscape/JSNPObject.cpp:
Source/WTF:
I needed tryFastAlignedMalloc() so I added it.
* wtf/FastMalloc.cpp:
(WTF::tryFastAlignedMalloc):
* wtf/FastMalloc.h:
* wtf/ParkingLot.cpp:
(WTF::ParkingLot::forEachImpl):
(WTF::ParkingLot::forEach): Deleted.
* wtf/ParkingLot.h:
(WTF::ParkingLot::parkConditionally):
(WTF::ParkingLot::unparkOne):
(WTF::ParkingLot::forEach):
* wtf/ScopedLambda.h:
(WTF::scopedLambdaRef):
* wtf/SentinelLinkedList.h:
(WTF::SentinelLinkedList::forEach):
(WTF::RawNode>::takeFrom):
* wtf/SimpleStats.h:
(WTF::SimpleStats::operator bool):
(WTF::SimpleStats::operator!): Deleted.
Tools:
* DumpRenderTree/TestRunner.cpp:
* DumpRenderTree/mac/DumpRenderTree.mm:
(DumpRenderTreeMain):
* Scripts/run-jsc-stress-tests:
* TestWebKitAPI/Tests/WTF/Vector.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/179778@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@205462 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-09-06 01:02:22 +00:00
|
|
|
|
|
|
|
template<typename Func>
|
|
|
|
void forEach(const Func& func)
|
|
|
|
{
|
|
|
|
for (iterator iter = begin(); iter != end();) {
|
|
|
|
iterator next = iter->next();
|
|
|
|
func(iter);
|
|
|
|
iter = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void takeFrom(SentinelLinkedList<T, RawNode>&);
|
|
|
|
|
2011-02-15 23:54:06 +00:00
|
|
|
private:
|
2011-09-06 09:23:55 +00:00
|
|
|
RawNode m_headSentinel;
|
|
|
|
RawNode m_tailSentinel;
|
2011-02-15 23:54:06 +00:00
|
|
|
};
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
template <typename T, typename PtrTraits> void BasicRawSentinelNode<T, PtrTraits>::remove()
|
2011-09-06 09:23:55 +00:00
|
|
|
{
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
SentinelLinkedList<T, BasicRawSentinelNode>::remove(static_cast<T*>(this));
|
2011-09-06 09:23:55 +00:00
|
|
|
}
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
template <typename T, typename PtrTraits> void BasicRawSentinelNode<T, PtrTraits>::prepend(BasicRawSentinelNode* node)
|
2016-01-26 08:17:31 +00:00
|
|
|
{
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
SentinelLinkedList<T, BasicRawSentinelNode>::prepend(
|
2016-01-26 08:17:31 +00:00
|
|
|
static_cast<T*>(this), static_cast<T*>(node));
|
|
|
|
}
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
template <typename T, typename PtrTraits> void BasicRawSentinelNode<T, PtrTraits>::append(BasicRawSentinelNode* node)
|
2016-01-26 08:17:31 +00:00
|
|
|
{
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
SentinelLinkedList<T, BasicRawSentinelNode>::append(
|
2016-01-26 08:17:31 +00:00
|
|
|
static_cast<T*>(this), static_cast<T*>(node));
|
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
template <typename T, typename RawNode> inline SentinelLinkedList<T, RawNode>::SentinelLinkedList()
|
2011-02-15 23:54:06 +00:00
|
|
|
: m_headSentinel(Sentinel)
|
|
|
|
, m_tailSentinel(Sentinel)
|
|
|
|
{
|
|
|
|
m_headSentinel.setNext(&m_tailSentinel);
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
m_headSentinel.setPrev(nullptr);
|
2011-02-15 23:54:06 +00:00
|
|
|
|
|
|
|
m_tailSentinel.setPrev(&m_headSentinel);
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
m_tailSentinel.setNext(nullptr);
|
2011-02-15 23:54:06 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
template <typename T, typename RawNode> inline typename SentinelLinkedList<T, RawNode>::iterator SentinelLinkedList<T, RawNode>::begin()
|
2011-02-15 23:54:06 +00:00
|
|
|
{
|
2011-09-06 09:23:55 +00:00
|
|
|
return static_cast<T*>(m_headSentinel.next());
|
2011-02-15 23:54:06 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
template <typename T, typename RawNode> inline typename SentinelLinkedList<T, RawNode>::iterator SentinelLinkedList<T, RawNode>::end()
|
2011-02-15 23:54:06 +00:00
|
|
|
{
|
2011-09-06 09:23:55 +00:00
|
|
|
return static_cast<T*>(&m_tailSentinel);
|
2011-02-15 23:54:06 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
template <typename T, typename RawNode> inline void SentinelLinkedList<T, RawNode>::push(T* node)
|
2011-02-15 23:54:06 +00:00
|
|
|
{
|
|
|
|
ASSERT(node);
|
2011-09-06 09:23:55 +00:00
|
|
|
ASSERT(!node->prev());
|
|
|
|
ASSERT(!node->next());
|
|
|
|
|
|
|
|
RawNode* prev = &m_headSentinel;
|
|
|
|
RawNode* next = m_headSentinel.next();
|
2011-02-15 23:54:06 +00:00
|
|
|
|
|
|
|
node->setPrev(prev);
|
|
|
|
node->setNext(next);
|
|
|
|
|
|
|
|
prev->setNext(node);
|
|
|
|
next->setPrev(node);
|
|
|
|
}
|
|
|
|
|
2016-01-26 08:17:31 +00:00
|
|
|
template <typename T, typename RawNode> inline void SentinelLinkedList<T, RawNode>::append(T* node)
|
|
|
|
{
|
|
|
|
ASSERT(node);
|
|
|
|
ASSERT(!node->prev());
|
|
|
|
ASSERT(!node->next());
|
|
|
|
|
|
|
|
RawNode* prev = m_tailSentinel.prev();
|
|
|
|
RawNode* next = &m_tailSentinel;
|
|
|
|
|
|
|
|
node->setPrev(prev);
|
|
|
|
node->setNext(next);
|
|
|
|
|
|
|
|
prev->setNext(node);
|
|
|
|
next->setPrev(node);
|
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
template <typename T, typename RawNode> inline void SentinelLinkedList<T, RawNode>::remove(T* node)
|
2011-02-15 23:54:06 +00:00
|
|
|
{
|
2011-09-06 09:23:55 +00:00
|
|
|
ASSERT(node);
|
|
|
|
ASSERT(!!node->prev());
|
|
|
|
ASSERT(!!node->next());
|
|
|
|
|
|
|
|
RawNode* prev = node->prev();
|
|
|
|
RawNode* next = node->next();
|
2011-02-15 23:54:06 +00:00
|
|
|
|
|
|
|
prev->setNext(next);
|
|
|
|
next->setPrev(prev);
|
2011-09-06 09:23:55 +00:00
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
node->setPrev(nullptr);
|
|
|
|
node->setNext(nullptr);
|
2011-02-15 23:54:06 +00:00
|
|
|
}
|
|
|
|
|
2016-01-26 08:17:31 +00:00
|
|
|
template <typename T, typename RawNode>
|
|
|
|
inline void SentinelLinkedList<T, RawNode>::prepend(T* existingNode, T* newNode)
|
|
|
|
{
|
|
|
|
ASSERT(existingNode);
|
|
|
|
ASSERT(!!existingNode->prev());
|
|
|
|
ASSERT(!!existingNode->next());
|
|
|
|
ASSERT(newNode);
|
|
|
|
ASSERT(!newNode->prev());
|
|
|
|
ASSERT(!newNode->next());
|
|
|
|
|
|
|
|
RawNode* prev = existingNode->prev();
|
|
|
|
|
|
|
|
newNode->setNext(existingNode);
|
|
|
|
newNode->setPrev(prev);
|
|
|
|
|
|
|
|
prev->setNext(newNode);
|
|
|
|
existingNode->setPrev(newNode);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename T, typename RawNode>
|
|
|
|
inline void SentinelLinkedList<T, RawNode>::append(T* existingNode, T* newNode)
|
|
|
|
{
|
|
|
|
ASSERT(existingNode);
|
|
|
|
ASSERT(!!existingNode->prev());
|
|
|
|
ASSERT(!!existingNode->next());
|
|
|
|
ASSERT(newNode);
|
|
|
|
ASSERT(!newNode->prev());
|
|
|
|
ASSERT(!newNode->next());
|
|
|
|
|
|
|
|
RawNode* next = existingNode->next();
|
|
|
|
|
|
|
|
newNode->setNext(next);
|
|
|
|
newNode->setPrev(existingNode);
|
|
|
|
|
|
|
|
next->setPrev(newNode);
|
|
|
|
existingNode->setNext(newNode);
|
|
|
|
}
|
|
|
|
|
2012-11-21 02:34:46 +00:00
|
|
|
template <typename T, typename RawNode> inline bool SentinelLinkedList<T, RawNode>::isOnList(T* node)
|
|
|
|
{
|
|
|
|
if (!node->isOnList())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
for (T* iter = begin(); iter != end(); iter = iter->next()) {
|
|
|
|
if (iter == node)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
https://bugs.webkit.org/show_bug.cgi?id=160125
Reviewed by Geoffrey Garen and Keith Miller.
JSTests:
Most of the things I did properly covered by existing tests, but I found some simple cases of
unshifting that had sketchy coverage.
* stress/array-storage-array-unshift.js: Added.
* stress/contiguous-array-unshift.js: Added.
* stress/double-array-unshift.js: Added.
* stress/int32-array-unshift.js: Added.
Source/bmalloc:
I needed to tryMemalign, so I added such a thing.
* bmalloc/Allocator.cpp:
(bmalloc::Allocator::allocate):
(bmalloc::Allocator::tryAllocate):
(bmalloc::Allocator::allocateImpl):
* bmalloc/Allocator.h:
* bmalloc/Cache.h:
(bmalloc::Cache::tryAllocate):
* bmalloc/bmalloc.h:
(bmalloc::api::tryMemalign):
Source/JavaScriptCore:
In order to make the GC concurrent (bug 149432), we would either need to enable concurrent
copying or we would need to not copy. Concurrent copying carries a 1-2% throughput overhead
from the barriers alone. Considering that MarkedSpace does a decent job of avoiding
fragmentation, it's unlikely that it's worth paying 1-2% throughput for copying. So, we want
to get rid of copied space. This change moves copied space's biggest client over to marked
space.
Moving butterflies to marked space means having them use the new Auxiliary HeapCell
allocation path. This is a fairly mechanical change, but it caused performance regressions
everywhere, so this change also fixes MarkedSpace's performance issues.
At a high level the mechanical changes are:
- We use AuxiliaryBarrier instead of CopyBarrier.
- We use tryAllocateAuxiliary instead of tryAllocateStorage. I got rid of the silly
CheckedBoolean stuff, since it's so much more trouble than it's worth.
- The JITs have to emit inlined marked space allocations instead of inline copy space
allocations.
- Everyone has to get used to zeroing their butterflies after allocation instead of relying
on them being pre-zeroed by the GC. Copied space would zero things for you, while marked
space doesn't.
That's about 1/3 of this change. But this led to performance problems, which I fixed with
optimizations that amounted to a major MarkedSpace rewrite:
- MarkedSpace always causes internal fragmentation for array allocations because the vector
length we choose when we resize usually leads to a cell size that doesn't correspond to any
size class. I got around this by making array allocations usually round up vectorLength to
the maximum allowed by the size class that we would have allocated in. Also,
ensureLengthSlow() and friends first make sure that the requested length can't just be
fulfilled with the current allocation size. This safeguard means that not every array
allocation has to do size class queries. For example, the fast path of new Array(length)
never does any size class queries, under the assumption that (1) the speed gained from
avoiding an ensureLengthSlow() call, which then just changes the vectorLength by doing the
size class query, is too small to offset the speed lost by doing the query on every
allocation and (2) new Array(length) is a pretty good hint that resizing is not very
likely.
- Size classes in MarkedSpace were way too precise, which led to external fragmentation. This
changes MarkedSpace size classes to use a linear progression for very small sizes followed
by a geometric progression that naturally transitions to a hyperbolic progression. We want
hyperbolic sizes when we get close to blockSize: for example the largest size we want is
payloadSize / 2 rounded down, to ensure we get exactly two cells with minimal slop. The
next size down should be payloadSize / 3 rounded down, and so on. After the last precise
size (80 bytes), we proceed using a geometric progression, but round up each size to
minimize slop at the end of the block. This naturally causes the geometric progression to
turn hyperbolic for large sizes. The size class configuration happens at VM start-up, so
it can be controlled with runtime options. I found that a base of 1.4 works pretty well.
- Large allocations caused massive internal fragmentation, since the smallest large
allocation had to use exactly blockSize, and the largest small allocation used
blockSize / 2. The next size up - the first large allocation size to require two blocks -
also had 50% internal fragmentation. This is because we required large allocations to be
blockSize aligned, so that MarkedBlock::blockFor() would work. I decided to rewrite all of
that. Cells no longer have to be owned by a MarkedBlock. They can now alternatively be
owned by a LargeAllocation. These two things are abstracted as CellContainer. You know that
a cell is owned by a LargeAllocation if the MarkedBlock::atomSize / 2 bit is set.
Basically, large allocations are deliberately misaligned by 8 bytes. This actually works
out great since (1) typed arrays won't use large allocations anyway since they have their
own malloc fallback and (2) large array butterflies already have a 8 byte header, which
means that the 8 byte base misalignment aligns the large array payload on a 16 byte
boundary. I took extreme care to make sure that the isLargeAllocation bit checks are as
rare as possible; for example, ExecState::vm() skips the check because we know that callees
must be small allocations. It's also possible to use template tricks to do one check for
cell container kind, and then invoke a function specialized for MarkedBlock or a function
specialized for LargeAllocation. LargeAllocation includes stubs for all MarkedBlock methods
that get used from functions that are template-specialized like this. That's mostly to
speed up the GC marking code. Most other code can use CellContainer API or HeapCell API
directly. That's another thing: HeapCell, the common base of JSCell and auxiliary
allocations, is now smart enough to do a lot of things for you, like HeapCell::vm(),
HeapCell::heap(), HeapCell::isLargeAllocation(), and HeapCell::cellContainer(). The size
cutoff for large allocations is runtime-configurable, so long as you don't choose something
so small that callees end up large. I found that 400 bytes is roughly optimal. This means
that the MarkedBlock size classes end up being:
16, 32, 48, 64, 80, 112, 160, 224, 320
The next size class would have been 432, but that's above the 400 byte cutoff. All of this
is configurable with --sizeClassProgression and --largeAllocationCutoff. You can see what
size classes you end up with by doing --dumpSizeClasses=true.
- Copied space uses 64KB blocks, while marked space used to use 16KB blocks. Allocating a lot
of stuff in 16KB blocks was slower than allocating it in 64KB blocks because the GC had a
lot of per-block overhead. I removed this overhead: It's now 2x faster to scan all
MarkedBlocks because the list that contains the interesting meta-data is allocated on the
side, for better locality during a sequential walk. It's no longer necessary to scan
MarkedBlocks to find WeakSets, since the sets of WeakSets for eden scan and full scan are
maintained on-the-fly. It's no longer necessary to scan all MarkedBlocks to clear mark
bits because we now use versioned mark bits: to clear then, just increment the 64-bit
heap version. It's no longer necessary to scan retired MarkedBlocks while allocating
because marking retires them on-the-fly. It's no longer necessary to sort all blocks in
the IncrementalSweeper's snapshot because blocks now know if they are in the snapshot. Put
together, these optimizations allowed me to reduce block size to 16KB without losing much
performance. There is some small perf loss on JetStream/splay, but not enough to hurt
JetStream overall. I tried reducing block sizes further, to 4KB, since that is a
progression on membuster. That's not possible yet, since there is still enough per-block
overhead yet that such a reduction hurts JetStream too much. I filed a bug about improving
this further: https://bugs.webkit.org/show_bug.cgi?id=161581.
- Even after all of that, copying butterflies was still faster because it allowed us to skip
sweeping dead space. A good GC allocates over dead bytes without explicitly freeing them,
so the GC pause is O(size of live), not O(size of live + dead). O(dead) is usually much
larger than O(live), especially in an eden collection. Copying satisfies this premise while
mark+sweep does not. So, I invented a new kind of allocator: bump'n'pop. Previously, our
MarkedSpace allocator was a freelist pop. That's simple and easy to inline but requires
that we walk the block to build a free list. This means walking dead space. The new
allocator allows totally free MarkedBlocks to simply set up a bump-pointer arena instead.
The allocator is a hybrid of bump-pointer and freelist pop. It tries bump first. The bump
pointer always bumps by cellSize, so the result of filling a block with bumping looks as if
we had used freelist popping to fill it. Additionally, each MarkedBlock now has a bit to
quickly tell if the block is entirely free. This makes sweeping O(1) whenever a MarkedBlock
is completely empty, which is the common case because of the generational hypothesis: the
number of objects that survive an eden collection is a tiny fraction of the number of
objects that had been allocated, and this fraction is so small that there are typically
fewer than one survivors per MarkedBlock. This change was enough to make this change a net
win over tip-of-tree.
- FTL now shares the same allocation fast paths as everything else, which is great, because
bump'n'pop has gnarly control flow. We don't really want B3 to have to think about that
control flow, since it won't be able to improve the machine code we write ourselves. GC
fast paths are best written in assembly. So, I've empowered B3 to have even better support
for Patchpoint terminals. It's now totally fine for a Patchpoint terminal to be non-Void.
So, the new FTL allocation fast paths are just Patchpoint terminals that call through to
AssemblyHelpers::emitAllocate(). B3 still reasons about things like constant-folding the
size class calculation and constant-hoisting the allocator. Also, I gave the FTL the
ability to constant-fold some allocator logic (in case we first assume that we're doing a
variable-length allocation but then realize that the length is known). I think it makes
sense to have constant folding rules in FTL::Output, or whatever the B3 IR builder is,
since this makes lowering easier (you can constant fold during lowering more easily) and it
reduces the amount of malloc traffic. In the future, we could teach B3 how to better
constant-fold this code. That would require allowing loads to be constant-folded, which is
doable but hella tricky.
- It used to be that if a logical object allocation required two physical allocations (first
the butterfly and then the cell), then the JIT would emit the code in such a way that a
failure in the second fast path would cause us to forget the successful first physical
allocation. This was pointlessly wasteful. It turns out that it's very cheap to devote a
register to storing either the butterfly or null, because the butterfly register is anyway
going to be free inside the first allocation. The only overhead here is zeroing the
butterfly register. With that in place, we can just pass the butterfly-or-null to the slow
path, which can then either allocate a butterfly or not. So now we never waste a successful
allocation. This patch implements such a solution both in DFG (where it's easy to do this
since we control registers already) and in FTL (where it's annoying, because mutable
"butterfly-or-null" variables are hard to say in SSA; also I realized that we had code
duplicated the JSArray allocation utility, so I deduplicated it). This came up because in
one version of this patch, this wastage would resonate with some Kraken benchmark: the
benchmark would always allocate N small things followed by one bigger thing. The problem
was I accidentally adjusted the various fixed overheads in MarkedBlock in such a way that
the JSObject size class, which both the small and big thing shared for their cell, could
hold exactly N cells per MarkedBlock. Then the benchmark would always call slow path when
it allocated the big thing. So, it would end up having to allocate the big thing's large
butterfly twice, every single time! Ouch!
- It used to be that we zeroed CopiedBlocks using memset, and so array allocations enjoyed
amortization of the cost of zeroing. This doesn't work anymore - it's now up to the client
of the allocator to initialize the object to whatever state they need. It used to be that
we would just use a dumb loop. I initially changed this so that we would end up in memset
for large allocations, but this didn't actually help performance that much. I got a much
better result by playing with different memsets written in assembly. First I wrote one
using non-temporal stores. That was a small speed-up over memset. Then I tried the classic
"rep stos" approach, and holy cow that version was fast. It's a ~20% speed-up on array
allocation microbenchmarks. So, this patch adds code paths to do "rep stos" on x86_64, or
memset, or use a loop, as appropriate, for both "contiguous" arrays (holes are zero) and
double arrays (holes are PNaN). Note that the JIT always emits either a loop or a flat slab
of stores (if the size is known), but those paths in the JIT won't trigger for
NewArrayWithSize() if the size is large, since that takes us to the
operationNewArrayWithSize() slow path, which calls into JSArray::create(). That's why the
optimizations here are all in JSArray::create() - that's the hot place for large arrays
that need to be filled with holes.
All of this put together gives us neutral perf on JetStream, membuster, and PLT3, a ~1%
regression on Speedometer, and up to a 4% regression Kraken. The Kraken regression is
because Kraken was allocating exactly 1024 element arrays at a rate of 400MB/sec. This is a
best-case scenario for bump allocation. I think that we should fix bmalloc to make up the
difference, but take the hit for now because it's a crazy corner case. By comparison, the
alternative approach of using a copy barrier would have cost us 1-2%. That's the real
apples-to-apples comparison if your premise is that we should have a concurrent GC. After we
finish removing copied space, we will be barrier-ready for concurrent GC: we already have a
marking barrier and we simply won't need a copying barrier. This change gets us there for
the purposes of our benchmarks, since the remaining clients of copied space are not very
important. On the other hand, if we keep copying, then getting barrier-ready would mean
adding back the copy barrier, which costs more perf.
We might get bigger speed-ups once we remove CopiedSpace altogether. That requires moving
typed arrays and a few other weird things over to Aux MarkedSpace.
This also includes some header sanitization. The introduction of AuxiliaryBarrier, HeapCell,
and CellContainer meant that I had to include those files from everywhere. Fortunately,
just including JSCInlines.h (instead of manually including the files that includes) is
usually enough. So, I made most of JSC's cpp files include JSCInlines.h, which is something
that we were already basically doing. In places where JSCInlines.h would be too much, I just
included HeapInlines.h. This got weird, because we previously included HeapInlines.h from
JSObject.h. That's bad because it led to some circular dependencies, so I fixed it - but that
meant having to manually include HeapInlines.h from the places that previously got it
implicitly via JSObject.h. But that led to more problems for some reason: I started getting
build errors because non-JSC files were having trouble including Opcode.h. That's just silly,
since Opcode.h is meant to be an internal JSC header. So, I made it an internal header and
made it impossible to include it from outside JSC. This was a lot of work, but it was
necessary to get the patch to build on all ports. It's also a net win. There were many places
in WebCore that were transitively including a *ton* of JSC headers just because of the
JSObject.h->HeapInlines.h edge and a bunch of dependency edges that arose from some public
(for WebCore) JSC headers needing Interpreter.h or Opcode.h for bad reasons.
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* API/JSTypedArray.cpp:
* API/ObjCCallbackFunction.mm:
* API/tests/testapi.mm:
(testObjectiveCAPI):
(testWeakValue): Deleted.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/builtins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
* Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_secondary_header_includes):
* Scripts/builtins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::JumpList::link):
(JSC::AbstractMacroAssembler::JumpList::linkTo):
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
* assembler/MacroAssemblerCodeRef.cpp: Added.
(JSC::MacroAssemblerCodePtr::createLLIntCodePtr):
(JSC::MacroAssemblerCodePtr::dumpWithName):
(JSC::MacroAssemblerCodePtr::dump):
(JSC::MacroAssemblerCodeRef::createLLIntCodeRef):
(JSC::MacroAssemblerCodeRef::dump):
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::createLLIntCodePtr): Deleted.
(JSC::MacroAssemblerCodePtr::dumpWithName): Deleted.
(JSC::MacroAssemblerCodePtr::dump): Deleted.
(JSC::MacroAssemblerCodeRef::createLLIntCodeRef): Deleted.
(JSC::MacroAssemblerCodeRef::dump): Deleted.
* b3/B3BasicBlock.cpp:
(JSC::B3::BasicBlock::appendBoolConstant):
* b3/B3BasicBlock.h:
* b3/B3DuplicateTails.cpp:
* b3/B3StackmapGenerationParams.h:
* b3/testb3.cpp:
(JSC::B3::testPatchpointTerminalReturnValue):
(JSC::B3::run):
* bindings/ScriptValue.cpp:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
* bytecode/BytecodeBasicBlock.cpp:
* bytecode/BytecodeLivenessAnalysis.cpp:
* bytecode/BytecodeUseDef.h:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::callTypeFor):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::callTypeFor): Deleted.
* bytecode/CallLinkStatus.cpp:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::clearLLIntGetByIdCache):
(JSC::CodeBlock::predictedMachineCodeSize):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::clearLLIntGetByIdCache): Deleted.
* bytecode/ExecutionCounter.h:
* bytecode/Instruction.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::isNull):
(JSC::ObjectAllocationProfile::initialize):
* bytecode/Opcode.h:
(JSC::padOpcodeName):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/PreciseJumpTargets.cpp:
* bytecode/StructureStubInfo.cpp:
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::vm): Deleted.
* bytecode/UnlinkedCodeBlock.h:
* bytecode/UnlinkedInstructionStream.cpp:
* bytecode/UnlinkedInstructionStream.h:
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCompile.cpp:
* ftl/FTLJITFinalizer.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::allocateArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::compileAllocateArrayWithSize): Deleted.
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::constBool):
(JSC::FTL::Output::add):
(JSC::FTL::Output::shl):
(JSC::FTL::Output::aShr):
(JSC::FTL::Output::lShr):
(JSC::FTL::Output::zeroExt):
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::aboveOrEqual):
(JSC::FTL::Output::below):
(JSC::FTL::Output::belowOrEqual):
(JSC::FTL::Output::greaterThan):
(JSC::FTL::Output::greaterThanOrEqual):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
(JSC::FTL::Output::select):
(JSC::FTL::Output::appendSuccessor):
(JSC::FTL::Output::addIncomingToPhi):
* ftl/FTLOutput.h:
* ftl/FTLValueFromBlock.h:
(JSC::FTL::ValueFromBlock::operator bool):
(JSC::FTL::ValueFromBlock::ValueFromBlock): Deleted.
* ftl/FTLWeightedTarget.h:
(JSC::FTL::WeightedTarget::frequentedBlock):
* heap/CellContainer.h: Added.
(JSC::CellContainer::CellContainer):
(JSC::CellContainer::operator bool):
(JSC::CellContainer::isMarkedBlock):
(JSC::CellContainer::isLargeAllocation):
(JSC::CellContainer::markedBlock):
(JSC::CellContainer::largeAllocation):
* heap/CellContainerInlines.h: Added.
(JSC::CellContainer::isMarked):
(JSC::CellContainer::isMarkedOrNewlyAllocated):
(JSC::CellContainer::noteMarked):
(JSC::CellContainer::cellSize):
(JSC::CellContainer::weakSet):
(JSC::CellContainer::flipIfNecessary):
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::~ConservativeRoots):
(JSC::ConservativeRoots::grow):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::genericAddSpan):
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots):
* heap/CopyToken.h:
* heap/FreeList.cpp: Added.
(JSC::FreeList::dump):
* heap/FreeList.h: Added.
(JSC::FreeList::FreeList):
(JSC::FreeList::list):
(JSC::FreeList::bump):
(JSC::FreeList::operator==):
(JSC::FreeList::operator!=):
(JSC::FreeList::operator bool):
(JSC::FreeList::allocationWillFail):
(JSC::FreeList::allocationWillSucceed):
* heap/GCTypeMap.h: Added.
(JSC::GCTypeMap::operator[]):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::finalizeUnconditionalFinalizers):
(JSC::Heap::markRoots):
(JSC::Heap::copyBackingStores):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::gatherJSStackRoots):
(JSC::Heap::gatherScratchBufferRoots):
(JSC::Heap::clearLivenessData):
(JSC::Heap::visitSmallStrings):
(JSC::Heap::visitConservativeRoots):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::gatherExtraHeapSnapshotData):
(JSC::Heap::removeDeadHeapSnapshotNodes):
(JSC::Heap::visitProtectedObjects):
(JSC::Heap::visitArgumentBuffers):
(JSC::Heap::visitException):
(JSC::Heap::visitStrongHandles):
(JSC::Heap::visitHandleStack):
(JSC::Heap::visitSamplingProfiler):
(JSC::Heap::traceCodeBlocksAndJITStubRoutines):
(JSC::Heap::converge):
(JSC::Heap::visitWeakHandles):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::clearUnmarkedExecutables):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collect):
(JSC::Heap::collectWithoutAnySweep):
(JSC::Heap::collectImpl):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::willStartCollection):
(JSC::Heap::flushOldStructureIDTables):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::stopAllocation):
(JSC::Heap::prepareForMarking):
(JSC::Heap::reapWeakHandles):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::sweepArrayBuffers):
(JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
(JSC::MarkedBlockSnapshotFunctor::operator()):
(JSC::Heap::snapshotMarkedSpace):
(JSC::Heap::deleteSourceProviderCaches):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::Heap::resetAllocators):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::resumeCompilerThreads):
(JSC::Zombify::visit):
(JSC::Heap::forEachCodeBlockImpl):
* heap/Heap.h:
(JSC::Heap::allocatorForObjectWithoutDestructor):
(JSC::Heap::allocatorForObjectWithDestructor):
(JSC::Heap::allocatorForAuxiliaryData):
(JSC::Heap::jitStubRoutines):
(JSC::Heap::codeBlockSet):
(JSC::Heap::storageAllocator): Deleted.
* heap/HeapCell.h:
(JSC::HeapCell::isZapped): Deleted.
* heap/HeapCellInlines.h: Added.
(JSC::HeapCell::isLargeAllocation):
(JSC::HeapCell::cellContainer):
(JSC::HeapCell::markedBlock):
(JSC::HeapCell::largeAllocation):
(JSC::HeapCell::heap):
(JSC::HeapCell::vm):
(JSC::HeapCell::cellSize):
(JSC::HeapCell::allocatorAttributes):
(JSC::HeapCell::destructionMode):
(JSC::HeapCell::cellKind):
* heap/HeapInlines.h:
(JSC::Heap::heap):
(JSC::Heap::isLive):
(JSC::Heap::isMarked):
(JSC::Heap::testAndSetMarked):
(JSC::Heap::setMarked):
(JSC::Heap::cellSize):
(JSC::Heap::forEachCodeBlock):
(JSC::Heap::allocateObjectOfType):
(JSC::Heap::subspaceForObjectOfType):
(JSC::Heap::allocatorForObjectOfType):
(JSC::Heap::allocateAuxiliary):
(JSC::Heap::tryAllocateAuxiliary):
(JSC::Heap::tryReallocateAuxiliary):
(JSC::Heap::isPointerGCObject): Deleted.
(JSC::Heap::isValueGCObject): Deleted.
* heap/HeapOperation.cpp: Added.
(WTF::printInternal):
* heap/HeapOperation.h:
* heap/HeapUtil.h: Added.
(JSC::HeapUtil::findGCObjectPointersForMarking):
(JSC::HeapUtil::isPointerGCObjectJSCell):
(JSC::HeapUtil::isValueGCObject):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::sweepNextBlock):
* heap/IncrementalSweeper.h:
* heap/LargeAllocation.cpp: Added.
(JSC::LargeAllocation::tryCreate):
(JSC::LargeAllocation::LargeAllocation):
(JSC::LargeAllocation::lastChanceToFinalize):
(JSC::LargeAllocation::shrink):
(JSC::LargeAllocation::visitWeakSet):
(JSC::LargeAllocation::reapWeakSet):
(JSC::LargeAllocation::flip):
(JSC::LargeAllocation::isEmpty):
(JSC::LargeAllocation::sweep):
(JSC::LargeAllocation::destroy):
(JSC::LargeAllocation::dump):
* heap/LargeAllocation.h: Added.
(JSC::LargeAllocation::fromCell):
(JSC::LargeAllocation::cell):
(JSC::LargeAllocation::isLargeAllocation):
(JSC::LargeAllocation::heap):
(JSC::LargeAllocation::vm):
(JSC::LargeAllocation::weakSet):
(JSC::LargeAllocation::clearNewlyAllocated):
(JSC::LargeAllocation::isNewlyAllocated):
(JSC::LargeAllocation::isMarked):
(JSC::LargeAllocation::isMarkedOrNewlyAllocated):
(JSC::LargeAllocation::isLive):
(JSC::LargeAllocation::hasValidCell):
(JSC::LargeAllocation::cellSize):
(JSC::LargeAllocation::aboveLowerBound):
(JSC::LargeAllocation::belowUpperBound):
(JSC::LargeAllocation::contains):
(JSC::LargeAllocation::attributes):
(JSC::LargeAllocation::flipIfNecessary):
(JSC::LargeAllocation::flipIfNecessaryConcurrently):
(JSC::LargeAllocation::testAndSetMarked):
(JSC::LargeAllocation::setMarked):
(JSC::LargeAllocation::clearMarked):
(JSC::LargeAllocation::noteMarked):
(JSC::LargeAllocation::headerSize):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::MarkedAllocator):
(JSC::MarkedAllocator::isPagedOut):
(JSC::MarkedAllocator::retire):
(JSC::MarkedAllocator::filterNextBlock):
(JSC::MarkedAllocator::setNextBlockToSweep):
(JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
(JSC::MarkedAllocator::tryAllocateWithoutCollecting):
(JSC::MarkedAllocator::allocateSlowCase):
(JSC::MarkedAllocator::tryAllocateSlowCase):
(JSC::MarkedAllocator::allocateSlowCaseImpl):
(JSC::blockHeaderSize):
(JSC::MarkedAllocator::blockSizeForBytes):
(JSC::MarkedAllocator::tryAllocateBlock):
(JSC::MarkedAllocator::addBlock):
(JSC::MarkedAllocator::removeBlock):
(JSC::MarkedAllocator::stopAllocating):
(JSC::MarkedAllocator::reset):
(JSC::MarkedAllocator::lastChanceToFinalize):
(JSC::MarkedAllocator::setFreeList):
(JSC::isListPagedOut): Deleted.
(JSC::MarkedAllocator::tryAllocateHelper): Deleted.
(JSC::MarkedAllocator::tryPopFreeList): Deleted.
(JSC::MarkedAllocator::tryAllocate): Deleted.
(JSC::MarkedAllocator::allocateBlock): Deleted.
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::takeLastActiveBlock):
(JSC::MarkedAllocator::offsetOfFreeList):
(JSC::MarkedAllocator::offsetOfCellSize):
(JSC::MarkedAllocator::tryAllocate):
(JSC::MarkedAllocator::allocate):
(JSC::MarkedAllocator::forEachBlock):
(JSC::MarkedAllocator::offsetOfFreeListHead): Deleted.
(JSC::MarkedAllocator::MarkedAllocator): Deleted.
(JSC::MarkedAllocator::init): Deleted.
(JSC::MarkedAllocator::stopAllocating): Deleted.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::tryCreate):
(JSC::MarkedBlock::Handle::Handle):
(JSC::MarkedBlock::Handle::~Handle):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
(JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode):
(JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
(JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
(JSC::SetNewlyAllocatedFunctor::operator()):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::lastChanceToFinalize):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::Handle::zap):
(JSC::MarkedBlock::Handle::forEachFreeCell):
(JSC::MarkedBlock::flipIfNecessary):
(JSC::MarkedBlock::Handle::flipIfNecessary):
(JSC::MarkedBlock::flipIfNecessarySlow):
(JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
(JSC::MarkedBlock::clearMarks):
(JSC::MarkedBlock::assertFlipped):
(JSC::MarkedBlock::needsFlip):
(JSC::MarkedBlock::Handle::needsFlip):
(JSC::MarkedBlock::Handle::willRemoveBlock):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::markCount):
(JSC::MarkedBlock::Handle::isEmpty):
(JSC::MarkedBlock::clearHasAnyMarked):
(JSC::MarkedBlock::noteMarkedSlow):
(WTF::printInternal):
(JSC::MarkedBlock::create): Deleted.
(JSC::MarkedBlock::destroy): Deleted.
(JSC::MarkedBlock::callDestructor): Deleted.
(JSC::MarkedBlock::specializedSweep): Deleted.
(JSC::MarkedBlock::sweep): Deleted.
(JSC::MarkedBlock::sweepHelper): Deleted.
(JSC::MarkedBlock::stopAllocating): Deleted.
(JSC::MarkedBlock::clearMarksWithCollectionType): Deleted.
(JSC::MarkedBlock::lastChanceToFinalize): Deleted.
(JSC::MarkedBlock::resumeAllocating): Deleted.
(JSC::MarkedBlock::didRetireBlock): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::VoidFunctor::returnValue):
(JSC::MarkedBlock::CountFunctor::CountFunctor):
(JSC::MarkedBlock::CountFunctor::count):
(JSC::MarkedBlock::CountFunctor::returnValue):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
(JSC::MarkedBlock::Handle::isOnBlocksToSweep):
(JSC::MarkedBlock::Handle::setIsOnBlocksToSweep):
(JSC::MarkedBlock::Handle::state):
(JSC::MarkedBlock::needsDestruction):
(JSC::MarkedBlock::handle):
(JSC::MarkedBlock::Handle::block):
(JSC::MarkedBlock::firstAtom):
(JSC::MarkedBlock::atoms):
(JSC::MarkedBlock::isAtomAligned):
(JSC::MarkedBlock::Handle::cellAlign):
(JSC::MarkedBlock::blockFor):
(JSC::MarkedBlock::Handle::allocator):
(JSC::MarkedBlock::Handle::heap):
(JSC::MarkedBlock::Handle::vm):
(JSC::MarkedBlock::vm):
(JSC::MarkedBlock::Handle::weakSet):
(JSC::MarkedBlock::weakSet):
(JSC::MarkedBlock::Handle::shrink):
(JSC::MarkedBlock::Handle::visitWeakSet):
(JSC::MarkedBlock::Handle::reapWeakSet):
(JSC::MarkedBlock::Handle::cellSize):
(JSC::MarkedBlock::cellSize):
(JSC::MarkedBlock::Handle::attributes):
(JSC::MarkedBlock::attributes):
(JSC::MarkedBlock::Handle::needsDestruction):
(JSC::MarkedBlock::Handle::destruction):
(JSC::MarkedBlock::Handle::cellKind):
(JSC::MarkedBlock::Handle::markCount):
(JSC::MarkedBlock::Handle::size):
(JSC::MarkedBlock::atomNumber):
(JSC::MarkedBlock::flipIfNecessary):
(JSC::MarkedBlock::flipIfNecessaryConcurrently):
(JSC::MarkedBlock::Handle::flipIfNecessary):
(JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
(JSC::MarkedBlock::Handle::flipForEdenCollection):
(JSC::MarkedBlock::assertFlipped):
(JSC::MarkedBlock::Handle::assertFlipped):
(JSC::MarkedBlock::isMarked):
(JSC::MarkedBlock::testAndSetMarked):
(JSC::MarkedBlock::Handle::isNewlyAllocated):
(JSC::MarkedBlock::Handle::setNewlyAllocated):
(JSC::MarkedBlock::Handle::clearNewlyAllocated):
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
(JSC::MarkedBlock::isMarkedOrNewlyAllocated):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::isAtom):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::Handle::forEachCell):
(JSC::MarkedBlock::Handle::forEachLiveCell):
(JSC::MarkedBlock::Handle::forEachDeadCell):
(JSC::MarkedBlock::Handle::needsSweeping):
(JSC::MarkedBlock::Handle::isAllocated):
(JSC::MarkedBlock::Handle::isMarked):
(JSC::MarkedBlock::Handle::isFreeListed):
(JSC::MarkedBlock::hasAnyMarked):
(JSC::MarkedBlock::noteMarked):
(WTF::MarkedBlockHash::hash):
(JSC::MarkedBlock::FreeList::FreeList): Deleted.
(JSC::MarkedBlock::allocator): Deleted.
(JSC::MarkedBlock::heap): Deleted.
(JSC::MarkedBlock::shrink): Deleted.
(JSC::MarkedBlock::visitWeakSet): Deleted.
(JSC::MarkedBlock::reapWeakSet): Deleted.
(JSC::MarkedBlock::willRemoveBlock): Deleted.
(JSC::MarkedBlock::didConsumeFreeList): Deleted.
(JSC::MarkedBlock::markCount): Deleted.
(JSC::MarkedBlock::isEmpty): Deleted.
(JSC::MarkedBlock::destruction): Deleted.
(JSC::MarkedBlock::cellKind): Deleted.
(JSC::MarkedBlock::size): Deleted.
(JSC::MarkedBlock::capacity): Deleted.
(JSC::MarkedBlock::setMarked): Deleted.
(JSC::MarkedBlock::clearMarked): Deleted.
(JSC::MarkedBlock::isNewlyAllocated): Deleted.
(JSC::MarkedBlock::setNewlyAllocated): Deleted.
(JSC::MarkedBlock::clearNewlyAllocated): Deleted.
(JSC::MarkedBlock::isLive): Deleted.
(JSC::MarkedBlock::isLiveCell): Deleted.
(JSC::MarkedBlock::forEachCell): Deleted.
(JSC::MarkedBlock::forEachLiveCell): Deleted.
(JSC::MarkedBlock::forEachDeadCell): Deleted.
(JSC::MarkedBlock::needsSweeping): Deleted.
(JSC::MarkedBlock::isAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrRetired): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::initializeSizeClassForStepSize):
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::~MarkedSpace):
(JSC::MarkedSpace::lastChanceToFinalize):
(JSC::MarkedSpace::allocate):
(JSC::MarkedSpace::tryAllocate):
(JSC::MarkedSpace::allocateLarge):
(JSC::MarkedSpace::tryAllocateLarge):
(JSC::MarkedSpace::sweep):
(JSC::MarkedSpace::sweepLargeAllocations):
(JSC::MarkedSpace::zombifySweep):
(JSC::MarkedSpace::resetAllocators):
(JSC::MarkedSpace::visitWeakSets):
(JSC::MarkedSpace::reapWeakSets):
(JSC::MarkedSpace::stopAllocating):
(JSC::MarkedSpace::prepareForMarking):
(JSC::MarkedSpace::resumeAllocating):
(JSC::MarkedSpace::isPagedOut):
(JSC::MarkedSpace::freeBlock):
(JSC::MarkedSpace::freeOrShrinkBlock):
(JSC::MarkedSpace::shrink):
(JSC::MarkedSpace::clearNewlyAllocated):
(JSC::VerifyMarked::operator()):
(JSC::MarkedSpace::flip):
(JSC::MarkedSpace::objectCount):
(JSC::MarkedSpace::size):
(JSC::MarkedSpace::capacity):
(JSC::MarkedSpace::addActiveWeakSet):
(JSC::MarkedSpace::didAddBlock):
(JSC::MarkedSpace::didAllocateInBlock):
(JSC::MarkedSpace::forEachAllocator): Deleted.
(JSC::VerifyMarkedOrRetired::operator()): Deleted.
(JSC::MarkedSpace::clearMarks): Deleted.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::sizeClassToIndex):
(JSC::MarkedSpace::indexToSizeClass):
(JSC::MarkedSpace::version):
(JSC::MarkedSpace::blocksWithNewObjects):
(JSC::MarkedSpace::largeAllocations):
(JSC::MarkedSpace::largeAllocationsNurseryOffset):
(JSC::MarkedSpace::largeAllocationsOffsetForThisCollection):
(JSC::MarkedSpace::largeAllocationsForThisCollectionBegin):
(JSC::MarkedSpace::largeAllocationsForThisCollectionEnd):
(JSC::MarkedSpace::largeAllocationsForThisCollectionSize):
(JSC::MarkedSpace::forEachLiveCell):
(JSC::MarkedSpace::forEachDeadCell):
(JSC::MarkedSpace::allocatorFor):
(JSC::MarkedSpace::destructorAllocatorFor):
(JSC::MarkedSpace::auxiliaryAllocatorFor):
(JSC::MarkedSpace::allocateWithoutDestructor):
(JSC::MarkedSpace::allocateWithDestructor):
(JSC::MarkedSpace::allocateAuxiliary):
(JSC::MarkedSpace::tryAllocateAuxiliary):
(JSC::MarkedSpace::forEachBlock):
(JSC::MarkedSpace::forEachAllocator):
(JSC::MarkedSpace::optimalSizeFor):
(JSC::MarkedSpace::didAddBlock): Deleted.
(JSC::MarkedSpace::didAllocateInBlock): Deleted.
(JSC::MarkedSpace::objectCount): Deleted.
(JSC::MarkedSpace::size): Deleted.
(JSC::MarkedSpace::capacity): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::markAuxiliary):
(JSC::SlotVisitor::noteLiveAuxiliaryCell):
(JSC::SlotVisitor::visitChildren):
* heap/SlotVisitor.h:
* heap/WeakBlock.cpp:
(JSC::WeakBlock::create):
(JSC::WeakBlock::WeakBlock):
(JSC::WeakBlock::visit):
(JSC::WeakBlock::reap):
* heap/WeakBlock.h:
(JSC::WeakBlock::disconnectContainer):
(JSC::WeakBlock::disconnectMarkedBlock): Deleted.
* heap/WeakSet.cpp:
(JSC::WeakSet::~WeakSet):
(JSC::WeakSet::sweep):
(JSC::WeakSet::shrink):
(JSC::WeakSet::addAllocator):
* heap/WeakSet.h:
(JSC::WeakSet::container):
(JSC::WeakSet::setContainer):
(JSC::WeakSet::WeakSet):
(JSC::WeakSet::visit):
(JSC::WeakSet::shrink): Deleted.
* heap/WeakSetInlines.h:
(JSC::WeakSet::allocate):
* inspector/InjectedScriptManager.cpp:
* inspector/JSGlobalObjectInspectorController.cpp:
* inspector/JSJavaScriptCallFrame.cpp:
* inspector/ScriptDebugServer.cpp:
* inspector/agents/InspectorDebuggerAgent.cpp:
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
* interpreter/Interpreter.cpp:
(JSC::loadVarargs):
(JSC::StackFrame::sourceID): Deleted.
(JSC::StackFrame::sourceURL): Deleted.
(JSC::StackFrame::functionName): Deleted.
(JSC::StackFrame::computeLineAndColumn): Deleted.
(JSC::StackFrame::toString): Deleted.
* interpreter/Interpreter.h:
(JSC::StackFrame::isNative): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
(JSC::AssemblyHelpers::emitAllocate):
(JSC::AssemblyHelpers::emitAllocateJSCell):
(JSC::AssemblyHelpers::emitAllocateJSObject):
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
* jit/JIT.cpp:
(JSC::JIT::compileCTINativeCall):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::JIT::compileCTINativeCall): Deleted.
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITExceptions.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_create_this):
(JSC::JIT::emitSlow_op_create_this):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
* jit/JITThunks.cpp:
* jit/JITThunks.h:
* jsc.cpp:
(functionDescribeArray):
(main):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntExceptions.cpp:
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ModuleAnalyzer.cpp:
* parser/NodeConstructors.h:
* parser/Nodes.h:
* profiler/ProfilerBytecode.cpp:
* profiler/ProfilerBytecode.h:
* profiler/ProfilerBytecodeSequence.cpp:
* runtime/ArrayConventions.h:
(JSC::indexingHeaderForArrayStorage):
(JSC::baseIndexingHeaderForArrayStorage):
(JSC::indexingHeaderForArray): Deleted.
(JSC::baseIndexingHeaderForArray): Deleted.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
(JSC::concatAppendOne):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/ArrayStorage.h:
(JSC::ArrayStorage::vectorLength):
(JSC::ArrayStorage::totalSizeFor):
(JSC::ArrayStorage::totalSize):
(JSC::ArrayStorage::availableVectorLength):
(JSC::ArrayStorage::optimalVectorLength):
(JSC::ArrayStorage::sizeFor): Deleted.
* runtime/AuxiliaryBarrier.h: Added.
(JSC::AuxiliaryBarrier::AuxiliaryBarrier):
(JSC::AuxiliaryBarrier::clear):
(JSC::AuxiliaryBarrier::get):
(JSC::AuxiliaryBarrier::slot):
(JSC::AuxiliaryBarrier::operator bool):
(JSC::AuxiliaryBarrier::setWithoutBarrier):
* runtime/AuxiliaryBarrierInlines.h: Added.
(JSC::AuxiliaryBarrier<T>::AuxiliaryBarrier):
(JSC::AuxiliaryBarrier<T>::set):
* runtime/Butterfly.h:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::availableContiguousVectorLength):
(JSC::Butterfly::optimalContiguousVectorLength):
(JSC::Butterfly::createUninitialized):
(JSC::Butterfly::growArrayRight):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createEmpty):
* runtime/CommonSlowPathsExceptions.cpp:
* runtime/CommonSlowPathsExceptions.h:
* runtime/DataView.cpp:
* runtime/DirectArguments.h:
* runtime/ECMAScriptSpecInternalFunctions.cpp:
* runtime/Error.cpp:
* runtime/Error.h:
* runtime/ErrorInstance.cpp:
* runtime/ErrorInstance.h:
* runtime/Exception.cpp:
* runtime/Exception.h:
* runtime/GeneratorFrame.cpp:
* runtime/GeneratorPrototype.cpp:
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::InternalFunction):
* runtime/IntlCollator.cpp:
* runtime/IntlCollatorConstructor.cpp:
* runtime/IntlCollatorPrototype.cpp:
* runtime/IntlDateTimeFormat.cpp:
* runtime/IntlDateTimeFormatConstructor.cpp:
* runtime/IntlDateTimeFormatPrototype.cpp:
* runtime/IntlNumberFormat.cpp:
* runtime/IntlNumberFormatConstructor.cpp:
* runtime/IntlNumberFormatPrototype.cpp:
* runtime/IntlObject.cpp:
* runtime/IteratorPrototype.cpp:
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateUninitialized):
(JSC::JSArray::setLengthWritable):
(JSC::JSArray::unshiftCountSlowCase):
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::appendMemcpy):
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::push):
(JSC::JSArray::fastSlice):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithArrayStorage):
(JSC::JSArray::fillArgList):
(JSC::JSArray::copyToArguments):
* runtime/JSArray.h:
(JSC::createContiguousArrayButterfly):
(JSC::createArrayButterfly):
(JSC::JSArray::create):
(JSC::JSArray::tryCreateUninitialized): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSCInlines.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContextAssumingStructure):
* runtime/JSCallee.cpp:
(JSC::JSCallee::JSCallee):
* runtime/JSCell.cpp:
(JSC::JSCell::estimatedSize):
* runtime/JSCell.h:
(JSC::JSCell::cellStateOffset): Deleted.
* runtime/JSCellInlines.h:
(JSC::ExecState::vm):
(JSC::JSCell::classInfo):
(JSC::JSCell::callDestructor):
(JSC::JSCell::vm): Deleted.
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
(JSC::JSFunction::setFunctionName):
(JSC::JSFunction::reifyLength):
(JSC::JSFunction::reifyName):
(JSC::JSFunction::reifyLazyPropertyIfNeeded):
(JSC::JSFunction::reifyBoundNameIfNeeded):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
(JSC::JSFunction::JSFunction):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
* runtime/JSInternalPromise.cpp:
* runtime/JSInternalPromiseConstructor.cpp:
* runtime/JSInternalPromiseDeferred.cpp:
* runtime/JSInternalPromisePrototype.cpp:
* runtime/JSJob.cpp:
* runtime/JSMapIterator.cpp:
* runtime/JSModuleNamespaceObject.cpp:
* runtime/JSModuleRecord.cpp:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::createInitialArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::putByIndexBeyondVectorLength):
(JSC::JSObject::putDirectIndexBeyondVectorLength):
(JSC::JSObject::getNewVectorLength):
(JSC::JSObject::increaseVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::growOutOfLineStorage):
(JSC::JSObject::copyButterfly): Deleted.
(JSC::JSObject::copyBackingStore): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::globalObject):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary): Deleted.
* runtime/JSObjectInlines.h:
* runtime/JSPromise.cpp:
* runtime/JSPromiseConstructor.cpp:
* runtime/JSPromiseDeferred.cpp:
* runtime/JSPromisePrototype.cpp:
* runtime/JSPropertyNameIterator.cpp:
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
* runtime/JSScope.h:
(JSC::JSScope::globalObject):
(JSC::JSScope::vm): Deleted.
* runtime/JSSetIterator.cpp:
* runtime/JSStringIterator.cpp:
* runtime/JSTemplateRegistryKey.cpp:
* runtime/JSTypedArrayViewConstructor.cpp:
* runtime/JSTypedArrayViewPrototype.cpp:
* runtime/JSWeakMap.cpp:
* runtime/JSWeakSet.cpp:
* runtime/MapConstructor.cpp:
* runtime/MapIteratorPrototype.cpp:
* runtime/MapPrototype.cpp:
* runtime/NativeErrorConstructor.cpp:
* runtime/NativeStdFunctionCell.cpp:
* runtime/Operations.h:
(JSC::scribbleFreeCells):
(JSC::scribble):
* runtime/Options.h:
* runtime/PropertyTable.cpp:
* runtime/ProxyConstructor.cpp:
* runtime/ProxyObject.cpp:
* runtime/ProxyRevoke.cpp:
* runtime/RegExp.cpp:
(JSC::RegExp::match):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::matchCompareWithInterpreter):
* runtime/RegExp.h:
* runtime/RegExpConstructor.h:
* runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
(JSC::createRegExpMatchesArray):
* runtime/RegExpPrototype.cpp:
(JSC::genericSplit):
* runtime/RuntimeType.cpp:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SetConstructor.cpp:
* runtime/SetIteratorPrototype.cpp:
* runtime/SetPrototype.cpp:
* runtime/StackFrame.cpp: Added.
(JSC::StackFrame::sourceID):
(JSC::StackFrame::sourceURL):
(JSC::StackFrame::functionName):
(JSC::StackFrame::computeLineAndColumn):
(JSC::StackFrame::toString):
* runtime/StackFrame.h: Added.
(JSC::StackFrame::isNative):
* runtime/StringConstructor.cpp:
* runtime/StringIteratorPrototype.cpp:
* runtime/StructureInlines.h:
(JSC::Structure::propertyTable):
* runtime/TemplateRegistry.cpp:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
* runtime/TestRunnerUtils.h:
* runtime/TypeProfilerLog.cpp:
* runtime/TypeSet.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureStackCapacityForCLoop):
(JSC::VM::isSafeToRecurseSoftCLoop):
* runtime/VM.h:
* runtime/VMEntryScope.h:
* runtime/VMInlines.h:
(JSC::VM::ensureStackCapacityFor):
(JSC::VM::isSafeToRecurseSoft):
* runtime/WeakMapConstructor.cpp:
* runtime/WeakMapData.cpp:
* runtime/WeakMapPrototype.cpp:
* runtime/WeakSetConstructor.cpp:
* runtime/WeakSetPrototype.cpp:
* testRegExp.cpp:
(testOneRegExp):
* tools/JSDollarVM.cpp:
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::isInObjectSpace):
Source/WebCore:
No new tests because no new WebCore behavior.
Just rewiring #includes.
* ForwardingHeaders/heap/HeapInlines.h: Added.
* ForwardingHeaders/interpreter/Interpreter.h: Removed.
* ForwardingHeaders/runtime/AuxiliaryBarrierInlines.h: Added.
* Modules/indexeddb/IDBCursorWithValue.cpp:
* Modules/indexeddb/client/TransactionOperation.cpp:
* Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:
* Modules/indexeddb/server/UniqueIDBDatabase.cpp:
* bindings/js/JSApplePayPaymentAuthorizedEventCustom.cpp:
* bindings/js/JSApplePayPaymentMethodSelectedEventCustom.cpp:
* bindings/js/JSApplePayShippingContactSelectedEventCustom.cpp:
* bindings/js/JSApplePayShippingMethodSelectedEventCustom.cpp:
* bindings/js/JSClientRectCustom.cpp:
* bindings/js/JSDOMBinding.cpp:
* bindings/js/JSDOMBinding.h:
* bindings/js/JSDeviceMotionEventCustom.cpp:
* bindings/js/JSDeviceOrientationEventCustom.cpp:
* bindings/js/JSErrorEventCustom.cpp:
* bindings/js/JSIDBCursorWithValueCustom.cpp:
* bindings/js/JSIDBIndexCustom.cpp:
* bindings/js/JSPopStateEventCustom.cpp:
* bindings/js/JSWebGL2RenderingContextCustom.cpp:
* bindings/js/JSWorkerGlobalScopeCustom.cpp:
* bindings/js/WorkerScriptController.cpp:
* contentextensions/ContentExtensionParser.cpp:
* dom/ErrorEvent.cpp:
* html/HTMLCanvasElement.cpp:
* html/MediaDocument.cpp:
* inspector/CommandLineAPIModule.cpp:
* loader/EmptyClients.cpp:
* page/CaptionUserPreferences.cpp:
* page/Frame.cpp:
* page/PageGroup.cpp:
* page/UserContentController.cpp:
* platform/mock/mediasource/MockBox.cpp:
* testing/GCObservation.cpp:
Source/WebKit2:
Just rewiring some #includes.
* UIProcess/ViewGestureController.cpp:
* UIProcess/WebPageProxy.cpp:
* UIProcess/WebProcessPool.cpp:
* UIProcess/WebProcessProxy.cpp:
* WebProcess/InjectedBundle/DOM/InjectedBundleRangeHandle.cpp:
* WebProcess/Plugins/Netscape/JSNPObject.cpp:
Source/WTF:
I needed tryFastAlignedMalloc() so I added it.
* wtf/FastMalloc.cpp:
(WTF::tryFastAlignedMalloc):
* wtf/FastMalloc.h:
* wtf/ParkingLot.cpp:
(WTF::ParkingLot::forEachImpl):
(WTF::ParkingLot::forEach): Deleted.
* wtf/ParkingLot.h:
(WTF::ParkingLot::parkConditionally):
(WTF::ParkingLot::unparkOne):
(WTF::ParkingLot::forEach):
* wtf/ScopedLambda.h:
(WTF::scopedLambdaRef):
* wtf/SentinelLinkedList.h:
(WTF::SentinelLinkedList::forEach):
(WTF::RawNode>::takeFrom):
* wtf/SimpleStats.h:
(WTF::SimpleStats::operator bool):
(WTF::SimpleStats::operator!): Deleted.
Tools:
* DumpRenderTree/TestRunner.cpp:
* DumpRenderTree/mac/DumpRenderTree.mm:
(DumpRenderTreeMain):
* Scripts/run-jsc-stress-tests:
* TestWebKitAPI/Tests/WTF/Vector.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/179778@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@205462 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-09-06 01:02:22 +00:00
|
|
|
template <typename T, typename RawNode>
|
|
|
|
inline void SentinelLinkedList<T, RawNode>::takeFrom(SentinelLinkedList<T, RawNode>& other)
|
|
|
|
{
|
|
|
|
if (other.isEmpty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
m_tailSentinel.prev()->setNext(other.m_headSentinel.next());
|
|
|
|
other.m_headSentinel.next()->setPrev(m_tailSentinel.prev());
|
|
|
|
|
|
|
|
m_tailSentinel.setPrev(other.m_tailSentinel.prev());
|
|
|
|
m_tailSentinel.prev()->setNext(&m_tailSentinel);
|
|
|
|
|
|
|
|
other.m_headSentinel.setNext(&other.m_tailSentinel);
|
|
|
|
other.m_tailSentinel.setPrev(&other.m_headSentinel);
|
|
|
|
}
|
|
|
|
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
template<typename T>
|
|
|
|
using PackedRawSentinelNode = BasicRawSentinelNode<T, PackedPtrTraits<T>>;
|
|
|
|
|
2011-02-15 23:54:06 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 09:23:55 +00:00
|
|
|
using WTF::BasicRawSentinelNode;
|
[JSC] Compress Watchpoint size by using enum type and Packed<> data structure
https://bugs.webkit.org/show_bug.cgi?id=197730
Reviewed by Filip Pizlo.
Source/JavaScriptCore:
Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
reducing each size of Watchpoint reduces memory footprint significantly.
As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
ARM64 only takes 2 pointers size.
ORIGINAL X86_64 ARM64
WatchpointSet: 40 32 28
CodeBlockJettisoningWatchpoint: 32 19 15
StructureStubClearingWatchpoint: 56 48 40
AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24 13 11
AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint: 24 13 11
FunctionRareData::AllocationProfileClearingWatchpoint: 32 19 15
ObjectToStringAdaptiveStructureWatchpoint: 56 48 40
LLIntPrototypeLoadAdaptiveStructureWatchpoint: 64 48 48
DFG::AdaptiveStructureWatchpoint: 56 48 40
While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* bytecode/CodeOrigin.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/Watchpoint.cpp:
(JSC::Watchpoint::fire):
* bytecode/Watchpoint.h:
(JSC::Watchpoint::Watchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* heap/PackedCellPtr.h: Added.
* runtime/FunctionRareData.h:
* runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
* runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::clearObjectToStringValue):
(JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
(JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
* runtime/StructureRareData.h:
Source/WTF:
This patch introduces a new data structures, WTF::Packed, WTF::PackedPtr, and WTF::PackedAlignedPtr.
- WTF::Packed
WTF::Packed is data storage. We can read and write trivial (in C++ term [1]) data to this storage. The difference to
the usual storage is that the alignment of this storage is always 1. We access the underlying data by using unalignedLoad/unalignedStore.
This class offers alignment = 1 data structure instead of missing the following characteristics.
1. Load / Store are non atomic even if the data size is within a pointer width. We should not use this for a member which can be accessed
in a racy way. (e.g. fields accessed optimistically from the concurrent compilers).
2. We cannot take reference / pointer to the underlying storage since they are unaligned.
3. Access to this storage is unaligned access. The code is using memcpy, and the compiler will convert to an appropriate unaligned access
in certain architectures (x86_64 / ARM64). It could be slow. So use it for non performance sensitive & memory sensitive places.
- WTF::PackedPtr
WTF::PackedPtr is a specialization of WTF::Packed<T*>. And it is basically WTF::PackedAlignedPtr with alignment = 1. We further compact
the pointer by leveraging the platform specific knowledge. In 64bit architectures, the effective width of pointers are less than 64 bit.
In x86_64, it is 48 bits. And Darwin ARM64 is further smaller, 36 bits. This information allows us to compact the pointer to 6 bytes in
x86_64 and 5 bytes in Darwin ARM64.
- WTF::PackedAlignedPtr
WTF::PackedAlignedPtr is the WTF::PackedPtr with alignment information of the T. If we use this alignment information, we could reduce the
size of packed pointer further in some cases. For example, since we guarantee that JSCells are 16 byte aligned, low 4 bits are empty. Leveraging
this information in Darwin ARM64 platform allows us to make packed JSCell pointer 4 bytes (36 - 4 bits). We do not use passed alignment
information if it is not profitable.
We also have PackedPtrTraits. This is new PtrTraits and use it for various data structures such as Bag<>.
[1]: https://en.cppreference.com/w/cpp/types/is_trivial
* WTF.xcodeproj/project.pbxproj:
* wtf/Bag.h:
(WTF::Bag::clear):
(WTF::Bag::iterator::operator++):
* wtf/CMakeLists.txt:
* wtf/DumbPtrTraits.h:
* wtf/DumbValueTraits.h:
* wtf/MathExtras.h:
(WTF::clzConstexpr):
(WTF::clz):
(WTF::ctzConstexpr):
(WTF::ctz):
(WTF::getLSBSetConstexpr):
(WTF::getMSBSetConstexpr):
* wtf/Packed.h: Added.
(WTF::Packed::Packed):
(WTF::Packed::get const):
(WTF::Packed::set):
(WTF::Packed::operator=):
(WTF::Packed::exchange):
(WTF::Packed::swap):
(WTF::alignof):
(WTF::PackedPtrTraits::exchange):
(WTF::PackedPtrTraits::swap):
(WTF::PackedPtrTraits::unwrap):
* wtf/Platform.h:
* wtf/SentinelLinkedList.h:
(WTF::BasicRawSentinelNode::BasicRawSentinelNode):
(WTF::BasicRawSentinelNode::prev):
(WTF::BasicRawSentinelNode::next):
(WTF::PtrTraits>::remove):
(WTF::PtrTraits>::prepend):
(WTF::PtrTraits>::append):
(WTF::RawNode>::SentinelLinkedList):
(WTF::RawNode>::remove):
(WTF::BasicRawSentinelNode<T>::remove): Deleted.
(WTF::BasicRawSentinelNode<T>::prepend): Deleted.
(WTF::BasicRawSentinelNode<T>::append): Deleted.
* wtf/StdLibExtras.h:
(WTF::roundUpToMultipleOfImpl):
(WTF::roundUpToMultipleOfImpl0): Deleted.
* wtf/UnalignedAccess.h:
(WTF::unalignedLoad):
(WTF::unalignedStore):
Tools:
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/MathExtras.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WTF/Packed.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/211952@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-05-12 22:50:21 +00:00
|
|
|
using WTF::PackedRawSentinelNode;
|
2011-02-15 23:54:06 +00:00
|
|
|
using WTF::SentinelLinkedList;
|