eea7c56468c31e3e0c0bbbac5f5c2e0c3972aac2
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2020-03-09  Mike Gorse  <mgorse@suse.com>
2
3         Build failure on ppc64le if __unix is undefined
4         https://bugs.webkit.org/show_bug.cgi?id=207906
5
6         Reviewed by Yusuke Suzuki.
7
8         * bmalloc/BPlatform.h: Check for __unix__ along with __unix.
9
10 2020-03-02  Alan Coon  <alancoon@apple.com>
11
12         Add new Mac target numbers
13         https://bugs.webkit.org/show_bug.cgi?id=208398
14
15         Reviewed by Alexey Proskuryakov.
16
17         * Configurations/Base.xcconfig:
18         * Configurations/DebugRelease.xcconfig:
19
20 2020-02-29  Yusuke Suzuki  <ysuzuki@apple.com>
21
22         Remove std::lock_guard
23         https://bugs.webkit.org/show_bug.cgi?id=206451
24
25         Reviewed by Anders Carlsson.
26
27         * bmalloc/Mutex.h:
28
29 2020-02-28  Saam Barati  <sbarati@apple.com>
30
31         Clean up code with how we choose Gigacage sizes and whether or not to use Wasm fast memory
32         https://bugs.webkit.org/show_bug.cgi?id=208392
33
34         Reviewed by Yusuke Suzuki.
35
36         * bmalloc/Gigacage.h:
37
38 2020-02-26  Basuke Suzuki  <basuke.suzuki@sony.com>
39
40         [bmalloc][PlayStation] Set Scavenger's thread name.
41         https://bugs.webkit.org/show_bug.cgi?id=208268
42
43         Reviewed by Alex Christensen.
44
45         We also need to have our thread with proper name.
46
47         * bmalloc/Scavenger.cpp:
48         (bmalloc::Scavenger::setThreadName):
49
50 2020-02-25  Saam Barati  <sbarati@apple.com>
51
52         Update stale comment about PackedAlignedPtr
53         https://bugs.webkit.org/show_bug.cgi?id=208176
54
55         Reviewed by Yusuke Suzuki.
56
57         The comment was stale since cells aren't guaranteed anymore to be
58         aligned on 16 byte boundaries because of the GCs precise allocations.
59
60         * bmalloc/Packed.h:
61
62 2020-02-09  Keith Rollin  <krollin@apple.com>
63
64         Re-enable LTO for ARM builds
65         https://bugs.webkit.org/show_bug.cgi?id=207402
66         <rdar://problem/49190767>
67
68         Reviewed by Sam Weinig.
69
70         Bug 190758 re-enabled LTO for Production builds for x86-family CPUs.
71         Enabling it for ARM was left out due to a compiler issue. That issue
72         has been fixed, and so now we can re-enable LTO for ARM.
73
74         * Configurations/Base.xcconfig:
75
76 2020-02-08  Basuke Suzuki  <basuke.suzuki@sony.com>
77
78         [bmalloc] VMHeap can be merge into Heap
79         https://bugs.webkit.org/show_bug.cgi?id=207410
80
81         Reviewed by Yusuke Suzuki.
82
83         VMHeap has only one member function in it and Heap is the only client of that.
84         No member variable is defined. It does nothing special with its context as a class.
85         It is safe to merge the function into Heap.
86
87         * CMakeLists.txt:
88         * bmalloc.xcodeproj/project.pbxproj:
89         * bmalloc/Heap.cpp:
90         (bmalloc::Heap::allocateLarge):
91         (bmalloc::Heap::tryAllocateLargeChunk): Moved from VMHeap.
92         * bmalloc/Heap.h:
93         * bmalloc/VMHeap.cpp: Removed.
94         * bmalloc/VMHeap.h: Removed.
95
96 2020-02-05  Don Olmstead  <don.olmstead@sony.com>
97
98         [bmalloc] Add declspec support for export macros
99         https://bugs.webkit.org/show_bug.cgi?id=207158
100
101         Reviewed by Yusuke Suzuki.
102
103         Add a check for __has_declspec_attribute which is a Clang extension for Microsoft
104         style __declspec attributes in BCompiler.h. Then use that check within BPlatform.h
105         to determine if __declspec or visibility("default") should be used for the export
106         macros.
107
108         The BExport.h file was then expanded to properly implement __declspec definitions
109         for export and import. Libraries that could be compiled statically in WebKit have
110         a STATICALLY_LINKED_WITH_${library} definition for when they're compiled statically
111         and later exposed through a different shared library. In practice though this is
112         really only needed when __declspec is used since this is the only case where the
113         import and export declarations differ.
114
115         The BEXPORT on StaticPerProcess resulted in undefined symbol errors when WebCore
116         was linked. Specifically IsoSharedHeap::getFastCase and IsoSharedHeap::getSlowCase
117         which is a subclass. It appears that Storage was the only one required to be
118         exported. This only appeared due to how __declspec requires exports and imports
119         to be defined differently.
120
121         Also added support for export macros on PlayStation in the BPlatform.h file and
122         fixed any exports for that platform when building.
123
124         * CMakeLists.txt:
125         * bmalloc/Allocator.h:
126         * bmalloc/AvailableMemory.h:
127         * bmalloc/BCompiler.h:
128         * bmalloc/BExport.h:
129         * bmalloc/BPlatform.h:
130         * bmalloc/Cache.h:
131         * bmalloc/IsoTLS.h:
132         * bmalloc/StaticPerProcess.h:
133
134 2020-01-21  Basuke Suzuki  <basuke.suzuki@sony.com>
135
136         [bmalloc] Make use of LockHolder strict in some methods of Scavenger
137         https://bugs.webkit.org/show_bug.cgi?id=206460
138
139         Reviewed by Darin Adler.
140
141         For instance, Scavenger::runHoldingLock() assume the caller has lock and express that by its function name. This rule can be
142         strict by passing LockHolder and that's the way as other code do.
143
144         Same change to runSoonHoldingLock and scheduleIfUnderMemoryPressureHoldingLock.
145
146         * bmalloc/Scavenger.cpp:
147         (bmalloc::Scavenger::run):
148         (bmalloc::Scavenger::runSoon):
149         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
150         (bmalloc::Scavenger::schedule):
151         (bmalloc::Scavenger::runHoldingLock): Renamed.
152         (bmalloc::Scavenger::runSoonHoldingLock): Renamed.
153         (bmalloc::Scavenger::scheduleIfUnderMemoryPressureHoldingLock): Renamed.
154         * bmalloc/Scavenger.h:
155
156 2020-01-17  Sam Weinig  <weinig@apple.com>
157
158         Platform.h is out of control Part 8: Macros are used inconsistently
159         https://bugs.webkit.org/show_bug.cgi?id=206425
160
161         Reviewed by Darin Adler.
162
163         * bmalloc/BPlatform.h:
164         Update OS_EFFECTIVE_ADDRESS_WIDTH to match WTF definition, add needed OS macros.
165
166 2020-01-20  David Kilzer  <ddkilzer@apple.com>
167
168         Fix missing header guards and clean up empty files in bmalloc, WTF, JavaScriptCore
169         <https://webkit.org/b/206481>
170
171         Reviewed by Darin Adler.
172
173         * bmalloc/PerThread.cpp: Remove empty file.
174         * bmalloc/ScopeExit.h: Add #pragma once.
175
176 2020-01-17  Basuke Suzuki  <basuke.suzuki@sony.com>
177
178         [bmalloc] Define alias for std::lock_guard and std::unique_lock for better readability
179         https://bugs.webkit.org/show_bug.cgi?id=206443
180
181         Reviewed by Yusuke Suzuki.
182
183         There are two types of lock holder in bmalloc: std::lock_guard and std::unique_lock. Their names are relatively long
184         and a bit harder to distinguish them each other. Define simple type name for them, LockHolder and UniqueLockHolder.
185
186         * bmalloc/AllIsoHeaps.cpp:
187         (bmalloc::AllIsoHeaps::AllIsoHeaps):
188         (bmalloc::AllIsoHeaps::add):
189         (bmalloc::AllIsoHeaps::head):
190         * bmalloc/AllIsoHeaps.h:
191         * bmalloc/Allocator.cpp:
192         (bmalloc::Allocator::reallocateImpl):
193         (bmalloc::Allocator::refillAllocatorSlowCase):
194         (bmalloc::Allocator::allocateLarge):
195         * bmalloc/CryptoRandom.cpp:
196         (bmalloc::ARC4RandomNumberGenerator::ARC4RandomNumberGenerator):
197         (bmalloc::ARC4RandomNumberGenerator::randomValues):
198         * bmalloc/Deallocator.cpp:
199         (bmalloc::Deallocator::scavenge):
200         (bmalloc::Deallocator::processObjectLog):
201         (bmalloc::Deallocator::deallocateSlowCase):
202         * bmalloc/Deallocator.h:
203         (bmalloc::Deallocator::lineCache):
204         * bmalloc/DebugHeap.cpp:
205         (bmalloc::DebugHeap::DebugHeap):
206         (bmalloc::DebugHeap::memalignLarge):
207         (bmalloc::DebugHeap::freeLarge):
208         * bmalloc/DebugHeap.h:
209         * bmalloc/DeferredTrigger.h:
210         * bmalloc/DeferredTriggerInlines.h:
211         (bmalloc::DeferredTrigger<trigger>::didBecome):
212         (bmalloc::DeferredTrigger<trigger>::handleDeferral):
213         * bmalloc/Environment.cpp:
214         (bmalloc::Environment::Environment):
215         * bmalloc/Environment.h:
216         * bmalloc/Gigacage.cpp:
217         (bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
218         (Gigacage::disablePrimitiveGigacage):
219         (Gigacage::addPrimitiveDisableCallback):
220         (Gigacage::removePrimitiveDisableCallback):
221         * bmalloc/Heap.cpp:
222         (bmalloc::Heap::Heap):
223         (bmalloc::Heap::freeableMemory):
224         (bmalloc::Heap::markAllLargeAsEligibile):
225         (bmalloc::Heap::decommitLargeRange):
226         (bmalloc::Heap::scavenge):
227         (bmalloc::Heap::scavengeToHighWatermark):
228         (bmalloc::Heap::deallocateLineCache):
229         (bmalloc::Heap::allocateSmallChunk):
230         (bmalloc::Heap::allocateSmallPage):
231         (bmalloc::Heap::deallocateSmallLine):
232         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
233         (bmalloc::Heap::allocateSmallBumpRangesByObject):
234         (bmalloc::Heap::splitAndAllocate):
235         (bmalloc::Heap::allocateLarge):
236         (bmalloc::Heap::isLarge):
237         (bmalloc::Heap::largeSize):
238         (bmalloc::Heap::shrinkLarge):
239         (bmalloc::Heap::deallocateLarge):
240         (bmalloc::Heap::externalCommit):
241         (bmalloc::Heap::externalDecommit):
242         * bmalloc/Heap.h:
243         (bmalloc::Heap::allocateSmallBumpRanges):
244         (bmalloc::Heap::derefSmallLine):
245         * bmalloc/HeapConstants.cpp:
246         (bmalloc::HeapConstants::HeapConstants):
247         * bmalloc/HeapConstants.h:
248         * bmalloc/IsoAllocatorInlines.h:
249         (bmalloc::IsoAllocator<Config>::allocateSlow):
250         (bmalloc::IsoAllocator<Config>::scavenge):
251         * bmalloc/IsoDeallocatorInlines.h:
252         (bmalloc::IsoDeallocator<Config>::deallocate):
253         (bmalloc::IsoDeallocator<Config>::scavenge):
254         * bmalloc/IsoDirectory.h:
255         * bmalloc/IsoDirectoryInlines.h:
256         (bmalloc::passedNumPages>::takeFirstEligible):
257         (bmalloc::passedNumPages>::didBecome):
258         (bmalloc::passedNumPages>::didDecommit):
259         (bmalloc::passedNumPages>::scavengePage):
260         (bmalloc::passedNumPages>::scavenge):
261         (bmalloc::passedNumPages>::scavengeToHighWatermark):
262         (bmalloc::passedNumPages>::forEachCommittedPage):
263         * bmalloc/IsoHeapImpl.h:
264         * bmalloc/IsoHeapImplInlines.h:
265         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
266         (bmalloc::IsoHeapImpl<Config>::didBecomeEligibleOrDecommited):
267         (bmalloc::IsoHeapImpl<Config>::scavenge):
268         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
269         (bmalloc::IsoHeapImpl<Config>::numLiveObjects):
270         (bmalloc::IsoHeapImpl<Config>::numCommittedPages):
271         (bmalloc::IsoHeapImpl<Config>::forEachDirectory):
272         (bmalloc::IsoHeapImpl<Config>::forEachCommittedPage):
273         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
274         (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
275         * bmalloc/IsoPage.h:
276         * bmalloc/IsoPageInlines.h:
277         (bmalloc::IsoPage<Config>::free):
278         (bmalloc::IsoPage<Config>::startAllocating):
279         (bmalloc::IsoPage<Config>::stopAllocating):
280         (bmalloc::IsoPage<Config>::forEachLiveObject):
281         * bmalloc/IsoSharedHeap.h:
282         (bmalloc::IsoSharedHeap::IsoSharedHeap):
283         * bmalloc/IsoSharedHeapInlines.h:
284         (bmalloc::IsoSharedHeap::allocateNew):
285         (bmalloc::IsoSharedHeap::allocateSlow):
286         * bmalloc/IsoSharedPage.h:
287         * bmalloc/IsoSharedPageInlines.h:
288         (bmalloc::IsoSharedPage::free):
289         (bmalloc::IsoSharedPage::startAllocating):
290         (bmalloc::IsoSharedPage::stopAllocating):
291         * bmalloc/IsoTLSDeallocatorEntry.h:
292         * bmalloc/IsoTLSDeallocatorEntryInlines.h:
293         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
294         * bmalloc/IsoTLSInlines.h:
295         (bmalloc::IsoTLS::ensureHeap):
296         * bmalloc/IsoTLSLayout.cpp:
297         (bmalloc::IsoTLSLayout::IsoTLSLayout):
298         (bmalloc::IsoTLSLayout::add):
299         * bmalloc/IsoTLSLayout.h:
300         * bmalloc/Mutex.h:
301         (bmalloc::sleep):
302         (bmalloc::waitUntilFalse):
303         * bmalloc/ObjectType.cpp:
304         (bmalloc::objectType):
305         * bmalloc/PerProcess.cpp:
306         (bmalloc::getPerProcessData):
307         * bmalloc/PerProcess.h:
308         (bmalloc::PerProcess::getSlowCase):
309         * bmalloc/Scavenger.cpp:
310         (bmalloc::Scavenger::Scavenger):
311         (bmalloc::Scavenger::run):
312         (bmalloc::Scavenger::runSoon):
313         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
314         (bmalloc::Scavenger::schedule):
315         (bmalloc::Scavenger::timeSinceLastFullScavenge):
316         (bmalloc::Scavenger::timeSinceLastPartialScavenge):
317         (bmalloc::Scavenger::scavenge):
318         (bmalloc::Scavenger::partialScavenge):
319         (bmalloc::Scavenger::freeableMemory):
320         (bmalloc::Scavenger::threadRunLoop):
321         * bmalloc/Scavenger.h:
322         * bmalloc/SmallLine.h:
323         (bmalloc::SmallLine::refCount):
324         (bmalloc::SmallLine::ref):
325         (bmalloc::SmallLine::deref):
326         * bmalloc/SmallPage.h:
327         (bmalloc::SmallPage::refCount):
328         (bmalloc::SmallPage::hasFreeLines const):
329         (bmalloc::SmallPage::setHasFreeLines):
330         (bmalloc::SmallPage::ref):
331         (bmalloc::SmallPage::deref):
332         * bmalloc/StaticPerProcess.h:
333         * bmalloc/VMHeap.cpp:
334         (bmalloc::VMHeap::VMHeap):
335         * bmalloc/VMHeap.h:
336         * bmalloc/Zone.cpp:
337         (bmalloc::Zone::Zone):
338         * bmalloc/Zone.h:
339         * bmalloc/bmalloc.cpp:
340         (bmalloc::api::tryLargeZeroedMemalignVirtual):
341         (bmalloc::api::freeLargeVirtual):
342         (bmalloc::api::setScavengerThreadQOSClass):
343
344 2020-01-17  Yusuke Suzuki  <ysuzuki@apple.com>
345
346         [bmalloc] Fix IsoHeapImpl's assertion introduced in r254708
347         https://bugs.webkit.org/show_bug.cgi?id=206440
348         <rdar://problem/58688794>
349
350         Reviewed by Mark Lam.
351
352         The assertion introduced in r254708 was wrong.
353         Fixing it to check the invariant we actually want to ensure.
354         This fixes TestWTF crash in Debug build.
355
356         * bmalloc/IsoHeapImplInlines.h:
357         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
358
359 2020-01-16  Yusuke Suzuki  <ysuzuki@apple.com>
360
361         [bmalloc] IsoHeap's initial setup should be small
362         https://bugs.webkit.org/show_bug.cgi?id=206214
363
364         Reviewed by Michael Saboff.
365
366         Keep IsoHeap related data structures small by using Packed technique. We start using IsoHeap for many classes,
367         then it is important that we keep metadata for IsoHeap small because these data persistently exists.
368
369         1. We pass IsoHeapImpl<> as a parameter instead of holding it unnecessarily.
370         2. We make some of pointers Packed so that we can keep sizeof(IsoHeapImpl<Config>) small.
371         3. One of the drawback of PackedPtr is that loading and storing are not atomic. And we pass `const std::lock_guard<Mutex>&`
372            to functions if functions need to be called with lock so that we ensure that PackedPtr are accessed only when lock is
373            held correctly.
374
375         * CMakeLists.txt:
376         * bmalloc.xcodeproj/project.pbxproj:
377         * bmalloc/Algorithm.h:
378         (bmalloc::ctzConstexpr):
379         (bmalloc::getLSBSetNonZeroConstexpr):
380         * bmalloc/BPlatform.h:
381         * bmalloc/DebugHeap.cpp:
382         (bmalloc::DebugHeap::DebugHeap):
383         * bmalloc/DebugHeap.h:
384         * bmalloc/DeferredTrigger.h:
385         * bmalloc/DeferredTriggerInlines.h:
386         (bmalloc::DeferredTrigger<trigger>::didBecome):
387         (bmalloc::DeferredTrigger<trigger>::handleDeferral):
388         * bmalloc/Environment.cpp:
389         (bmalloc::Environment::Environment):
390         * bmalloc/Environment.h:
391         * bmalloc/Gigacage.cpp:
392         (bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
393         * bmalloc/Heap.cpp:
394         (bmalloc::Heap::freeableMemory):
395         (bmalloc::Heap::markAllLargeAsEligibile):
396         (bmalloc::Heap::decommitLargeRange):
397         (bmalloc::Heap::scavenge):
398         (bmalloc::Heap::scavengeToHighWatermark):
399         * bmalloc/Heap.h:
400         * bmalloc/HeapConstants.cpp:
401         (bmalloc::HeapConstants::HeapConstants):
402         * bmalloc/HeapConstants.h:
403         * bmalloc/IsoAllocator.h:
404         * bmalloc/IsoAllocatorInlines.h:
405         (bmalloc::IsoAllocator<Config>::IsoAllocator):
406         (bmalloc::IsoAllocator<Config>::allocate):
407         (bmalloc::IsoAllocator<Config>::allocateSlow):
408         (bmalloc::IsoAllocator<Config>::scavenge):
409         * bmalloc/IsoDeallocatorInlines.h:
410         (bmalloc::IsoDeallocator<Config>::scavenge):
411         * bmalloc/IsoDirectory.h:
412         * bmalloc/IsoDirectoryInlines.h:
413         (bmalloc::passedNumPages>::IsoDirectory):
414         (bmalloc::passedNumPages>::takeFirstEligible):
415         (bmalloc::passedNumPages>::didBecome):
416         (bmalloc::passedNumPages>::didDecommit):
417         (bmalloc::passedNumPages>::scavengePage):
418         (bmalloc::passedNumPages>::scavenge):
419         (bmalloc::passedNumPages>::scavengeToHighWatermark):
420         (bmalloc::passedNumPages>::forEachCommittedPage):
421         * bmalloc/IsoHeapImpl.cpp:
422         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
423         * bmalloc/IsoHeapImpl.h:
424         * bmalloc/IsoHeapImplInlines.h:
425         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
426         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
427         (bmalloc::IsoHeapImpl<Config>::didBecomeEligibleOrDecommited):
428         (bmalloc::IsoHeapImpl<Config>::scavenge):
429         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
430         (bmalloc::IsoHeapImplBase::freeableMemory):
431         (bmalloc::IsoHeapImpl<Config>::numLiveObjects):
432         (bmalloc::IsoHeapImpl<Config>::numCommittedPages):
433         (bmalloc::IsoHeapImpl<Config>::forEachDirectory):
434         (bmalloc::IsoHeapImpl<Config>::forEachCommittedPage):
435         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
436         (bmalloc::IsoHeapImplBase::footprint):
437         (bmalloc::IsoHeapImplBase::didCommit):
438         (bmalloc::IsoHeapImplBase::didDecommit):
439         (bmalloc::IsoHeapImplBase::isNowFreeable):
440         (bmalloc::IsoHeapImplBase::isNoLongerFreeable):
441         (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
442         (bmalloc::IsoHeapImpl<Config>::freeableMemory): Deleted.
443         (bmalloc::IsoHeapImpl<Config>::footprint): Deleted.
444         (bmalloc::IsoHeapImpl<Config>::didCommit): Deleted.
445         (bmalloc::IsoHeapImpl<Config>::didDecommit): Deleted.
446         (bmalloc::IsoHeapImpl<Config>::isNowFreeable): Deleted.
447         (bmalloc::IsoHeapImpl<Config>::isNoLongerFreeable): Deleted.
448         * bmalloc/IsoPage.h:
449         (bmalloc::IsoPageBase::IsoPageBase):
450         * bmalloc/IsoPageInlines.h:
451         (bmalloc::IsoPage<Config>::IsoPage):
452         (bmalloc::IsoPage<Config>::free):
453         (bmalloc::IsoPage<Config>::startAllocating):
454         (bmalloc::IsoPage<Config>::stopAllocating):
455         (bmalloc::IsoPage<Config>::forEachLiveObject):
456         * bmalloc/IsoSharedHeap.h:
457         (bmalloc::IsoSharedHeap::IsoSharedHeap):
458         * bmalloc/IsoSharedHeapInlines.h:
459         (bmalloc::IsoSharedHeap::allocateNew):
460         (bmalloc::IsoSharedHeap::allocateSlow):
461         * bmalloc/IsoSharedPage.h:
462         * bmalloc/IsoSharedPageInlines.h:
463         (bmalloc::IsoSharedPage::free):
464         (bmalloc::IsoSharedPage::startAllocating):
465         (bmalloc::IsoSharedPage::stopAllocating):
466         * bmalloc/IsoTLS.h:
467         * bmalloc/IsoTLSAllocatorEntry.h:
468         * bmalloc/IsoTLSAllocatorEntryInlines.h:
469         (bmalloc::IsoTLSAllocatorEntry<Config>::scavenge):
470         * bmalloc/IsoTLSDeallocatorEntry.h:
471         * bmalloc/IsoTLSDeallocatorEntryInlines.h:
472         (bmalloc::IsoTLSDeallocatorEntry<Config>::scavenge):
473         * bmalloc/IsoTLSEntry.cpp:
474         (bmalloc::IsoTLSEntry::IsoTLSEntry):
475         * bmalloc/IsoTLSEntry.h:
476         * bmalloc/IsoTLSEntryInlines.h:
477         (bmalloc::DefaultIsoTLSEntry<EntryType>::DefaultIsoTLSEntry):
478         (bmalloc::DefaultIsoTLSEntry<EntryType>::~DefaultIsoTLSEntry): Deleted.
479         (bmalloc::DefaultIsoTLSEntry<EntryType>::scavenge): Deleted.
480         * bmalloc/IsoTLSInlines.h:
481         (bmalloc::IsoTLS::scavenge):
482         (bmalloc::IsoTLS::allocateImpl):
483         (bmalloc::IsoTLS::allocateFast):
484         (bmalloc::IsoTLS::allocateSlow):
485         * bmalloc/IsoTLSLayout.cpp:
486         (bmalloc::IsoTLSLayout::add):
487         * bmalloc/Packed.h: Added.
488         (bmalloc::Packed::Packed):
489         (bmalloc::Packed::get const):
490         (bmalloc::Packed::set):
491         (bmalloc::Packed::operator=):
492         (bmalloc::Packed::exchange):
493         (bmalloc::Packed::swap):
494         (bmalloc::alignof):
495         (bmalloc::PackedPtrTraits::exchange):
496         (bmalloc::PackedPtrTraits::swap):
497         (bmalloc::PackedPtrTraits::unwrap):
498         * bmalloc/Scavenger.cpp:
499         (bmalloc::Scavenger::Scavenger):
500         * bmalloc/Scavenger.h:
501         * bmalloc/VMHeap.cpp:
502         (bmalloc::VMHeap::VMHeap):
503         * bmalloc/VMHeap.h:
504         * bmalloc/Zone.cpp:
505         (bmalloc::Zone::Zone):
506         * bmalloc/Zone.h:
507
508 2020-01-14  Basuke Suzuki  <basuke.suzuki@sony.com>
509
510         [bmalloc] Calculate LineMetadata for specific VM page size in compile time
511         https://bugs.webkit.org/show_bug.cgi?id=206044
512
513         Reviewed by Yusuke Suzuki.
514
515         LineMetadata is dependent only on VM page size. This patch enables the pre-calculation for
516         specific VM page sizes by compiler flags. The benefit is both runtime initialization speed
517         up and avoiding extra VM allocation on runtime.
518
519         First targets are 4k (Mac) and 16k (some iOS, PlayStation) VM page sizes.
520
521         * bmalloc/Algorithm.h:
522         (bmalloc::divideRoundingUp):
523         * bmalloc/BPlatform.h:
524         * bmalloc/HeapConstants.cpp:
525         (bmalloc::fillLineMetadata):
526         (bmalloc::computeLineMetadata):
527         (bmalloc::HeapConstants::initializeLineMetadata):
528         * bmalloc/HeapConstants.h:
529         (bmalloc::HeapConstants::smallLineCount const):
530         (bmalloc::HeapConstants::startOffset const):
531         (bmalloc::HeapConstants::objectCount const):
532         (bmalloc::HeapConstants::lineMetadata const):
533         (bmalloc::HeapConstants::startOffset): Deleted.
534         (bmalloc::HeapConstants::objectCount): Deleted.
535         (bmalloc::HeapConstants::lineMetadata): Deleted.
536         * bmalloc/LineMetadata.h:
537         * bmalloc/Sizes.h:
538         (bmalloc::Sizes::maskObjectSize):
539         (bmalloc::Sizes::logSizeClass):
540         (bmalloc::Sizes::logObjectSize):
541         (bmalloc::Sizes::sizeClass):
542         (bmalloc::Sizes::objectSize):
543         (bmalloc::Sizes::pageSize):
544         (bmalloc::Sizes::smallLineCount):
545
546 2020-01-14  David Kilzer  <ddkilzer@apple.com>
547
548         Enable -Wconditional-uninitialized in bmalloc, WTF, JavaScriptCore
549         <https://webkit.org/b/206190>
550         <rdar://problem/58540387>
551
552         Reviewed by Mark Lam.
553
554         * Configurations/Base.xcconfig:
555         (WARNING_CFLAGS): Add -Wconditional-uninitialized.
556
557 2020-01-09  Basuke Suzuki  <basuke.suzuki@sony.com>
558
559         [bmalloc] Extract constants from Heap and share it among Heaps.
560         https://bugs.webkit.org/show_bug.cgi?id=205834
561
562         Reviewed by Geoffrey Garen.
563
564         A Heap has many constants (m_vmPageSizePhysical, m_smallLineMetadata and m_pageClasses) and they
565         are dependent only to vmPageSizePhysical and identical for all Heaps.
566
567         Extracting them into a class and make it sharable among heaps. Also this is the first step for
568         making Heap constants to actual `constexpr`.
569
570         * CMakeLists.txt: Added HeapConstants.cpp.
571         * bmalloc.xcodeproj/project.pbxproj: Ditto.
572         * bmalloc/Heap.cpp: Referencing HeapConstants object to get information.
573         (bmalloc::Heap::Heap):
574         (bmalloc::Heap::allocateSmallPage):
575         (bmalloc::Heap::deallocateSmallLine):
576         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
577         (bmalloc::Heap::allocateSmallBumpRangesByObject):
578         (bmalloc::Heap::initializeLineMetadata): Moved to HeapConstants.cpp.
579         (bmalloc::Heap::initializePageMetadata): Moved to HeapConstants.cpp.
580         * bmalloc/Heap.h: Extract metadata initialization and member variables.
581         * bmalloc/HeapConstants.cpp: Added.
582         (bmalloc::HeapConstants::HeapConstants):
583         (bmalloc::HeapConstants::initializeLineMetadata):
584         (bmalloc::HeapConstants::initializePageMetadata):
585         * bmalloc/HeapConstants.h:
586         (bmalloc::HeapConstants::pageClass const):
587         (bmalloc::HeapConstants::smallLineCount const):
588         (bmalloc::HeapConstants::startOffset):
589         (bmalloc::HeapConstants::objectCount):
590         (bmalloc::HeapConstants::lineMetadata):
591
592 2020-01-02  Yusuke Suzuki  <ysuzuki@apple.com> and Simon Fraser  <simon.fraser@apple.com>
593
594         Experiment: create lots of different malloc zones for easier accounting of memory use
595         https://bugs.webkit.org/show_bug.cgi?id=186422
596
597         Reviewed by Saam Barati.
598
599         * bmalloc/BPlatform.h:
600         * bmalloc/Environment.cpp:
601         (bmalloc::Environment::computeIsDebugHeapEnabled):
602         * bmalloc/IsoHeap.h:
603         (bmalloc::api::IsoHeap::IsoHeap):
604         * bmalloc/IsoHeapInlines.h:
605         (bmalloc::api::IsoHeap<Type>::IsoHeap):
606         * bmalloc/IsoTLSInlines.h:
607         (bmalloc::IsoTLS::allocateSlow):
608         (bmalloc::IsoTLS::deallocateSlow):
609
610 2019-12-07  Basuke Suzuki  <basuke.suzuki@sony.com>
611
612         [bmalloc] Decommit unused region in chunk metadata.
613         https://bugs.webkit.org/show_bug.cgi?id=204810
614
615         Reviewed by Yusuke Suzuki.
616
617         There is an unused memory region from just after Chunk object to next page border.
618         We can decommit those memory to kernel at the initialization of Chunk.
619
620         * bmalloc/Heap.cpp:
621         (bmalloc::Heap::allocateSmallChunk):
622
623 2019-11-25  Fujii Hironori  <Hironori.Fujii@sony.com>
624
625         Ran sort-Xcode-project-file.
626
627         Unreviewed.
628
629         * bmalloc.xcodeproj/project.pbxproj:
630
631 2019-11-18  Basuke Suzuki  <basuke.suzuki@sony.com>
632
633         [bmalloc] Some chunks have unused region in the tail of its memory block.
634         https://bugs.webkit.org/show_bug.cgi?id=204286
635
636         Reviewed by Yusuke Suzuki.
637
638         When chunk is initialized, some amount of memory are not used and be kept untouched until its end.
639         This patch tries to decommit those region at the end of initialization.
640
641         For instance, think about the case that the pageClass is 5. Then pageSize is 24k. With this pageSize,
642         a chunk can hold 42 pages and its size is 24k * 42 = 1008k which is smaller than chunkSize = 1024k.
643         Here is the complete result:
644
645                 page    page    page
646                 class   size    count   remainings
647                 ----------------------------------
648                 0       4kB     256     0
649                 1       8kB     128     0
650                 2       12kB    85      4kB
651                 3       16kB    64      0
652                 4       20kB    51      4kB
653                 5       24kB    42      16kB
654                 6       28kB    36      16kB
655                 7       32kB    32      0
656                 8       36kB    28      16kB
657                 9       40kB    25      24kB
658                 10      44kB    23      12kB
659                 11      48kB    21      16kB
660                 12      52kB    19      36kB
661                 13      56kB    18      16kB
662                 14      60kB    17      4kB
663                 15      64kB    16      0
664
665         Tested on Mac testmem and result is almost same or in error margin.
666
667                 Before:                                 After:
668                 end score:           8.5425 MB          end score:           8.5127 MB
669                 peak score:          8.7997 MB          peak score:          8.7884 MB
670                 total memory score:  8.6702 MB          total memory score:  8.6495 MB
671                 time score:          668.19 ms          time score:          666.27 ms
672
673         * bmalloc/Chunk.h:
674         (bmalloc::Chunk::metadataSize):
675         (bmalloc::forEachPage):
676         * bmalloc/Heap.cpp:
677         (bmalloc::Heap::allocateSmallChunk):
678
679 2019-11-15  Basuke Suzuki  <basuke.suzuki@sony.com>
680
681         [bmalloc] The tracking of freeableMemory of Heap doesn't count Chunk's metadata size.
682         https://bugs.webkit.org/show_bug.cgi?id=204135
683
684         Reviewed by Yusuke Suzuki.
685
686         When chunk is allocated in allocateSmallChunk(), all chunk size is added to freeableMemory.
687         This is wrong. Only free pages should be added to it.
688
689         * bmalloc/Heap.cpp:
690         (bmalloc::Heap::allocateSmallChunk):
691
692 2019-11-15  Basuke Suzuki  <basuke.suzuki@sony.com>
693
694         [Mac] Use better describing name for Mac's scavenger compiler flag.
695         https://bugs.webkit.org/show_bug.cgi?id=203922
696
697         Reviewed by Yusuke Suzuki.
698
699         Changing BPLATFORM(MAC) to BUSE(PARTIAL_SCAVENGE).
700
701         * bmalloc/BPlatform.h:
702         * bmalloc/Heap.cpp:
703         (bmalloc::Heap::scavenge):
704         (bmalloc::Heap::allocateSmallChunk):
705         (bmalloc::Heap::allocateSmallPage):
706         (bmalloc::Heap::allocateLarge):
707         * bmalloc/Heap.h:
708         * bmalloc/IsoDirectory.h:
709         * bmalloc/IsoDirectoryInlines.h:
710         (bmalloc::passedNumPages>::takeFirstEligible):
711         (bmalloc::passedNumPages>::scavenge):
712         * bmalloc/IsoHeapImpl.h:
713         * bmalloc/IsoHeapImplInlines.h:
714         * bmalloc/LargeMap.cpp:
715         (bmalloc::LargeMap::add):
716         * bmalloc/LargeRange.h:
717         (bmalloc::LargeRange::LargeRange):
718         (bmalloc::merge):
719         * bmalloc/Scavenger.cpp:
720         (bmalloc::Scavenger::Scavenger):
721         (bmalloc::Scavenger::scavenge):
722         (bmalloc::Scavenger::threadRunLoop):
723         * bmalloc/Scavenger.h:
724         * bmalloc/SmallPage.h:
725
726 2019-11-07  Basuke Suzuki  <Basuke.Suzuki@sony.com> and Yusuke Suzuki  <ysuzuki@apple.com>
727
728         [bmalloc] Bug fix for wait time when it's in mini mode.
729         https://bugs.webkit.org/show_bug.cgi?id=203121
730
731         Reviewed by Saam Barati.
732
733         Basuke pointed out that we never changed m_waitTime in scavenger when we are in iOS and mini-mode.
734         So previously, we are always executing scavenger for each 10ms in mini-mode. After fixing it, we
735         found that this unintentional behavior was better policy for RAMification.
736         In this patch, we explicitly use the old behavior, "scavenge for each 10ms" in iOS mini-mode.
737         We should revisit scavenger's behavior in the future to explore further better behavior.
738
739         * bmalloc/Scavenger.cpp:
740         (bmalloc::Scavenger::threadRunLoop):
741
742 2019-11-06  Yusuke Suzuki  <ysuzuki@apple.com>
743
744         Unreviewed, roll-out r251268 due to RAMification regression
745         https://bugs.webkit.org/show_bug.cgi?id=203121
746
747         The code was the bug, but it would be possible that this bug accidentally makes our policy better.
748         We should clean up to make this bug's behavior default. And we should look for a bit larger interval here.
749
750         * bmalloc/Scavenger.cpp:
751         (bmalloc::Scavenger::threadRunLoop):
752
753 2019-10-17  Basuke Suzuki  <Basuke.Suzuki@sony.com>
754
755         [bmalloc] Bug fix for wait time when it's in mini mode.
756         https://bugs.webkit.org/show_bug.cgi?id=203121
757
758         Reviewed by Yusuke Suzuki.
759
760         Since r243144, m_waitTime is never changed on mini mode.
761
762         * bmalloc/Scavenger.cpp:
763         (bmalloc::Scavenger::threadRunLoop):
764
765 2019-10-07  Wenson Hsieh  <wenson_hsieh@apple.com>
766
767         Add a missing #include in DeferredTriggerInlines.h
768         https://bugs.webkit.org/show_bug.cgi?id=202677
769
770         Reviewed by Yusuke Suzuki.
771
772         DeferredTriggerInlines.h uses RELEASE_BASSERT, but does not include BAssert.h. This causes
773         subsequent build failures when shuffling around some sources in WebCore that then attempt to
774         include <wtf/IsoMallocInlines.h>.
775
776         * bmalloc/DeferredTriggerInlines.h:
777
778 2019-09-24  Keith Rollin  <krollin@apple.com>
779
780         Address static analysis warning in Allocator.cpp: Null pointer argument in call to memory copy function
781         https://bugs.webkit.org/show_bug.cgi?id=202152
782         <rdar://problem/55671444>
783
784         Reviewed by Geoffrey Garen.
785
786         Xcode's static analysis facility flags the following:
787
788             .../OpenSource/Source/bmalloc/bmalloc/Allocator.cpp:98:5: warning: Null pointer argument in call to memory copy function
789                 memcpy(result, object, copySize);
790                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
791
792         https://en.cppreference.com/w/cpp/string/byte/memcpy explains that
793         this is undefined behavior:
794
795             "If either dest or src is a null pointer, the behavior is
796              undefined, even if count is zero."
797
798         I suppose that passing in a null source pointer could be bad if the
799         implementation fetched the first source byte to copy before actually
800         checking the number of bytes to copy. So far, it doesn’t seem to be an
801         issue, but we should clean this up.
802
803         Simply adding "if (result && object)" before the memcpy will add tests
804         and branches in the hot path of this function and so might not be the
805         best solution. Instead, straighten out the code a little bit by
806         putting an early check and return on "object". This also allows us to
807         remove some intermediate code.
808
809         * bmalloc/Allocator.cpp:
810         (bmalloc::Allocator::reallocateImpl):
811
812 2019-09-17  Mark Lam  <mark.lam@apple.com>
813
814         Use constexpr instead of const in symbol definitions that are obviously constexpr.
815         https://bugs.webkit.org/show_bug.cgi?id=201879
816
817         Rubber-stamped by Joseph Pecoraro.
818
819         * bmalloc/AvailableMemory.cpp:
820         * bmalloc/IsoTLS.h:
821         * bmalloc/Map.h:
822         * bmalloc/Mutex.cpp:
823         (bmalloc::Mutex::lockSlowCase):
824         * bmalloc/PerThread.h:
825         * bmalloc/Vector.h:
826         * bmalloc/Zone.h:
827
828 2019-09-13  Mark Lam  <mark.lam@apple.com>
829
830         We should never fail to allocate VA for the Gigacage.
831         https://bugs.webkit.org/show_bug.cgi?id=201774
832         <rdar://problem/55352042>
833
834         Reviewed by Yusuke Suzuki.
835
836         Unfortunately, this is still not true for OS(LINUX).  So, I'll leave the
837         GIGACAGE_ALLOCATION_CAN_FAIL code in place but disable it for everything else.
838
839         * bmalloc/Gigacage.h:
840
841 2019-09-09  Michael Saboff  <msaboff@apple.com>
842
843         Revert to pre-r243144 scavenging behavior for macOS
844         https://bugs.webkit.org/show_bug.cgi?id=201555
845
846         Reviewed by Saam Barati.
847
848         The change in r243144 regressed internal power metrics for some Mac models.
849
850         * bmalloc/Heap.cpp:
851         (bmalloc::Heap::scavenge):
852         (bmalloc::Heap::scavengeToHighWatermark):
853         (bmalloc::Heap::allocateSmallChunk):
854         (bmalloc::Heap::allocateSmallPage):
855         (bmalloc::Heap::allocateLarge):
856         * bmalloc/Heap.h:
857         * bmalloc/IsoDirectory.h:
858         * bmalloc/IsoDirectoryInlines.h:
859         (bmalloc::passedNumPages>::takeFirstEligible):
860         (bmalloc::passedNumPages>::scavenge):
861         (bmalloc::passedNumPages>::scavengeToHighWatermark):
862         * bmalloc/IsoHeapImpl.h:
863         * bmalloc/IsoHeapImplInlines.h:
864         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
865         * bmalloc/LargeMap.cpp:
866         (bmalloc::LargeMap::add):
867         * bmalloc/LargeRange.h:
868         (bmalloc::LargeRange::LargeRange):
869         (bmalloc::merge):
870         * bmalloc/Scavenger.cpp:
871         (bmalloc::Scavenger::Scavenger):
872         (bmalloc::Scavenger::timeSinceLastPartialScavenge):
873         (bmalloc::Scavenger::scavenge):
874         (bmalloc::Scavenger::partialScavenge):
875         (bmalloc::Scavenger::threadRunLoop):
876         * bmalloc/Scavenger.h:
877         * bmalloc/SmallPage.h:
878
879 2019-09-07  Mark Lam  <mark.lam@apple.com>
880
881         [Follow up fix] Harden protection of the Gigacage Config parameters.
882         https://bugs.webkit.org/show_bug.cgi?id=201570
883         <rdar://problem/55134229>
884
885         Reviewed by Saam Barati.
886
887         The previously landed hardening measures is failing the assertion in
888         forbidDisablingPrimitiveGigacage() when a replacement heap (e.g. gmalloc) is
889         used.
890
891         1. forbidDisablingPrimitiveGigacage() should just ensureGigacage() so that we
892            know that the Gigacage is properly configured (whether enabled or disabled).
893         2. Strengthen the assertion in forbidDisablingPrimitiveGigacage() to ensure that
894            we have already determined if the Gigacage should be enabled.
895
896         * bmalloc/Gigacage.cpp:
897         (Gigacage::forbidDisablingPrimitiveGigacage):
898
899 2019-09-07  Mark Lam  <mark.lam@apple.com>
900
901         performJITMemcpy() source buffer should not be in the Gigacage.
902         https://bugs.webkit.org/show_bug.cgi?id=201577
903         <rdar://problem/55142606>
904
905         Reviewed by Michael Saboff.
906
907         1. Add the Gigacage start address and totalSize to the Config.
908         2. Add a contains() function that uses the start address and totalSize to check
909            if a given pointer is in the Gigacage's address range.
910
911         * bmalloc/Gigacage.cpp:
912         (Gigacage::ensureGigacage):
913         (Gigacage::verifyGigacageIsEnabled):
914         * bmalloc/Gigacage.h:
915         (Gigacage::contains):
916
917 2019-09-06  Mark Lam  <mark.lam@apple.com>
918
919         Harden protection of the Gigacage Config parameters.
920         https://bugs.webkit.org/show_bug.cgi?id=201570
921         <rdar://problem/55134229>
922
923         Reviewed by Saam Barati.
924
925         1. Rename protectGigacageBasePtrs() and unprotectGigacageBasePtrs() to
926            freezeGigacageConfig() and unfreezeGigacageConfig() respectively.
927
928            Also move the alignment check in protectGigacageBasePtrs() into ensureGigacage().
929            There's no need to check it more than once.
930
931         2. Introduce permanentlyFreezeGigacageConfig() which permanently makes the
932            Config ReadOnly.  Once invoked, the Config cannot be made writable again.
933
934            This is made possible by using vm_protect with a true set_maximum argument.
935            We also add a g_gigacageConfig.isPermanentlyFrozen flag that we assert.
936            Note: this permanence is only true for OS(DARWIN) since vm_protect is Mach API.
937
938         3. Rename disableDisablingPrimitiveGigacageIfShouldBeEnabled() to
939            forbidDisablingPrimitiveGigacage() because "disablingDisabling" is a tongue
940            twister.
941
942            Also, we don't want to make it conditional on "IfShouldBeEnabled".  We want
943            forbidDisablingPrimitiveGigacage() to be irreversible.  It is up to the client
944            to ensure that the Gigacage is already initialized (if possible) before
945            invoking forbidDisablingPrimitiveGigacage().  Conceptually, the forbidding
946            isn't about guaranteeing that the Gigacage is enabled.  It only takes away the
947            option to disable it.
948
949            That said, forbidDisablingPrimitiveGigacage() is only invoked by clients that
950            care about keeping the Gigacage enabled.  So, it does a sanity check (with an
951            assertion) that if !GIGACAGE_ALLOCATION_CAN_FAIL, then the Gigacage should be
952            have been initialized and enabled before invoking it.
953
954            We also make sure that forbidDisablingPrimitiveGigacage() calls
955            permanentlyFreezeGigacageConfig() unconditionally.  It is safe to call it more
956            than once.  This guarantees that the Config is permanently frozen after this,
957            even if a bug should inadvertantly set the
958            g_gigacageConfig.disablingPrimitiveGigacageIsForbidden flag before
959            forbidDisablingPrimitiveGigacage() is invoked.
960
961         4. Assert that ensureGigacage() is only called once.
962
963         5. Assert that shouldBeEnabled() is only called once.
964            Also moved its cached result into the Config so that it can be frozen.
965
966         * bmalloc/Gigacage.cpp:
967         (Gigacage::bmalloc::freezeGigacageConfig):
968         (Gigacage::bmalloc::unfreezeGigacageConfig):
969         (Gigacage::bmalloc::permanentlyFreezeGigacageConfig):
970         (Gigacage::bmalloc::UnfreezeGigacageConfigScope::UnfreezeGigacageConfigScope):
971         (Gigacage::bmalloc::UnfreezeGigacageConfigScope::~UnfreezeGigacageConfigScope):
972         (Gigacage::ensureGigacage):
973         (Gigacage::disablePrimitiveGigacage):
974         (Gigacage::verifyGigacageIsEnabled):
975         (Gigacage::forbidDisablingPrimitiveGigacage):
976         (Gigacage::isDisablingPrimitiveGigacageForbidden):
977         (Gigacage::shouldBeEnabled):
978         (Gigacage::bmalloc::protectGigacageBasePtrs): Deleted.
979         (Gigacage::bmalloc::unprotectGigacageBasePtrs): Deleted.
980         (Gigacage::bmalloc::UnprotectGigacageBasePtrsScope::UnprotectGigacageBasePtrsScope): Deleted.
981         (Gigacage::bmalloc::UnprotectGigacageBasePtrsScope::~UnprotectGigacageBasePtrsScope): Deleted.
982         (Gigacage::primitiveGigacageDisabled): Deleted.
983         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled): Deleted.
984         (Gigacage::isDisablingPrimitiveGigacageDisabled): Deleted.
985         * bmalloc/Gigacage.h:
986         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
987         (Gigacage::canPrimitiveGigacageBeDisabled):
988         (Gigacage::forbidDisablingPrimitiveGigacage):
989         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled): Deleted.
990
991 2019-09-06  Mark Lam  <mark.lam@apple.com>
992
993         Use FailureAction everywhere in bmalloc instead of a crashOnFailure boolean.
994         https://bugs.webkit.org/show_bug.cgi?id=201553
995
996         Reviewed by Yusuke Suzuki.
997
998         * bmalloc/Cache.cpp:
999         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
1000         (bmalloc::Cache::allocateSlowCaseNullCache):
1001         (bmalloc::Cache::tryReallocateSlowCaseNullCache):
1002         (bmalloc::Cache::reallocateSlowCaseNullCache):
1003         * bmalloc/DebugHeap.cpp:
1004         (bmalloc::DebugHeap::malloc):
1005         (bmalloc::DebugHeap::memalign):
1006         (bmalloc::DebugHeap::realloc):
1007         * bmalloc/DebugHeap.h:
1008
1009 2019-09-06  Mark Lam  <mark.lam@apple.com>
1010
1011         Fix bmalloc::Allocator:tryAllocate() to return null on failure to allocate.
1012         https://bugs.webkit.org/show_bug.cgi?id=201529
1013         <rdar://problem/53935772>
1014
1015         Reviewed by Yusuke Suzuki.
1016
1017         In this implementation, we pass FailureAction in as a runtime option.  If this
1018         proves to be a perf issue, we can easily fix this by passing it as a template
1019         argument.  That will also automatically elide unneeded code paths.  We'll defer
1020         that exercise until we have evidence that it is warranted.
1021
1022         * CMakeLists.txt:
1023         * bmalloc.xcodeproj/project.pbxproj:
1024         * bmalloc/Allocator.cpp:
1025         (bmalloc::Allocator::allocateImpl):
1026         (bmalloc::Allocator::reallocateImpl):
1027         (bmalloc::Allocator::refillAllocatorSlowCase):
1028         (bmalloc::Allocator::refillAllocator):
1029         (bmalloc::Allocator::allocateLarge):
1030         (bmalloc::Allocator::allocateLogSizeClass):
1031         (bmalloc::Allocator::allocateSlowCase):
1032         (bmalloc::Allocator::tryAllocate): Deleted.
1033         (bmalloc::Allocator::allocate): Deleted.
1034         (bmalloc::Allocator::reallocate): Deleted.
1035         (bmalloc::Allocator::tryReallocate): Deleted.
1036         * bmalloc/Allocator.h:
1037         (bmalloc::Allocator::tryAllocate):
1038         (bmalloc::Allocator::allocate):
1039         (bmalloc::Allocator::tryReallocate):
1040         (bmalloc::Allocator::reallocate):
1041         (bmalloc::Allocator::allocateImpl):
1042         * bmalloc/BumpAllocator.h:
1043         * bmalloc/FailureAction.h: Added.
1044         * bmalloc/Heap.cpp:
1045         (bmalloc::Heap::allocateSmallChunk):
1046         (bmalloc::Heap::allocateSmallPage):
1047         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
1048         (bmalloc::Heap::allocateSmallBumpRangesByObject):
1049         (bmalloc::Heap::allocateLarge):
1050         (bmalloc::Heap::tryAllocateLarge): Deleted.
1051         * bmalloc/Heap.h:
1052         (bmalloc::Heap::allocateSmallBumpRanges):
1053         * bmalloc/bmalloc.cpp:
1054         (bmalloc::api::tryLargeZeroedMemalignVirtual):
1055
1056 2019-09-05  Mark Lam  <mark.lam@apple.com>
1057
1058         Refactor the Gigacage code to require less pointer casting.
1059         https://bugs.webkit.org/show_bug.cgi?id=201521
1060
1061         Reviewed by Saam Barati.
1062
1063         1. Define a Gigacage::Config struct instead of hacking around a g_gigacageBasePtrs
1064            array of bytes.
1065         2. Change Gigacage::basePtr() to return a pointer instead of a reference to the
1066            requested basePtr.  Instead, make it explicit when the client is trying to
1067            take the address of the basePtr, or setting it.
1068         3. Renamed wasEnabled() to isEnabled() because it returns the present state of the
1069            flag, not some past state.
1070
1071         * bmalloc/Gigacage.cpp:
1072         (Gigacage::bmalloc::protectGigacageBasePtrs):
1073         (Gigacage::bmalloc::unprotectGigacageBasePtrs):
1074         (Gigacage::bmalloc::runwaySize):
1075         (Gigacage::ensureGigacage):
1076         (Gigacage::disablePrimitiveGigacage):
1077         (Gigacage::addPrimitiveDisableCallback):
1078         (Gigacage::primitiveGigacageDisabled):
1079         * bmalloc/Gigacage.h:
1080         (Gigacage::name):
1081         (Gigacage::Config::basePtr const):
1082         (Gigacage::Config::setBasePtr):
1083         (Gigacage::isEnabled):
1084         (Gigacage::basePtr):
1085         (Gigacage::addressOfBasePtr):
1086         (Gigacage::size):
1087         (Gigacage::caged):
1088         (Gigacage::wasEnabled): Deleted.
1089         (Gigacage::setWasEnabled): Deleted.
1090         (Gigacage::basePtrs): Deleted.
1091         * bmalloc/HeapKind.h:
1092         (bmalloc::heapKind):
1093         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1094         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1095
1096 2019-09-03  Yusuke Suzuki  <ysuzuki@apple.com>
1097
1098         [bmalloc] IsoTLSLayout and AllIsoHeaps registration is racy with derived class initialization with virtual functions
1099         https://bugs.webkit.org/show_bug.cgi?id=201448
1100
1101         Reviewed by Mark Lam.
1102
1103         In the base class of IsoTLSEntry and IsoHeapImplBase, we register each instance with the per-process linked-list singleton to
1104         offer a way to iterate all these instances. But since derived classes of IsoTLSEntry and IsoHeapImplBase have virtual functions,
1105         the instance is not fully instantiated yet when executing the base constructor! In particular, the register instance needs vtable pointer
1106         initialization in the derived constructor.
1107
1108         So, there is a race condition,
1109
1110         1. IsoTLSEntry adds itself to the global linked-list.
1111         2. IsoTLSEntry's derived class is initializing the instance including vtable pointer, this happens because base and derived classes have virtual functions.
1112         3. While doing (2), other thread iterates instances through (1)'s linked-list and call virtual functions
1113
1114         Then, crash happens because the instance vtable pointer hasn't been set to the derived class' vtable yet. IsoHeapImpl has the same problem.
1115         This issue causes some crashes in bmalloc::Scavenger::scavenge / bmalloc::IsoTLS::ensureEntries.
1116
1117         In this patch,
1118
1119         1. We introduce IsoTLSEntryHolder, which initialize the TLS entry. And after fully initializing it, the holder registers the entry with the IsoTLSLayout singleton.
1120         2. We call IsoHeapImplBase::addToAllIsoHeaps after IsoHeapImpl is fully initialized.
1121         3. We put memory barrier in IsoTLSLayout since IsoTLSLayout::head does not take a lock.
1122         4. We add unit-test that reliably reproduces IsoHeapImpl crash if we run this test ~10 times!
1123
1124         * bmalloc/AllIsoHeaps.h:
1125         * bmalloc/IsoHeapImpl.h:
1126         * bmalloc/IsoHeapImplInlines.h:
1127         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
1128         (bmalloc::IsoHeapImpl<Config>::allocatorOffset):
1129         (bmalloc::IsoHeapImpl<Config>::deallocatorOffset):
1130         * bmalloc/IsoHeapInlines.h:
1131         (bmalloc::api::IsoHeap<Type>::initialize):
1132         * bmalloc/IsoTLSAllocatorEntry.h:
1133         * bmalloc/IsoTLSDeallocatorEntry.h:
1134         * bmalloc/IsoTLSEntry.cpp:
1135         (bmalloc::IsoTLSEntry::IsoTLSEntry):
1136         * bmalloc/IsoTLSEntry.h:
1137         (bmalloc::IsoTLSEntryHolder::IsoTLSEntryHolder):
1138         (bmalloc::IsoTLSEntryHolder::operator* const):
1139         (bmalloc::IsoTLSEntryHolder::operator*):
1140         (bmalloc::IsoTLSEntryHolder::operator-> const):
1141         (bmalloc::IsoTLSEntryHolder::operator->):
1142         * bmalloc/IsoTLSLayout.cpp:
1143         (bmalloc::IsoTLSLayout::add):
1144         * bmalloc/IsoTLSLayout.h:
1145
1146 2019-08-29  Keith Rollin  <krollin@apple.com>
1147
1148         Update .xcconfig symbols to reflect the current set of past and future product versions.
1149         https://bugs.webkit.org/show_bug.cgi?id=200720
1150         <rdar://problem/54305032>
1151
1152         Reviewed by Alex Christensen.
1153
1154         Remove version symbols related to old OS's we no longer support,
1155         ensure that version symbols are defined for OS's we do support.
1156
1157         * Configurations/Base.xcconfig:
1158         * Configurations/DebugRelease.xcconfig:
1159
1160 2019-08-26  Yusuke Suzuki  <ysuzuki@apple.com>
1161
1162         [bmalloc] Disable IsoHeap completely if DebugHeap is enabled
1163         https://bugs.webkit.org/show_bug.cgi?id=201154
1164
1165         Reviewed by Simon Fraser.
1166
1167         Previously we had the guarantee that IsoHeap is disabled when DebugHeap is enabled.
1168         But this is guaranteed in a bit tricky way: when DebugHeap is enabled, Gigacage is disabled.
1169         And IsoHeap is disabled when Gigacage is disabled. However r249065 enabled IsoHeap even if
1170         Gigacage is disabled. This accidentally enabled IsoHeap even if DebugHeap is enabled.
1171
1172         Currently, this is incorrect. When DebugHeap is enabled, we do not start bmalloc::Scavenger.
1173         So IsoHeap does not work. In addition, when DebugHeap is enabled, we want to investigate the Malloc data.
1174         However IsoHeap wipes these information for IsoHeaped objects. Moreover enabling IsoHeap is not free
1175         in terms of memory usage: bmalloc::Scavenger starts working.
1176
1177         So we should not enable IsoHeap in such an accidental way for DebugHeap environment. If we consider enabling
1178         IsoHeap even if `Malloc=1` is specified, we should first examine how memory is used by this change because
1179         the users of `Malloc=1` requires explicitly tight memory usage.
1180
1181         In this patch, we remove the accidental enabling of IsoHeap for DebugHeap by checking DebugHeap status in IsoTLS.
1182
1183         * bmalloc/IsoTLS.cpp:
1184         (bmalloc::IsoTLS::determineMallocFallbackState):
1185
1186 2019-08-22  Mark Lam  <mark.lam@apple.com>
1187
1188         Undo disabling of IsoHeaps when Gigacage is off.
1189         https://bugs.webkit.org/show_bug.cgi?id=201061
1190         <rdar://problem/54622500>
1191
1192         Reviewed by Saam Barati and Michael Saboff.
1193
1194         * CMakeLists.txt:
1195         * bmalloc.xcodeproj/project.pbxproj:
1196         * bmalloc/IsoTLS.cpp:
1197         (bmalloc::IsoTLS::determineMallocFallbackState):
1198         * bmalloc/PerThread.cpp: Removed.
1199         * bmalloc/PerThread.h:
1200
1201 2019-08-19  Yusuke Suzuki  <ysuzuki@apple.com>
1202
1203         [WTF] Add makeUnique<T>, which ensures T is fast-allocated, actual static_assert part
1204         https://bugs.webkit.org/show_bug.cgi?id=200620
1205
1206         Reviewed by Geoff Garen.
1207
1208         Expose T::webkitFastMalloced type to perform static_assert in makeUnique.
1209
1210         * bmalloc/IsoHeap.h:
1211         * bmalloc/IsoHeapInlines.h:
1212
1213 2019-07-24  Yusuke Suzuki  <ysuzuki@apple.com>
1214
1215         [bmalloc] Add IsoHeap test to ensure that IsoHeap pages are not allocating too large VA
1216         https://bugs.webkit.org/show_bug.cgi?id=200103
1217
1218         Reviewed by Mark Lam.
1219
1220         * bmalloc/IsoPage.cpp:
1221
1222 2019-07-22  Yusuke Suzuki  <ysuzuki@apple.com>
1223
1224         [bmalloc] Each IsoPage gets 1MB VA because VMHeap::tryAllocateLargeChunk rounds up
1225         https://bugs.webkit.org/show_bug.cgi?id=200024
1226
1227         Reviewed by Saam Barati.
1228
1229         When we allocate IsoHeap's page, we reused VMHeap::tryAllocateLargeChunk. However, this function is originally designed
1230         to be used for Large allocation in bmalloc (e.g. allocating Chunk in bmalloc). As a result, this function rounds up the
1231         requested size with 1MB (bmalloc::chunkSize). As a result, all IsoHeap's 16KB page gets 1MB VA while it just uses 16KB of
1232         the allocated region. This leads to VA exhaustion since IsoHeap now uses 64x VA than we expected!
1233
1234         This patch fixes the above VA exhaustion issue by allocating a page by using tryVMAllocate. When allocating a page, we start
1235         using a VM tag for IsoHeap. We discussed at e-mail and we decided reusing a VM tag previously assigned to CLoop Stack since
1236         this is less profitable. Since this tag is not Malloc-related tag, Leaks tool can scan memory region conservatively without
1237         registering allocated region into Zone, which was previously done in VMHeap and that's why we reused VMHeap for IsoHeap.
1238
1239         * bmalloc/BVMTags.h:
1240         * bmalloc/IsoPage.cpp:
1241         (bmalloc::IsoPageBase::allocatePageMemory):
1242         * bmalloc/IsoTLS.cpp:
1243         (bmalloc::IsoTLS::ensureEntries):
1244         * bmalloc/VMAllocate.h:
1245         (bmalloc::vmAllocate):
1246
1247 2019-07-22  Yusuke Suzuki  <ysuzuki@apple.com>
1248
1249         Unreviewed, follow-up fix for tls->size() access
1250         https://bugs.webkit.org/show_bug.cgi?id=200019
1251
1252         * bmalloc/IsoTLS.cpp:
1253         (bmalloc::IsoTLS::ensureEntries):
1254         (bmalloc::IsoTLS::destructor):
1255
1256 2019-07-22  Yusuke Suzuki  <ysuzuki@apple.com>
1257
1258         [bmalloc] IsoTLS is not deallocated in TLS destructor
1259         https://bugs.webkit.org/show_bug.cgi?id=200019
1260
1261         Reviewed by Mark Lam.
1262
1263         TLS destructor for IsoTLS needs to deallocate memory used for IsoTLS itself.
1264         While we are correctly deallocating old IsoTLS when extending it to the new one,
1265         we lack deallocation when the thread is destroyed. IsoTLS is per-thread, so we
1266         should destroy IsoTLS when a thread finishes.
1267
1268         * bmalloc/IsoTLS.cpp:
1269         (bmalloc::IsoTLS::ensureEntries):
1270         (bmalloc::IsoTLS::destructor):
1271
1272 2019-07-12  Keith Miller  <keith_miller@apple.com>
1273
1274         Increase JSValue cage size on iOS and reduce the max slide
1275         https://bugs.webkit.org/show_bug.cgi?id=199765
1276
1277         Reviewed by Saam Barati.
1278
1279         Since the WebContent jetsam limit has changed we sometimes run out
1280         of JSValue cage VA space causing us to run out of memory for
1281         arrays. This change makes the JSValue cage a more reasonable upper
1282         limit for what should be possible without jetsamming.
1283
1284         The worst case memory mapping with this configuration is has not
1285         changed from before. Under both configurations we could map 36GB
1286         with a temporary mapping of 38GB (to align the VA to 2GB).
1287
1288         * bmalloc/Gigacage.h:
1289
1290 2019-07-03  Keith Miller  <keith_miller@apple.com>
1291
1292         PACCage should first cage leaving PAC bits intact then authenticate
1293         https://bugs.webkit.org/show_bug.cgi?id=199372
1294
1295         Reviewed by Saam Barati.
1296
1297         * bmalloc/ProcessCheck.mm:
1298         (bmalloc::shouldProcessUnconditionallyUseBmalloc):
1299
1300 2019-07-02  Commit Queue  <commit-queue@webkit.org>
1301
1302         Unreviewed, rolling out r247041.
1303         https://bugs.webkit.org/show_bug.cgi?id=199425
1304
1305         broke some iOS arm64e tests (Requested by keith_miller on
1306         #webkit).
1307
1308         Reverted changeset:
1309
1310         "PACCage should first cage leaving PAC bits intact then
1311         authenticate"
1312         https://bugs.webkit.org/show_bug.cgi?id=199372
1313         https://trac.webkit.org/changeset/247041
1314
1315 2019-07-02  Keith Miller  <keith_miller@apple.com>
1316
1317         PACCage should first cage leaving PAC bits intact then authenticate
1318         https://bugs.webkit.org/show_bug.cgi?id=199372
1319
1320         Reviewed by Saam Barati.
1321
1322         * bmalloc/ProcessCheck.mm:
1323         (bmalloc::shouldProcessUnconditionallyUseBmalloc):
1324
1325 2019-06-27  Beth Dakin  <bdakin@apple.com>
1326
1327         Upstream use of MACCATALYST
1328         https://bugs.webkit.org/show_bug.cgi?id=199245
1329         rdar://problem/51687723
1330
1331         Reviewed by Tim Horton.
1332
1333         * Configurations/SDKVariant.xcconfig:
1334
1335 2019-06-24  Yusuke Suzuki  <ysuzuki@apple.com>
1336
1337         [bmalloc] IsoHeap shared tier threshold is small
1338         https://bugs.webkit.org/show_bug.cgi?id=199145
1339
1340         Reviewed by Saam Barati.
1341
1342         We accidentally picked 3 for the shared tier threshold. While this is OK because the important part of IsoHeap shared tier is putting
1343         small # of shared objects before tiering up to the page-based allocation, increasing this threshold can potentially improve memory footprint.
1344         This patch increases this threshold from 3 to 8. A/B test says that this offers stable 0.25% improvement in PLUM2.
1345
1346         * bmalloc/IsoHeapImpl.h:
1347
1348 2019-06-21  Yusuke Suzuki  <ysuzuki@apple.com>
1349
1350         [bmalloc] IsoTLS Layout extension initializes one IsoTLSEntry twice
1351         https://bugs.webkit.org/show_bug.cgi?id=199077
1352
1353         Reviewed by Saam Barati.
1354
1355         Found that IsoTLS::ensureEntries can construct the same IsoTLSEntry many times, it can leak memory because the construction clears previous fields including freelist.
1356
1357         1. We have oldLastEntry.
1358         2. In that case, startEntry is oldLastEntry.
1359         3. We find some targetEntry.
1360         4. Finally, if startEntry exists, we newly construct [startEntry, targetEntry]
1361         5. In the above sequence, oldLastEntry (== startEntry) is constructed again, while oldLastEntry is already constructed previously.
1362
1363         We fix this issue by changing the startEntry. We already have `RELEASE_BASSERT(!oldLastEntry || oldLastEntry->offset() < offset);`
1364         assertion. This means that `oldLastEntry->m_next` must exist, otherwise the following loop would not find a `targetEntry`. And `layout.head()`
1365         must return non nullptr at `IsoTLS::ensureEntries` because `IsoTLS::ensureEntries` requires that `IsoHeap<>` is initialized, and `IsoHeap<>`
1366         must add at least one TLS entry to the IsoTLSLayout.
1367
1368         * bmalloc/IsoTLS.cpp:
1369         (bmalloc::IsoTLS::ensureEntries):
1370
1371 2019-06-19  Yusuke Suzuki  <ysuzuki@apple.com>
1372
1373         [bmalloc] IsoHeap's initialization is racy with IsoHeap::isInitialized
1374         https://bugs.webkit.org/show_bug.cgi?id=199053
1375
1376         Reviewed by Saam Barati.
1377
1378         IsoHeap's initialization code is racy. Let's see the `isInitialized` and the initialization code.
1379
1380         isInitialized:
1381
1382             template<typename Type>
1383             bool IsoHeap<Type>::isInitialized()
1384             {
1385                 std::atomic<unsigned>* atomic =
1386                     reinterpret_cast<std::atomic<unsigned>*>(&m_allocatorOffsetPlusOne);
1387                 return !!atomic->load(std::memory_order_acquire);
1388             }
1389
1390         initialization:
1391
1392             if (!handle.isInitialized()) {
1393                 std::lock_guard<Mutex> locker(handle.m_initializationLock);
1394                 if (!handle.isInitialized()) {
1395                     auto* heap = new IsoHeapImpl<typename api::IsoHeap<Type>::Config>();
1396                     std::atomic_thread_fence(std::memory_order_seq_cst);
1397                     handle.setAllocatorOffset(heap->allocatorOffset());                  // <================= (1)
1398                     handle.setDeallocatorOffset(heap->deallocatorOffset());              // (2)
1399                     handle.m_impl = heap;
1400                 }
1401             }
1402
1403         IsoHeap::isInitialized is loading m_allocatorOffsetPlusOne with acquire fence. On the other hand, the initialization
1404         code configures m_allocatorOffsetPlusOne (1) before configuring m_deallocatorOffsetPlusOne (2). Let's consider the following
1405         case.
1406
1407             1. Thread A is at (1)
1408             2. Thread B calls handle.isInitialized(). Then B think that handle is already initialized while it lacks m_deallocatorOffsetPlusOne and m_impl pointer.
1409             3. Thread B uses this handle, and does `std::max(handle.allocatorOffset(), handle.deallocatorOffset())`. But m_deallocatorOffsetPlusOne is not configured
1410                yet. As a result, deallocatorOffset() returns 0xffffffff (b/c it calculates m_deallocatorOffsetPlusOne - 1, and m_deallocatorOffsetPlusOne is first
1411                zero-initialized before IsoHeap initialization happens).
1412             4. std::max returns 0xffffffff as an offset. Of course, this is wrong, and leading to the release assertion.
1413
1414         This patch fixes the above issue by,
1415
1416             1. Add IsoHeap::initialize() function instead of initializing it in IsoTLS
1417             2. Change `isInitialized()` function to load m_impl pointer instead of m_allocatorOffsetPlusOne with acquire fence.
1418             3. In initialize() function, we store m_heap with release fence at last.
1419
1420         * bmalloc/IsoHeap.h:
1421         * bmalloc/IsoHeapInlines.h:
1422         (bmalloc::api::IsoHeap<Type>::isInitialized):
1423         (bmalloc::api::IsoHeap<Type>::initialize):
1424         * bmalloc/IsoTLSInlines.h:
1425         (bmalloc::IsoTLS::ensureHeap):
1426
1427 2019-06-14  Keith Miller  <keith_miller@apple.com>
1428
1429         Restore PAC based cage.
1430         https://bugs.webkit.org/show_bug.cgi?id=198872
1431
1432         Rubber-stamped by Saam Barati.
1433
1434         * bmalloc/Gigacage.h:
1435
1436 2019-06-12  Commit Queue  <commit-queue@webkit.org>
1437
1438         Unreviewed, rolling out r246322.
1439         https://bugs.webkit.org/show_bug.cgi?id=198796
1440
1441         "It's a huge page load regression on iOS" (Requested by
1442         saamyjoon on #webkit).
1443
1444         Reverted changeset:
1445
1446         "Roll out PAC cage"
1447         https://bugs.webkit.org/show_bug.cgi?id=198726
1448         https://trac.webkit.org/changeset/246322
1449
1450 2019-06-11  Saam Barati  <sbarati@apple.com>
1451
1452         Roll out PAC cage
1453         https://bugs.webkit.org/show_bug.cgi?id=198726
1454
1455         Reviewed by Keith Miller.
1456
1457         * bmalloc/Gigacage.h:
1458         (Gigacage::isEnabled):
1459         (Gigacage::caged):
1460         (Gigacage::cagedMayBeNull): Deleted.
1461
1462 2019-06-09  Commit Queue  <commit-queue@webkit.org>
1463
1464         Unreviewed, rolling out r246150, r246160, and r246166.
1465         https://bugs.webkit.org/show_bug.cgi?id=198698
1466
1467         Regresses page loading time on iOS 13 (Requested by keith_m__
1468         on #webkit).
1469
1470         Reverted changesets:
1471
1472         "Reenable Gigacage on ARM64."
1473         https://bugs.webkit.org/show_bug.cgi?id=198453
1474         https://trac.webkit.org/changeset/246150
1475
1476         "Unrevied build fix for FTL without Gigacage."
1477         https://trac.webkit.org/changeset/246160
1478
1479         "Fix typo in cageWithoutUntagging"
1480         https://bugs.webkit.org/show_bug.cgi?id=198617
1481         https://trac.webkit.org/changeset/246166
1482
1483 2019-06-06  Keith Miller  <keith_miller@apple.com>
1484
1485         Reenable Gigacage on ARM64.
1486         https://bugs.webkit.org/show_bug.cgi?id=198453
1487
1488         Reviewed by Michael Saboff.
1489
1490         * bmalloc/Gigacage.h:
1491
1492 2019-06-03  Commit Queue  <commit-queue@webkit.org>
1493
1494         Unreviewed, rolling out r246022.
1495         https://bugs.webkit.org/show_bug.cgi?id=198486
1496
1497         Causing Internal build failures and JSC test failures
1498         (Requested by ShawnRoberts on #webkit).
1499
1500         Reverted changeset:
1501
1502         "Reenable Gigacage on ARM64."
1503         https://bugs.webkit.org/show_bug.cgi?id=198453
1504         https://trac.webkit.org/changeset/246022
1505
1506 2019-06-02  Keith Miller  <keith_miller@apple.com>
1507
1508         Reenable Gigacage on ARM64.
1509         https://bugs.webkit.org/show_bug.cgi?id=198453
1510
1511         Reviewed by Filip Pizlo.
1512
1513         * bmalloc/Gigacage.h:
1514
1515 2019-05-30  Don Olmstead  <don.olmstead@sony.com>
1516
1517         [CMake] Add WEBKIT_FRAMEWORK_TARGET macro
1518         https://bugs.webkit.org/show_bug.cgi?id=198396
1519
1520         Reviewed by Konstantin Tokarev.
1521
1522         Use WEBKIT_FRAMEWORK_TARGET.
1523
1524         * CMakeLists.txt:
1525
1526 2019-05-30  Keith Miller  <keith_miller@apple.com>
1527
1528         IsoHeaps don't notice uncommitted VA becoming the first eligible.
1529         https://bugs.webkit.org/show_bug.cgi?id=198301
1530
1531         Reviewed by Yusuke Suzuki.
1532
1533         IsoDirectory has a firstEligible member that is used as an
1534         optimization to help find the first fit. However if the scavenger
1535         decommitted a page before firstEligible then we wouldn't move
1536         firstEligible. Thus, if no space is ever freed below firstEligible
1537         we will never reused the decommitted memory (e.g. if the VA page
1538         is decommitted). The fix is to make IsoDirectory::didDecommit move
1539         the firstEligible page back if the decommitted page is smaller
1540         than the current firstEligible. As such, this patch renames
1541         firstEligible to firstEligibleOrDecommitted.
1542
1543         Also, this patch changes gigacageEnabledForProcess to check if the
1544         process starts with Test rather than just test as TestWTF does.
1545
1546         Lastly, unbeknownst to me IsoHeaps are dependent on gigacage, so
1547         by removing gigacage from arm64 I accidentally disabled
1548         IsoHeaps...
1549
1550         * bmalloc.xcodeproj/project.pbxproj:
1551         * bmalloc/IsoDirectory.h:
1552         * bmalloc/IsoDirectoryInlines.h:
1553         (bmalloc::passedNumPages>::takeFirstEligible):
1554         (bmalloc::passedNumPages>::didBecome):
1555         (bmalloc::passedNumPages>::didDecommit):
1556         * bmalloc/IsoHeapImpl.h:
1557         * bmalloc/IsoHeapImplInlines.h:
1558         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
1559         (bmalloc::IsoHeapImpl<Config>::didBecomeEligibleOrDecommited):
1560         (bmalloc::IsoHeapImpl<Config>::didCommit):
1561         (bmalloc::IsoHeapImpl<Config>::didBecomeEligible): Deleted.
1562         * bmalloc/IsoTLS.cpp:
1563         (bmalloc::IsoTLS::determineMallocFallbackState):
1564         * bmalloc/ProcessCheck.mm:
1565         (bmalloc::gigacageEnabledForProcess):
1566
1567 2019-05-23  Don Olmstead  <don.olmstead@sony.com>
1568
1569         [CMake] Use target oriented design for bmalloc
1570         https://bugs.webkit.org/show_bug.cgi?id=198046
1571
1572         Reviewed by Konstantin Tokarev.
1573
1574         Switch to a target oriented dsign for bmalloc. Use target_include_directories directly
1575         instead of include_directories.
1576
1577         List the headers for bmalloc and copy them using WEBKIT_COPY_FILES.
1578
1579         Add an intermediate target bmalloc_PostBuild which depends on bmalloc and the headers
1580         being copied. Then alias that to WebKit::bmalloc.
1581
1582         * CMakeLists.txt:
1583         * PlatformMac.cmake:
1584
1585 2019-05-16  Keith Miller  <keith_miller@apple.com>
1586
1587         Wasm should cage the memory base pointers in structs
1588         https://bugs.webkit.org/show_bug.cgi?id=197620
1589
1590         Reviewed by Saam Barati.
1591
1592         Fix signature to take Gigacage::Kind, which matches GIGACAGE_ENABLED build.
1593
1594         * bmalloc/Gigacage.h:
1595         (Gigacage::isEnabled):
1596
1597 2019-05-08  Keith Miller  <keith_miller@apple.com>
1598
1599         Remove Gigacage from arm64 and use PAC for arm64e instead
1600         https://bugs.webkit.org/show_bug.cgi?id=197110
1601
1602         Reviewed by Saam Barati.
1603
1604         Stop using gigacage on arm64 and add a new cage function cagedMayBeNull that is the same as
1605         cage but returns a nullptr if the incoming pointer is already null.
1606
1607         * bmalloc/Gigacage.h:
1608         (Gigacage::cagedMayBeNull):
1609
1610 2019-04-29  Alex Christensen  <achristensen@webkit.org>
1611
1612         <rdar://problem/50299396> Fix internal High Sierra build
1613         https://bugs.webkit.org/show_bug.cgi?id=197388
1614
1615         * Configurations/Base.xcconfig:
1616
1617 2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>
1618
1619         [bmalloc] Follow-up and fixing bug after r244481
1620         https://bugs.webkit.org/show_bug.cgi?id=197294
1621
1622         Reviewed by Saam Barati.
1623
1624         This patch includes follow-up after r244481 and bug fixes which is introduced in the refactoring.
1625
1626         * bmalloc/IsoAllocator.h: Remove unused function.
1627         * bmalloc/IsoAllocatorInlines.h:
1628         (bmalloc::IsoAllocator<Config>::allocateSlow):
1629         * bmalloc/IsoDeallocatorInlines.h:
1630         (bmalloc::IsoDeallocator<Config>::deallocate):
1631         * bmalloc/IsoHeapImpl.h: Rename m_usableBits to m_availableShared and add static_assert.
1632         * bmalloc/IsoHeapImplInlines.h: Do not clear m_numberOfAllocationsFromSharedInOneCycle etc. in scavenge since IsoHeapImpl::scavenge
1633         is not related to thread-local IsoAllocator's status.
1634         (bmalloc::IsoHeapImpl<Config>::scavenge):
1635         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
1636         (bmalloc::IsoHeapImpl<Config>::updateAllocationMode): Update m_allocationMode correctly.
1637         (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
1638         * bmalloc/IsoSharedHeapInlines.h:
1639         (bmalloc::computeObjectSizeForSharedCell):
1640         (bmalloc::IsoSharedHeap::allocateNew):
1641         (bmalloc::IsoSharedHeap::allocateSlow): Add computeObjectSizeForSharedCell.
1642         * bmalloc/IsoSharedPage.h:
1643         * bmalloc/IsoSharedPageInlines.h:
1644         (bmalloc::IsoSharedPage::free): Pass `const std::lock_guard<Mutex>&` in its parameter.
1645
1646 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1647
1648         Start using C++17
1649         https://bugs.webkit.org/show_bug.cgi?id=197131
1650
1651         Reviewed by Darin Adler.
1652
1653         * Configurations/Base.xcconfig:
1654
1655 2019-04-24  Yusuke Suzuki  <ysuzuki@apple.com>
1656
1657         Unreviewed, fix typo in r244481
1658         https://bugs.webkit.org/show_bug.cgi?id=196837
1659
1660         * bmalloc/IsoHeapImplInlines.h:
1661         (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
1662
1663 2019-04-21  Yusuke Suzuki  <ysuzuki@apple.com>
1664
1665         [bmalloc] Use StaticPerProcess' mutex as bmalloc::Heap does with PerProcess
1666         https://bugs.webkit.org/show_bug.cgi?id=197135
1667
1668         Reviewed by Darin Adler.
1669
1670         This patch leverages StaticPerProcess::mutex() for per process instance's lock in various classes,
1671         as Heap does with PerProcess::mutex().
1672
1673         * bmalloc/AllIsoHeaps.cpp:
1674         (bmalloc::AllIsoHeaps::add):
1675         (bmalloc::AllIsoHeaps::head):
1676         * bmalloc/AllIsoHeaps.h:
1677         * bmalloc/CryptoRandom.cpp:
1678         (bmalloc::ARC4RandomNumberGenerator::randomValues):
1679         * bmalloc/DebugHeap.cpp:
1680         (bmalloc::DebugHeap::memalignLarge):
1681         (bmalloc::DebugHeap::freeLarge):
1682         * bmalloc/DebugHeap.h:
1683         * bmalloc/Scavenger.cpp:
1684         (bmalloc::Scavenger::run):
1685         (bmalloc::Scavenger::runSoon):
1686         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
1687         (bmalloc::Scavenger::schedule):
1688         (bmalloc::Scavenger::timeSinceLastFullScavenge):
1689         (bmalloc::Scavenger::scavenge):
1690         (bmalloc::Scavenger::threadRunLoop):
1691         * bmalloc/Scavenger.h:
1692
1693 2019-04-19  Yusuke Suzuki  <ysuzuki@apple.com>
1694
1695         [bmalloc] IsoHeap should have lower tier using shared IsoPage
1696         https://bugs.webkit.org/show_bug.cgi?id=196837
1697
1698         Reviewed by Filip Pizlo.
1699
1700         IsoHeap had a scalability problem. Once one instance is allocated from IsoHeap, it immediately allocates 16KB page for this type.
1701         But some types allocate only a few instances. It leads to memory wastage, and it also limits the scalability of IsoHeap since
1702         we need to carefully select classes which will be confined in IsoHeap due to this characteristics. If we can remove this wastage,
1703         we can apply IsoHeap more aggressively without causing memory regression, this is the goal of this patch.
1704
1705         In this patch, we introduce a slow tier to IsoHeap allocation. Initially, the allocator for a certain type allocates instances from
1706         a shared page with the other allocators, and eventually, the allocator tiers up and gets dedicated pages if instances of the type
1707         are allocated a lot. This "shared" tier is slow, but it is totally OK because we will tier up to the normal fast tier if allocation
1708         frequently happens. Even the instance is allocated from pages shared with the other allocators, we still make the allocated memory
1709         region dedicated to the specific type: once a memory region is allocated for a certain type from a shared page, this region continues
1710         being used only for this type even after this memory is freed. To summarize the changes:
1711
1712         1. We introduce "shared" tier to IsoHeap allocation. Up to N (N = 8 for now, but we can pick any power-of-two numbers up to 32) allocations,
1713            we continue using this tier. We allocate memory from shared pages so that we do not waste 16KB pages for types which only allocates a few instances.
1714
1715         2. We eventually tier up to the "fast" tier, and eventually tier down to the "shared" tier too. We measure the period between slow paths,
1716            and switch the appropriate tier for the type. Currently, we use 1 seconds as heuristics. We also count # of allocations per cycle to
1717            avoid pathological slow downs.
1718
1719         3. Shared page mechanism must keep the characteristics of IsoHeap. Once a memory region is allocated for a certain type, this memory region
1720            must be dedicated to this type. We keep track the allocated memory regions from shared pages in IsoHeapImpl, and ensure that we never
1721            reuse a memory region for a different type.
1722
1723         This patch improves PLUM2 by 1.4% (128.4MB v.s. 126.62MB), and early Speedometer2 results are performance-neutral.
1724
1725         * CMakeLists.txt:
1726         * bmalloc.xcodeproj/project.pbxproj:
1727         * bmalloc/Algorithm.h:
1728         (bmalloc::roundUpToMultipleOfImpl):
1729         (bmalloc::roundUpToMultipleOf):
1730         * bmalloc/BCompiler.h:
1731         * bmalloc/BExport.h:
1732         * bmalloc/FreeList.h:
1733         * bmalloc/IsoAllocator.h:
1734         * bmalloc/IsoAllocatorInlines.h:
1735         (bmalloc::IsoAllocator<Config>::allocateSlow):
1736         * bmalloc/IsoDeallocator.h:
1737         * bmalloc/IsoDeallocatorInlines.h:
1738         (bmalloc::IsoDeallocator<Config>::deallocate):
1739         * bmalloc/IsoHeapImpl.h:
1740         * bmalloc/IsoHeapImplInlines.h:
1741         (bmalloc::IsoHeapImpl<Config>::scavenge):
1742         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
1743         (bmalloc::IsoHeapImpl<Config>::updateAllocationMode):
1744         (bmalloc::IsoHeapImpl<Config>::allocateFromShared):
1745         * bmalloc/IsoPage.h:
1746         (bmalloc::IsoPageBase::IsoPageBase):
1747         (bmalloc::IsoPageBase::isShared const):
1748         * bmalloc/IsoPageInlines.h:
1749         (bmalloc::IsoPage<Config>::IsoPage):
1750         (bmalloc::IsoPageBase::pageFor):
1751         (bmalloc::IsoPage<Config>::pageFor):
1752         (bmalloc::IsoPage<Config>::free):
1753         * bmalloc/IsoSharedConfig.h: Copied from Source/bmalloc/bmalloc/BExport.h.
1754         * bmalloc/IsoSharedHeap.cpp: Copied from Source/bmalloc/bmalloc/BExport.h.
1755         * bmalloc/IsoSharedHeap.h: Copied from Source/bmalloc/bmalloc/IsoAllocator.h.
1756         (bmalloc::VariadicBumpAllocator::VariadicBumpAllocator):
1757         (bmalloc::IsoSharedHeap::IsoSharedHeap):
1758         * bmalloc/IsoSharedHeapInlines.h: Added.
1759         (bmalloc::VariadicBumpAllocator::allocate):
1760         (bmalloc::IsoSharedHeap::allocateNew):
1761         (bmalloc::IsoSharedHeap::allocateSlow):
1762         * bmalloc/IsoSharedPage.cpp: Copied from Source/bmalloc/bmalloc/BExport.h.
1763         (bmalloc::IsoSharedPage::tryCreate):
1764         * bmalloc/IsoSharedPage.h: Copied from Source/bmalloc/bmalloc/IsoDeallocator.h.
1765         (bmalloc::IsoSharedPage::IsoSharedPage):
1766         (bmalloc::indexSlotFor):
1767         * bmalloc/IsoSharedPageInlines.h: Added.
1768         (bmalloc::IsoSharedPage::free):
1769         (bmalloc::IsoSharedPage::startAllocating):
1770         (bmalloc::IsoSharedPage::stopAllocating):
1771         * bmalloc/IsoTLS.h:
1772         * bmalloc/IsoTLSInlines.h:
1773         (bmalloc::IsoTLS::deallocateImpl):
1774         (bmalloc::IsoTLS::deallocateFast):
1775         (bmalloc::IsoTLS::deallocateSlow):
1776         * bmalloc/StdLibExtras.h:
1777         (bmalloc::bitwise_cast):
1778         * test/testbmalloc.cpp:
1779         (testIsoMallocAndFreeFast):
1780         (run):
1781
1782 2019-04-18  Yusuke Suzuki  <ysuzuki@apple.com>
1783
1784         Unreviewed, fix build failure
1785         https://bugs.webkit.org/show_bug.cgi?id=195938
1786
1787         Including <array>.
1788
1789         * bmalloc/AvailableMemory.cpp:
1790
1791 2019-04-15  Yoshiaki Jitsukawa  <yoshiaki.jitsukawa@sony.com>
1792
1793         Unreviewed. Build fix after r244244.
1794
1795         * bmalloc/AvailableMemory.cpp:
1796
1797 2019-04-13  Zan Dobersek  <zdobersek@igalia.com>
1798
1799         [bmalloc][Linux] Add support for memory status calculation
1800         https://bugs.webkit.org/show_bug.cgi?id=195938
1801
1802         Reviewed by Carlos Garcia Campos.
1803
1804         Memory status and under-memory-pressure capabilities in bmalloc can be
1805         implemented on Linux by reading and parsing the statm file under the
1806         proc filesystem.
1807
1808         We retrieve the resident set size from the statm file and multiply it
1809         with the page size. This gives an upper-bound estimate of the memory
1810         that's being consumed by the process.
1811
1812         The statm-based estimate seems preferable to other alternatives. One
1813         such alternative would be reading and parsing more-detailed smaps file,
1814         also exposed under the proc filesystem. This is at the moment being done
1815         in WTF's MemoryFootprint implementation for Linux systems, but on Linux
1816         ports this operation is being throttled to only execute once per second
1817         because of the big computing expense required to read and parse out the
1818         data. A future MemoryFootprint implementation could simply retrieve the
1819         memory footprint value from bmalloc.
1820
1821         Another alternative is the Linux taskstats interface. This one would
1822         require utilizing a netlink socket to retrieve the necessary statistics,
1823         but it requires the process to have elevated privileges, which is a
1824         blocker.
1825
1826         * bmalloc/AvailableMemory.cpp:
1827         (bmalloc::LinuxMemory::singleton):
1828         (bmalloc::LinuxMemory::footprint const):
1829         (bmalloc::computeAvailableMemory):
1830         (bmalloc::memoryStatus):
1831         * bmalloc/AvailableMemory.h:
1832         (bmalloc::isUnderMemoryPressure):
1833         * bmalloc/bmalloc.h:
1834
1835 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
1836
1837         [WebCore] Put most of derived classes of ScriptWrappable into IsoHeap
1838         https://bugs.webkit.org/show_bug.cgi?id=196475
1839
1840         Reviewed by Saam Barati.
1841
1842         Add MAKE_BISO_MALLOCED_IMPL_TEMPLATE, which can be used for explicit specialization for template classes.
1843
1844         * bmalloc/IsoHeap.h:
1845         * bmalloc/IsoHeapInlines.h:
1846
1847 2019-03-22  Keith Rollin  <krollin@apple.com>
1848
1849         Enable ThinLTO support in Production builds
1850         https://bugs.webkit.org/show_bug.cgi?id=190758
1851         <rdar://problem/45413233>
1852
1853         Reviewed by Daniel Bates.
1854
1855         Enable building with Thin LTO in Production when using Xcode 10.2 or
1856         later. This change results in a 1.45% progression in PLT5. Full
1857         Production build times increase about 2-3%. Incremental build times
1858         are more severely affected, and so LTO is not enabled for local
1859         engineering builds.
1860
1861         LTO is enabled only on macOS for now, until rdar://problem/49013399,
1862         which affects ARM builds, is fixed.
1863
1864         To change the LTO setting when building locally:
1865
1866         - If building with `make`, specify WK_LTO_MODE={none,thin,full} on the
1867           command line.
1868         - If building with `build-webkit`, specify --lto-mode={none,thin,full}
1869           on the command line.
1870         - If building with `build-root`, specify --lto={none,thin,full} on the
1871           command line.
1872         - If building with Xcode, create a LocalOverrides.xcconfig file at the
1873           top level of your repository directory (if needed) and define
1874           WK_LTO_MODE to full, thin, or none.
1875
1876         * Configurations/Base.xcconfig:
1877
1878 2019-03-21  Michael Saboff  <msaboff@apple.com>
1879
1880         [BMalloc] No need to delay deallocating chunks based on recent use
1881         https://bugs.webkit.org/show_bug.cgi?id=196121
1882
1883         Reviewed by Mark Lam.
1884
1885         The "used since last scavenge" logic is not needed for small chunks since their memory isn't decommitted directly.
1886         We can deallocate small chunks immediately as that adds them to the LargeRange free list.  That free list employs the
1887         "used since last scavenge" logic before the scavenger decommits the backing memory.
1888
1889         * bmalloc/Chunk.h:
1890         (bmalloc::Chunk::usedSinceLastScavenge): Deleted.
1891         (bmalloc::Chunk::clearUsedSinceLastScavenge): Deleted.
1892         (bmalloc::Chunk::setUsedSinceLastScavenge): Deleted.
1893         * bmalloc/Heap.cpp:
1894         (bmalloc::Heap::scavenge):
1895         (bmalloc::Heap::allocateSmallPage):
1896
1897 2019-03-21  Brady Eidson  <beidson@apple.com>
1898
1899         Certain WebProcesses should opt-out of the freezer.
1900         <rdar://problem/42846139> and https://bugs.webkit.org/show_bug.cgi?id=196062
1901
1902         Reviewed by Andy Estes.
1903
1904         * bmalloc.xcodeproj/project.pbxproj:
1905         * bmalloc/darwin/MemoryStatusSPI.h:
1906
1907 2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
1908
1909         Unreviewed, fix -Wformat warning
1910         https://bugs.webkit.org/show_bug.cgi?id=195895
1911         <rdar://problem/48517629>
1912
1913         * bmalloc/Scavenger.cpp:
1914         (bmalloc::Scavenger::threadRunLoop):
1915
1916 2019-03-18  Michael Saboff  <msaboff@apple.com>
1917
1918         [BMalloc] Scavenger should react to recent memory activity
1919         https://bugs.webkit.org/show_bug.cgi?id=195895
1920
1921         Reviewed by Geoffrey Garen.
1922
1923         This change adds a recently used bit to objects that are scavenged.  When an object is allocated, that bit is set.
1924         When we scavenge, if the bit is set, we clear it.  If the bit was already clear, we decommit the object.  The timing
1925         to scavenging has been changed as well.  We perform our first scavne almost immediately after bmalloc is initialized
1926         (10ms later).  Subsequent scavenging is done as a multiple of the time it took to scavenge.  We bound this computed
1927         time between a minimum and maximum.  Through empirical testing, the multiplier, minimum and maximum are
1928         150x, 100ms and 10,000ms respectively.  For mini-mode, when the JIT is disabled, we use much more aggressive values of
1929         50x, 25ms and 500ms.
1930
1931         Eliminated partial scavenging since this change allows for any scavenge to be partial or full based on recent use of
1932         the objects on the various free lists.
1933
1934         * bmalloc/Chunk.h:
1935         (bmalloc::Chunk::usedSinceLastScavenge):
1936         (bmalloc::Chunk::clearUsedSinceLastScavenge):
1937         (bmalloc::Chunk::setUsedSinceLastScavenge):
1938         * bmalloc/Heap.cpp:
1939         (bmalloc::Heap::scavenge):
1940         (bmalloc::Heap::allocateSmallChunk):
1941         (bmalloc::Heap::allocateSmallPage):
1942         (bmalloc::Heap::splitAndAllocate):
1943         (bmalloc::Heap::tryAllocateLarge):
1944         (bmalloc::Heap::scavengeToHighWatermark): Deleted.
1945         * bmalloc/Heap.h:
1946         * bmalloc/IsoDirectory.h:
1947         * bmalloc/IsoDirectoryInlines.h:
1948         (bmalloc::passedNumPages>::takeFirstEligible):
1949         (bmalloc::passedNumPages>::scavenge):
1950         (bmalloc::passedNumPages>::scavengeToHighWatermark): Deleted.
1951         * bmalloc/IsoHeapImpl.h:
1952         * bmalloc/IsoHeapImplInlines.h:
1953         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark): Deleted.
1954         * bmalloc/LargeRange.h:
1955         (bmalloc::LargeRange::LargeRange):
1956         (bmalloc::LargeRange::usedSinceLastScavenge):
1957         (bmalloc::LargeRange::clearUsedSinceLastScavenge):
1958         (bmalloc::LargeRange::setUsedSinceLastScavenge):
1959         (): Deleted.
1960         * bmalloc/Scavenger.cpp:
1961         (bmalloc::Scavenger::Scavenger):
1962         (bmalloc::Scavenger::threadRunLoop):
1963         (bmalloc::Scavenger::timeSinceLastPartialScavenge): Deleted.
1964         (bmalloc::Scavenger::partialScavenge): Deleted.
1965         * bmalloc/Scavenger.h:
1966         * bmalloc/SmallPage.h:
1967         (bmalloc::SmallPage::usedSinceLastScavenge):
1968         (bmalloc::SmallPage::clearUsedSinceLastScavenge):
1969         (bmalloc::SmallPage::setUsedSinceLastScavenge):
1970
1971 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
1972
1973         [bmalloc] Add StaticPerProcess for known types to save pages
1974         https://bugs.webkit.org/show_bug.cgi?id=195691
1975
1976         Reviewed by Mark Lam.
1977
1978         As initial memory footprint of VM + JSGlobalObject becomes 488KB dirty size in fast malloc memory (w/ JSC_useJIT=0 and Malloc=1), pages for PerProcess is costly.
1979         For example, under Malloc=1 mode, we still need to allocate PerProcess<DebugHeap> and PerProcess<Environment>. And sizeof(Environment) is only 1 (bool flag), and
1980         sizeof(DebugHeap) is 120. But we are allocating 1 pages for them. Since page size in iOS is 16KB, this 121B consumes 16KB dirty memory, and it is not negligible
1981         size if we keep in mind that the current fast malloc heap size is 488KB. Putting them into the __DATA section, close to the other mutable data, we can avoid allocating
1982         this page.
1983
1984         This patch revives the SafePerProcess concept in r228107. We add "StaticPerProcess<T>", which allocates underlying storage statically in the __DATA section instead of
1985         allocating it at runtime. And we use this StaticPerProcess<T> for types where (1) T is known a priori, and (2) sizeof(T) is not huge.
1986
1987         * bmalloc.xcodeproj/project.pbxproj:
1988         * bmalloc/AllIsoHeaps.cpp:
1989         * bmalloc/AllIsoHeaps.h:
1990         * bmalloc/Allocator.cpp:
1991         (bmalloc::Allocator::Allocator):
1992         * bmalloc/Cache.cpp:
1993         (bmalloc::Cache::Cache):
1994         * bmalloc/CryptoRandom.cpp:
1995         (bmalloc::cryptoRandom):
1996         * bmalloc/Deallocator.cpp:
1997         (bmalloc::Deallocator::Deallocator):
1998         * bmalloc/DebugHeap.cpp:
1999         * bmalloc/DebugHeap.h:
2000         (bmalloc::DebugHeap::tryGet):
2001         * bmalloc/Environment.cpp:
2002         * bmalloc/Environment.h:
2003         * bmalloc/Gigacage.cpp:
2004         (Gigacage::Callback::Callback):
2005         (Gigacage::Callback::function):
2006         (bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
2007         (Gigacage::disablePrimitiveGigacage):
2008         (Gigacage::addPrimitiveDisableCallback):
2009         (Gigacage::removePrimitiveDisableCallback):
2010         (Gigacage::shouldBeEnabled):
2011         (Gigacage::bmalloc::Callback::Callback): Deleted.
2012         (Gigacage::bmalloc::Callback::function): Deleted.
2013         (Gigacage::bmalloc::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
2014         * bmalloc/Heap.cpp:
2015         (bmalloc::Heap::Heap):
2016         (bmalloc::Heap::tryAllocateLarge):
2017         * bmalloc/IsoDirectoryInlines.h:
2018         (bmalloc::passedNumPages>::takeFirstEligible):
2019         (bmalloc::passedNumPages>::didBecome):
2020         * bmalloc/IsoHeapImpl.cpp:
2021         (bmalloc::IsoHeapImplBase::addToAllIsoHeaps):
2022         * bmalloc/IsoPage.cpp:
2023         (bmalloc::IsoPageBase::allocatePageMemory):
2024         * bmalloc/IsoTLS.cpp:
2025         (bmalloc::IsoTLS::IsoTLS):
2026         (bmalloc::IsoTLS::ensureEntries):
2027         (bmalloc::IsoTLS::forEachEntry):
2028         * bmalloc/IsoTLSEntry.cpp:
2029         (bmalloc::IsoTLSEntry::IsoTLSEntry):
2030         * bmalloc/IsoTLSInlines.h:
2031         (bmalloc::IsoTLS::allocateSlow):
2032         (bmalloc::IsoTLS::deallocateSlow):
2033         * bmalloc/IsoTLSLayout.cpp:
2034         * bmalloc/IsoTLSLayout.h:
2035         * bmalloc/Scavenger.cpp:
2036         (bmalloc::Scavenger::Scavenger):
2037         (bmalloc::dumpStats):
2038         (bmalloc::Scavenger::scavenge):
2039         (bmalloc::Scavenger::partialScavenge):
2040         (bmalloc::Scavenger::freeableMemory):
2041         (bmalloc::Scavenger::footprint):
2042         * bmalloc/Scavenger.h:
2043         * bmalloc/StaticPerProcess.h: Added.
2044         * bmalloc/VMHeap.cpp:
2045         * bmalloc/VMHeap.h:
2046         * bmalloc/Zone.h:
2047         * bmalloc/bmalloc.cpp:
2048         (bmalloc::api::scavenge):
2049         (bmalloc::api::isEnabled):
2050         (bmalloc::api::setScavengerThreadQOSClass):
2051         (bmalloc::api::enableMiniMode):
2052         * test/testbmalloc.cpp:
2053         (assertEmptyPointerSet):
2054         (assertHasObjects):
2055         (assertHasOnlyObjects):
2056         (assertClean):
2057
2058 2019-03-13  Yoshiaki Jitsukawa  <yoshiaki.jitsukawa@sony.com>
2059
2060         [bmalloc] Use MADV_FREE on FreeBSD
2061         https://bugs.webkit.org/show_bug.cgi?id=195665
2062
2063         Reviewed by Geoffrey Garen.
2064
2065         * bmalloc/BPlatform.h:
2066
2067         Introduce BOS_FREEBSD, which is equivalent to WTF_OS_FREEBSD
2068
2069         * bmalloc/VMAllocate.h:
2070         (bmalloc::vmDeallocatePhysicalPages):
2071
2072         Use MADV_FREE instead of MADV_DONTNEED if BOS(FREEBSD), since on FreeBSD,
2073         unlike on Linux, MADV_DONTNEED doesn't let the OS discard the contents of
2074         the pages.
2075
2076 2019-03-13  Sam Weinig  <sam@webkit.org>
2077
2078         Fix testbmalloc build
2079         https://bugs.webkit.org/show_bug.cgi?id=195660
2080
2081         Reviewed by Geoffrey Garen.
2082
2083         * bmalloc.xcodeproj/project.pbxproj:
2084         Link Foundation in when building testbmalloc. Since bmalloc requires Foundation, and is a static
2085         library, all clients of bmalloc are required to link it themselves.
2086         
2087         * bmalloc/IsoPageInlines.h:
2088         * bmalloc/StdLibExtras.h: Added.
2089         (bmalloc::bitwise_cast):
2090         Add bitwise_cast implementation, and use it in IsoPageInlines.h. It is a layering violation
2091         to expect the one from WTF to be available, as seems to have been the case.
2092
2093 2019-03-12  Robin Morisset  <rmorisset@apple.com>
2094
2095         A lot more classes have padding that can be reduced by reordering their fields
2096         https://bugs.webkit.org/show_bug.cgi?id=195579
2097
2098         Reviewed by Mark Lam.
2099
2100         * bmalloc/Heap.h:
2101         * bmalloc/Scavenger.h:
2102
2103 2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
2104
2105         [bmalloc] Bmalloc DebugHeap should have dump and scavenge features
2106         https://bugs.webkit.org/show_bug.cgi?id=195305
2107
2108         Reviewed by Saam Barati.
2109
2110         As the same to bmalloc, bmalloc::DebugHeap should have scavenge feature to make it scavengable if we want.
2111         We also add DebugHeap::dump feature which dumps system malloc data in the WebKit Malloc zone.
2112
2113         * bmalloc/DebugHeap.cpp:
2114         (bmalloc::DebugHeap::scavenge):
2115         (bmalloc::DebugHeap::dump):
2116         * bmalloc/DebugHeap.h:
2117         * bmalloc/bmalloc.cpp:
2118         (bmalloc::api::scavenge):
2119
2120 2019-02-23  Keith Miller  <keith_miller@apple.com>
2121
2122         Add new mac target numbers
2123         https://bugs.webkit.org/show_bug.cgi?id=194955
2124
2125         Reviewed by Tim Horton.
2126
2127         * Configurations/Base.xcconfig:
2128         * Configurations/DebugRelease.xcconfig:
2129
2130 2019-02-19  Yusuke Suzuki  <ysuzuki@apple.com>
2131
2132         [bmalloc] bmalloc::Heap is allocated even though we use system malloc mode
2133         https://bugs.webkit.org/show_bug.cgi?id=194836
2134
2135         Reviewed by Mark Lam.
2136
2137         Previously, bmalloc::Heap holds DebugHeap, and delegates allocation and deallocation to debug heap.
2138         However, bmalloc::Heap is large. We would like to avoid initialization of bmalloc::Heap under the
2139         system malloc mode.
2140
2141         This patch extracts out DebugHeap from bmalloc::Heap, and logically puts this in a boundary of
2142         bmalloc::api. bmalloc::api delegates allocation and deallocation to DebugHeap if DebugHeap is enabled.
2143         Otherwise, using bmalloc's usual mechanism. The challenge is that we would like to keep bmalloc fast
2144         path fast.
2145
2146         1. For IsoHeaps, we use the similar techniques done in Cache. If the debug mode is enabled, we always go
2147            to the slow path of the IsoHeap allocation, and keep IsoTLS::get() returning nullptr. In the slow path,
2148            we just fallback to the usual bmalloc::api::tryMalloc implementation. This is efficient because bmalloc
2149            continues using the fast path.
2150
2151         2. For the other APIs, like freeLargeVirtual, we just put DebugHeap check because this API itself takes fair
2152            amount of time. Then debug heap check does not matter.
2153
2154         * bmalloc/Allocator.cpp:
2155         (bmalloc::Allocator::reallocateImpl):
2156         * bmalloc/Cache.cpp:
2157         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2158         (bmalloc::Cache::allocateSlowCaseNullCache):
2159         (bmalloc::Cache::deallocateSlowCaseNullCache):
2160         (bmalloc::Cache::tryReallocateSlowCaseNullCache):
2161         (bmalloc::Cache::reallocateSlowCaseNullCache):
2162         (): Deleted.
2163         (bmalloc::debugHeap): Deleted.
2164         * bmalloc/DebugHeap.cpp:
2165         * bmalloc/DebugHeap.h:
2166         (bmalloc::DebugHeap::tryGet):
2167         * bmalloc/Heap.cpp:
2168         (bmalloc::Heap::Heap):
2169         (bmalloc::Heap::footprint):
2170         (bmalloc::Heap::tryAllocateLarge):
2171         (bmalloc::Heap::deallocateLarge):
2172         * bmalloc/Heap.h:
2173         (bmalloc::Heap::debugHeap): Deleted.
2174         * bmalloc/IsoTLS.cpp:
2175         (bmalloc::IsoTLS::IsoTLS):
2176         (bmalloc::IsoTLS::isUsingDebugHeap): Deleted.
2177         (bmalloc::IsoTLS::debugMalloc): Deleted.
2178         (bmalloc::IsoTLS::debugFree): Deleted.
2179         * bmalloc/IsoTLS.h:
2180         * bmalloc/IsoTLSInlines.h:
2181         (bmalloc::IsoTLS::allocateSlow):
2182         (bmalloc::IsoTLS::deallocateSlow):
2183         * bmalloc/ObjectType.cpp:
2184         (bmalloc::objectType):
2185         * bmalloc/ObjectType.h:
2186         * bmalloc/Scavenger.cpp:
2187         (bmalloc::Scavenger::Scavenger):
2188         * bmalloc/bmalloc.cpp:
2189         (bmalloc::api::tryLargeZeroedMemalignVirtual):
2190         (bmalloc::api::freeLargeVirtual):
2191         (bmalloc::api::scavenge):
2192         (bmalloc::api::isEnabled):
2193         (bmalloc::api::setScavengerThreadQOSClass):
2194         (bmalloc::api::commitAlignedPhysical):
2195         (bmalloc::api::decommitAlignedPhysical):
2196         (bmalloc::api::enableMiniMode):
2197
2198 2019-02-20  Andy Estes  <aestes@apple.com>
2199
2200         [Xcode] Add SDKVariant.xcconfig to various Xcode projects
2201         https://bugs.webkit.org/show_bug.cgi?id=194869
2202
2203         Rubber-stamped by Jer Noble.
2204
2205         * bmalloc.xcodeproj/project.pbxproj:
2206
2207 2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
2208
2209         [bmalloc] DebugHeap::malloc does not have "try" version.
2210         https://bugs.webkit.org/show_bug.cgi?id=194837
2211
2212         Reviewed by Mark Lam.
2213
2214         Since DebugHeap::malloc does not have "try" version, our tryAllocate implementation does not work well with DebugHeap.
2215         This patch adds crashOnFailure flag to DebugHeap::malloc.
2216
2217         * bmalloc/Cache.cpp:
2218         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2219         (bmalloc::Cache::allocateSlowCaseNullCache):
2220         * bmalloc/DebugHeap.cpp:
2221         (bmalloc::DebugHeap::malloc):
2222         * bmalloc/DebugHeap.h:
2223         * bmalloc/IsoTLS.cpp:
2224         (bmalloc::IsoTLS::debugMalloc):
2225
2226 2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
2227
2228         [bmalloc] bmalloc::Cache should not be instantiated if we are using system malloc
2229         https://bugs.webkit.org/show_bug.cgi?id=194811
2230
2231         Reviewed by Mark Lam.
2232
2233         bmalloc::Cache is very large. It is 13KB. Since it exists per HeapKind, it takes 40KB.
2234         But this is meaningless if we are under the system malloc mode by using "Malloc=1". We
2235         found that it continues using so much dirty memory region even under the system malloc mode.
2236         This patch avoids instantiation of bmalloc::Cache under the system malloc mode.
2237
2238         * bmalloc/Allocator.cpp:
2239         (bmalloc::Allocator::Allocator):
2240         (bmalloc::Allocator::tryAllocate):
2241         (bmalloc::Allocator::allocateImpl):
2242         (bmalloc::Allocator::reallocateImpl):
2243         (bmalloc::Allocator::allocateSlowCase):
2244         Allocator is a per Cache object. So we no longer need to keep m_debugHeap. If debug heap is enabled,
2245         Allocator is never created.
2246
2247         * bmalloc/Allocator.h:
2248         * bmalloc/Cache.cpp:
2249         (bmalloc::debugHeap):
2250         (bmalloc::Cache::Cache):
2251         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2252         (bmalloc::Cache::allocateSlowCaseNullCache):
2253         (bmalloc::Cache::deallocateSlowCaseNullCache):
2254         (bmalloc::Cache::tryReallocateSlowCaseNullCache):
2255         (bmalloc::Cache::reallocateSlowCaseNullCache):
2256         * bmalloc/Cache.h:
2257         (bmalloc::Cache::tryAllocate):
2258         (bmalloc::Cache::tryReallocate):
2259         If the debug heap mode is enabled, we keep Cache::getFast() returning nullptr. And in the slow path case, we use debugHeap.
2260         This makes bmalloc fast path fast, while we avoid Cache instantiation.
2261
2262         * bmalloc/Deallocator.cpp:
2263         (bmalloc::Deallocator::Deallocator):
2264         (bmalloc::Deallocator::scavenge):
2265         (bmalloc::Deallocator::deallocateSlowCase):
2266         * bmalloc/Deallocator.h:
2267         Ditto for Deallocator.
2268
2269         * bmalloc/bmalloc.cpp:
2270         (bmalloc::api::isEnabled):
2271         We used `getFastCase()` for Heap. But it is basically wrong since we do not have any guarantee that someone already initializes
2272         Heap when this is called. Previously, luckily, Cache is initialized, and Cache initialized Heap. But Cache initialization is removed
2273         for system malloc mode and now PerProcess<PerHeapKind<Heap>>::getFastCase() returns nullptr at an early phase. This patch just uses
2274         Environment::isDebugHeapEnabled() instead.
2275
2276 2019-02-20  Commit Queue  <commit-queue@webkit.org>
2277
2278         Unreviewed, rolling out r241789.
2279         https://bugs.webkit.org/show_bug.cgi?id=194856
2280
2281         GuardMalloc crashes (Requested by yusukesuzuki on #webkit).
2282
2283         Reverted changeset:
2284
2285         "[bmalloc] bmalloc::Cache should not be instantiated if we are
2286         using system malloc"
2287         https://bugs.webkit.org/show_bug.cgi?id=194811
2288         https://trac.webkit.org/changeset/241789
2289
2290 2019-02-19  Yusuke Suzuki  <ysuzuki@apple.com>
2291
2292         [bmalloc] bmalloc::Cache should not be instantiated if we are using system malloc
2293         https://bugs.webkit.org/show_bug.cgi?id=194811
2294
2295         Reviewed by Mark Lam.
2296
2297         bmalloc::Cache is very large. It is 13KB. Since it exists per HeapKind, it takes 40KB.
2298         But this is meaningless if we are under the system malloc mode by using "Malloc=1". We
2299         found that it continues using so much dirty memory region even under the system malloc mode.
2300         This patch avoids instantiation of bmalloc::Cache under the system malloc mode.
2301
2302         * bmalloc/Allocator.cpp:
2303         (bmalloc::Allocator::Allocator):
2304         (bmalloc::Allocator::tryAllocate):
2305         (bmalloc::Allocator::allocateImpl):
2306         (bmalloc::Allocator::reallocateImpl):
2307         (bmalloc::Allocator::allocateSlowCase):
2308         Allocator is a per Cache object. So we no longer need to keep m_debugHeap. If debug heap is enabled,
2309         Allocator is never created.
2310
2311         * bmalloc/Allocator.h:
2312         * bmalloc/Cache.cpp:
2313         (bmalloc::debugHeap):
2314         (bmalloc::Cache::Cache):
2315         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2316         (bmalloc::Cache::allocateSlowCaseNullCache):
2317         (bmalloc::Cache::deallocateSlowCaseNullCache):
2318         (bmalloc::Cache::tryReallocateSlowCaseNullCache):
2319         (bmalloc::Cache::reallocateSlowCaseNullCache):
2320         * bmalloc/Cache.h:
2321         (bmalloc::Cache::tryAllocate):
2322         (bmalloc::Cache::tryReallocate):
2323         If the debug heap mode is enabled, we keep Cache::getFast() returning nullptr. And in the slow path case, we use debugHeap.
2324         This makes bmalloc fast path fast, while we avoid Cache instantiation.
2325
2326         * bmalloc/Deallocator.cpp:
2327         (bmalloc::Deallocator::Deallocator):
2328         (bmalloc::Deallocator::scavenge):
2329         (bmalloc::Deallocator::deallocateSlowCase):
2330         * bmalloc/Deallocator.h:
2331         Ditto for Deallocator.
2332
2333 2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>
2334
2335         [bmalloc] NSBundle-based application name check should be executed after debug-heap environment variable check
2336         https://bugs.webkit.org/show_bug.cgi?id=194694
2337
2338         Reviewed by Mark Lam.
2339
2340         Interestingly, NSBundle allocates fair amount of memory and keeps it for a process-long time. For example, it
2341         allocates global NSConcreteHashTable, which takes 2.5KB. This patch changes the order of gigacage-check, we
2342         first check "Malloc=1" status, and then check the process name through NSBundle. This allows us to remove NSBundle
2343         related allocation in JSC initialization in the system malloc mode.
2344
2345         * bmalloc/Gigacage.cpp:
2346         (Gigacage::shouldBeEnabled):
2347
2348 2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>
2349
2350         [bmalloc] Do not start scavenger thread if we use system malloc
2351         https://bugs.webkit.org/show_bug.cgi?id=194674
2352
2353         Reviewed by Mark Lam.
2354
2355         We always start the scavenger thread even if system malloc is used by the environment variable like "Malloc=1".
2356         Because bmalloc allocation goes to the system malloc if "Malloc=1" is set, we do not need to scavenge. This patch
2357         changes it not to start the scavenger thread.
2358
2359         * bmalloc/Scavenger.cpp:
2360         (bmalloc::Scavenger::Scavenger):
2361
2362 2019-02-12  Commit Queue  <commit-queue@webkit.org>
2363
2364         Unreviewed, rolling out r241182.
2365         https://bugs.webkit.org/show_bug.cgi?id=194547
2366
2367         causes a 2-3% Speedometer2 regression. (Requested by
2368         keith_miller on #webkit).
2369
2370         Reverted changeset:
2371
2372         "bmalloc uses more memory on iOS compared to macOS due to
2373         physical page size differences"
2374         https://bugs.webkit.org/show_bug.cgi?id=192389
2375         https://trac.webkit.org/changeset/241182
2376
2377 2019-02-07  Michael Saboff  <msaboff@apple.com>
2378
2379         bmalloc uses more memory on iOS compared to macOS due to physical page size differences
2380         https://bugs.webkit.org/show_bug.cgi?id=192389
2381
2382         Reviewed by Geoffrey Garen.
2383
2384         Changed small line allocations to be in smallPageSize "virtual page" multiples instead of physical
2385         page size increments for sizes less that the physical page size.  This required changing the small
2386         page commit / decommit code to work in full physical page increments.  For page classes that are
2387         physical page size and larger, there isn't any functional change.
2388
2389         When scavenging page classes smaller than the physical page size, we need to consider whether or
2390         not the adjacent small pages on the same physical page are also free before decommiting that
2391         containing page.  When we need to commit more memory, we commit the whole page, and add any
2392         adjacent virtual pages that were fully committed as well.
2393
2394         * bmalloc/Chunk.h:
2395         (bmalloc::forEachPage):
2396         * bmalloc/Heap.cpp:
2397         (bmalloc::Heap::initializeLineMetadata):
2398         (bmalloc::Heap::initializePageMetadata):
2399         (bmalloc::Heap::scavenge):
2400         (bmalloc::__attribute__):
2401         (bmalloc::Heap::commitSmallPagesInPhysicalPage):
2402         (bmalloc::Heap::allocateSmallPage):
2403         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2404         * bmalloc/Heap.h:
2405         * bmalloc/SmallPage.h:
2406         (bmalloc::SmallPage::refCount):
2407
2408 2019-01-18  Keith Miller  <keith_miller@apple.com>
2409
2410         gigacage slide should randomize both start and end
2411         https://bugs.webkit.org/show_bug.cgi?id=193601
2412
2413         Reviewed by Yusuke Suzuki.
2414
2415         This patch makes it so that the gigacade slide has an arbitrary
2416         distance from the end as well as the start. This is done by
2417         picking a random size then based on that size picking an random
2418         starting offset.
2419
2420         * bmalloc/Gigacage.h:
2421         * bmalloc/Heap.cpp:
2422         (bmalloc::Heap::Heap):
2423
2424 2019-01-18  Jer Noble  <jer.noble@apple.com>
2425
2426         SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
2427         https://bugs.webkit.org/show_bug.cgi?id=189553
2428
2429         Reviewed by Tim Horton.
2430
2431         * Configurations/Base.xcconfig:
2432         * Configurations/SDKVariant.xcconfig: Added.
2433
2434 2019-01-18  Keith Miller  <keith_miller@apple.com>
2435
2436         Gigacages should start allocations from a slide
2437         https://bugs.webkit.org/show_bug.cgi?id=193523
2438
2439         Reviewed by Mark Lam.
2440
2441         This patch makes it so that Gigacage Heaps slide the start of the
2442         cage by some random amount. We still ensure that there is always
2443         at least 4/2GB, on MacOS/iOS respectively, of VA space available
2444         for allocation.
2445
2446         Also, this patch changes some macros into constants since macros
2447         are the devil.
2448
2449         * bmalloc/Gigacage.cpp:
2450         (Gigacage::bmalloc::protectGigacageBasePtrs):
2451         (Gigacage::bmalloc::unprotectGigacageBasePtrs):
2452         (Gigacage::bmalloc::runwaySize):
2453         (Gigacage::ensureGigacage):
2454         (Gigacage::shouldBeEnabled):
2455         * bmalloc/Gigacage.h:
2456         (Gigacage::name):
2457         (Gigacage::gigacageSizeToMask):
2458         (Gigacage::size):
2459         (Gigacage::mask):
2460         (Gigacage::basePtr):
2461         (Gigacage::ensureGigacage):
2462         (Gigacage::wasEnabled):
2463         (Gigacage::isCaged):
2464         (Gigacage::isEnabled):
2465         (Gigacage::caged):
2466         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2467         (Gigacage::canPrimitiveGigacageBeDisabled):
2468         (Gigacage::disablePrimitiveGigacage):
2469         (Gigacage::addPrimitiveDisableCallback):
2470         (Gigacage::removePrimitiveDisableCallback):
2471         * bmalloc/Heap.cpp:
2472         (bmalloc::Heap::Heap):
2473         * bmalloc/Sizes.h:
2474         (bmalloc::Sizes::maskSizeClass):
2475         (bmalloc::Sizes::maskObjectSize):
2476         (bmalloc::Sizes::logSizeClass):
2477         (bmalloc::Sizes::logObjectSize):
2478         (bmalloc::Sizes::sizeClass):
2479         (bmalloc::Sizes::objectSize):
2480         (bmalloc::Sizes::pageSize):
2481
2482 2019-01-18  Matt Lewis  <jlewis3@apple.com>
2483
2484         Unreviewed, rolling out r240160.
2485
2486         This broke multiple internal builds.
2487
2488         Reverted changeset:
2489
2490         "Gigacages should start allocations from a slide"
2491         https://bugs.webkit.org/show_bug.cgi?id=193523
2492         https://trac.webkit.org/changeset/240160
2493
2494 2019-01-18  Keith Miller  <keith_miller@apple.com>
2495
2496         Gigacages should start allocations from a slide
2497         https://bugs.webkit.org/show_bug.cgi?id=193523
2498
2499         Reviewed by Mark Lam.
2500
2501         This patch makes it so that Gigacage Heaps slide the start of the
2502         cage by some random amount. We still ensure that there is always
2503         at least 4/2GB, on MacOS/iOS respectively, of VA space available
2504         for allocation.
2505
2506         Also, this patch changes some macros into constants since macros
2507         are the devil.
2508
2509         * bmalloc/Gigacage.cpp:
2510         (Gigacage::bmalloc::protectGigacageBasePtrs):
2511         (Gigacage::bmalloc::unprotectGigacageBasePtrs):
2512         (Gigacage::bmalloc::runwaySize):
2513         (Gigacage::ensureGigacage):
2514         (Gigacage::shouldBeEnabled):
2515         * bmalloc/Gigacage.h:
2516         (Gigacage::name):
2517         (Gigacage::gigacageSizeToMask):
2518         (Gigacage::size):
2519         (Gigacage::mask):
2520         (Gigacage::basePtr):
2521         (Gigacage::ensureGigacage):
2522         (Gigacage::wasEnabled):
2523         (Gigacage::isCaged):
2524         (Gigacage::caged):
2525         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2526         (Gigacage::disablePrimitiveGigacage):
2527         (Gigacage::addPrimitiveDisableCallback):
2528         (Gigacage::removePrimitiveDisableCallback):
2529         * bmalloc/Heap.cpp:
2530         (bmalloc::Heap::Heap):
2531         * bmalloc/Sizes.h:
2532         (bmalloc::Sizes::maskSizeClass):
2533         (bmalloc::Sizes::maskObjectSize):
2534         (bmalloc::Sizes::logSizeClass):
2535         (bmalloc::Sizes::logObjectSize):
2536         (bmalloc::Sizes::sizeClass):
2537         (bmalloc::Sizes::objectSize):
2538         (bmalloc::Sizes::pageSize):
2539
2540 2019-01-17  Truitt Savell  <tsavell@apple.com>
2541
2542         Unreviewed, rolling out r240124.
2543
2544         This commit broke an internal build.
2545
2546         Reverted changeset:
2547
2548         "SDK_VARIANT build destinations should be separate from non-
2549         SDK_VARIANT builds"
2550         https://bugs.webkit.org/show_bug.cgi?id=189553
2551         https://trac.webkit.org/changeset/240124
2552
2553 2019-01-17  Jer Noble  <jer.noble@apple.com>
2554
2555         SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
2556         https://bugs.webkit.org/show_bug.cgi?id=189553
2557
2558         Reviewed by Tim Horton.
2559
2560         * Configurations/Base.xcconfig:
2561         * Configurations/SDKVariant.xcconfig: Added.
2562
2563 2019-01-16  Keith Miller  <keith_miller@apple.com>
2564
2565         bmalloc should use JSC VM tag for gigacage
2566         https://bugs.webkit.org/show_bug.cgi?id=193496
2567
2568         Reviewed by Mark Lam.
2569
2570         This patch moves the VMTag info from WTF to bmalloc so that we can
2571         tag gigacage memory with the unused JSC memory tag. The JSC memory
2572         tag was previously used for wasm but since wasm is now allocated
2573         out of the primitive cage it was unused.
2574
2575         * bmalloc.xcodeproj/project.pbxproj:
2576         * bmalloc/BVMTags.h: Copied from Source/WTF/wtf/VMTags.h.
2577         * bmalloc/Gigacage.cpp:
2578         (Gigacage::ensureGigacage):
2579         * bmalloc/VMAllocate.h:
2580         (bmalloc::tryVMAllocate):
2581         (bmalloc::vmZeroAndPurge):
2582
2583 2019-01-09  Mark Lam  <mark.lam@apple.com>
2584
2585         Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly.
2586         https://bugs.webkit.org/show_bug.cgi?id=193292
2587         <rdar://problem/46485450>
2588
2589         Reviewed by Yusuke Suzuki.
2590
2591         Previously, when GIGACAGE_ALLOCATION_CAN_FAIL is true, we allow the Gigacage to
2592         be disabled if we fail to allocate memory for it.  However, Gigacage::primitiveGigacageDisabled()
2593         still always assumes that the Gigacage is always enabled after ensureGigacage() is
2594         called.
2595
2596         This patch updates Gigacage::primitiveGigacageDisabled() to allow the Gigacage to
2597         already be disabled if GIGACAGE_ALLOCATION_CAN_FAIL is true and wasEnabled() is
2598         false.
2599
2600         In this patch, we also put the wasEnabled flag in the 0th slot of the
2601         g_gigacageBasePtrs buffer to ensure that it is also protected against writes just
2602         like the Gigacage base pointers.
2603
2604         To achieve this, we do the following:
2605         1. Added a reservedForFlags field in struct BasePtrs.
2606         2. Added a ReservedForFlagsAndNotABasePtr Gigacage::Kind.
2607         3. Added assertions to ensure that the BasePtrs::primitive is at the offset
2608            matching the offset computed from Gigacage::Primitive.  Ditto for
2609            BasePtrs::jsValue and Gigacage::JSValue.
2610         4. Added assertions to ensure that Gigacage::ReservedForFlagsAndNotABasePtr is not
2611            used for fetching a Gigacage base pointer.
2612         5. Added RELEASE_BASSERT_NOT_REACHED() to implement such assertions in bmalloc.
2613
2614         No test added because this issue requires Gigacage allocation to fail in order to
2615         manifest.  I've tested it manually by modifying the code locally to force an
2616         allocation failure.
2617
2618         * bmalloc/BAssert.h:
2619         * bmalloc/Gigacage.cpp:
2620         (Gigacage::ensureGigacage):
2621         (Gigacage::primitiveGigacageDisabled):
2622         * bmalloc/Gigacage.h:
2623         (Gigacage::wasEnabled):
2624         (Gigacage::setWasEnabled):
2625         (Gigacage::name):
2626         (Gigacage::basePtr):
2627         (Gigacage::size):
2628         * bmalloc/HeapKind.h:
2629         (bmalloc::heapKind):
2630
2631 2018-12-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>
2632
2633         Unreviewed, suppress warnings in Linux
2634
2635         * bmalloc/Gigacage.cpp:
2636
2637 2018-12-14  Keith Miller  <keith_miller@apple.com>
2638
2639         Gigacage runway should immediately follow the primitive cage
2640         https://bugs.webkit.org/show_bug.cgi?id=192733
2641
2642         Reviewed by Saam Barati.
2643
2644         This patch makes sure that the Gigacage runway is always
2645         immediately after the primitive cage. Since writing outside the
2646         primitive gigacage is likely to be more dangerous than the JSValue
2647         cage. The ordering of the cages is still random however.
2648
2649         * bmalloc/Gigacage.cpp:
2650         (Gigacage::ensureGigacage):
2651
2652 2018-12-13  Mark Lam  <mark.lam@apple.com>
2653
2654         Verify that tryLargeZeroedMemalignVirtual()'s aligned size and alignment values are valid.
2655         https://bugs.webkit.org/show_bug.cgi?id=192682
2656         <rdar://problem/37751522>
2657
2658         Reviewed by Saam Barati.
2659
2660         * bmalloc/bmalloc.cpp:
2661         (bmalloc::api::tryLargeZeroedMemalignVirtual):
2662
2663 2018-11-21  Dominik Infuehr  <dinfuehr@igalia.com>
2664
2665         Enable JIT on ARM/Linux
2666         https://bugs.webkit.org/show_bug.cgi?id=191548
2667
2668         Reviewed by Yusuke Suzuki.
2669
2670         * bmalloc/IsoPageInlines.h:
2671         (bmalloc::IsoPage<Config>::startAllocating):
2672
2673 2018-11-01  Jiewen Tan  <jiewen_tan@apple.com>
2674
2675         Replace CommonRandom SPI with API
2676         https://bugs.webkit.org/show_bug.cgi?id=191178
2677         <rdar://problem/45722391>
2678
2679         Reviewed by Brent Fulgham.
2680
2681         * bmalloc/CryptoRandom.cpp:
2682         (bmalloc::ARC4RandomNumberGenerator::stir):
2683
2684 2018-10-29  Mark Lam  <mark.lam@apple.com>
2685
2686         Correctly detect string overflow when using the 'Function' constructor.
2687         https://bugs.webkit.org/show_bug.cgi?id=184883
2688         <rdar://problem/36320331>
2689
2690         Reviewed by Saam Barati.
2691
2692         * bmalloc/Allocator.cpp:
2693         (bmalloc::Allocator::reallocate):
2694         (bmalloc::Allocator::tryReallocate):
2695         (bmalloc::Allocator::reallocateImpl):
2696         * bmalloc/Allocator.h:
2697         * bmalloc/Cache.h:
2698         (bmalloc::Cache::tryReallocate):
2699         * bmalloc/DebugHeap.cpp:
2700         (bmalloc::DebugHeap::realloc):
2701         * bmalloc/DebugHeap.h:
2702         * bmalloc/bmalloc.h:
2703         (bmalloc::api::tryRealloc):
2704
2705 2018-10-25  Ross Kirsling  <ross.kirsling@sony.com>
2706
2707         Cleanup: inline constexpr is redundant as constexpr implies inline
2708         https://bugs.webkit.org/show_bug.cgi?id=190819
2709
2710         Reviewed by Mark Lam.
2711
2712         * bmalloc/Algorithm.h:
2713         (bmalloc::max):
2714         (bmalloc::min):
2715         (bmalloc::mask):
2716         (bmalloc::test):
2717         (bmalloc::isPowerOfTwo):
2718         (bmalloc::roundDownToMultipleOf):
2719         (bmalloc::sizeOf):
2720         (bmalloc::bitCount):
2721         (bmalloc::log2):
2722         * bmalloc/Bits.h:
2723         (bmalloc::bitsArrayLength):
2724         * bmalloc/Sizes.h:
2725         (bmalloc::Sizes::maskSizeClass):
2726
2727 2018-10-24  Alexey Proskuryakov  <ap@apple.com>
2728
2729         Add BPLATFORM(IOS_FAMILY)
2730         https://bugs.webkit.org/show_bug.cgi?id=190878
2731
2732         Reviewed by Saam Barati.
2733
2734         * bmalloc/AvailableMemory.cpp:
2735         (bmalloc::memorySizeAccordingToKernel):
2736         (bmalloc::computeAvailableMemory):
2737         * bmalloc/AvailableMemory.h:
2738         (bmalloc::isUnderMemoryPressure):
2739         * bmalloc/BPlatform.h:
2740         * bmalloc/Gigacage.h:
2741         * bmalloc/Logging.cpp:
2742         (bmalloc::logVMFailure):
2743         * bmalloc/VMAllocate.h:
2744         (bmalloc::vmPageSizePhysical):
2745         * bmalloc/bmalloc.h:
2746         * bmalloc/darwin/MemoryStatusSPI.h:
2747
2748 2018-10-12  Ryan Haddad  <ryanhaddad@apple.com>
2749
2750         Unreviewed, rolling out r237063.
2751
2752         Caused layout test fast/dom/Window/window-postmessage-clone-
2753         deep-array.html to fail on macOS and iOS Debug bots.
2754
2755         Reverted changeset:
2756
2757         "[JSC] Remove gcc warnings on mips and armv7"
2758         https://bugs.webkit.org/show_bug.cgi?id=188598
2759         https://trac.webkit.org/changeset/237063
2760
2761 2018-10-11  Guillaume Emont  <guijemont@igalia.com>
2762
2763         [JSC] Remove gcc warnings on mips and armv7
2764         https://bugs.webkit.org/show_bug.cgi?id=188598
2765
2766         Reviewed by Mark Lam.
2767
2768         Add bitwise_cast (from WTF) and use it instead of reinterpret_cast in
2769         a couple places where reinterpret_cast triggers a warning about
2770         alignment even though we know that alignment is correct.
2771
2772         * bmalloc/Algorithm.h:
2773         (bmalloc::bitwise_cast): Copied from WTF/wtf/StdLibextras.h
2774         * bmalloc/IsoDirectoryPageInlines.h:
2775         (bmalloc::IsoDirectoryPage<Config>::pageFor):
2776         * bmalloc/IsoPageInlines.h:
2777         (bmalloc::IsoPage<Config>::startAllocating):
2778
2779 2018-10-03  Dan Bernstein  <mitz@apple.com>
2780
2781         bmalloc part of [Xcode] Update some build settings as recommended by Xcode 10
2782         https://bugs.webkit.org/show_bug.cgi?id=190250
2783
2784         Reviewed by Alex Christensen.
2785
2786         * Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS,
2787           and CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF.
2788
2789         * bmalloc.xcodeproj/project.pbxproj: Let Xcode update LastUpgradeCheck.
2790
2791 2018-09-25  Alex Christensen  <achristensen@webkit.org>
2792
2793         Allow for suffixes to com.apple.WebKit.WebContent
2794         https://bugs.webkit.org/show_bug.cgi?id=189972
2795
2796         Reviewed by Chris Dumez.
2797
2798         * bmalloc/ProcessCheck.mm:
2799         (bmalloc::gigacageEnabledForProcess):
2800
2801 2018-09-24  Fujii Hironori  <Hironori.Fujii@sony.com>
2802
2803         Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
2804         https://bugs.webkit.org/show_bug.cgi?id=189733
2805
2806         Reviewed by Michael Catanzaro.
2807
2808         * bmalloc/BCompiler.h:
2809
2810 2018-08-27  Keith Rollin  <krollin@apple.com>
2811
2812         Unreviewed build fix -- disable LTO for production builds
2813
2814         * Configurations/Base.xcconfig:
2815
2816 2018-08-27  Keith Rollin  <krollin@apple.com>
2817
2818         Build system support for LTO
2819         https://bugs.webkit.org/show_bug.cgi?id=187785
2820         <rdar://problem/42353132>
2821
2822         Reviewed by Dan Bernstein.
2823
2824         Update Base.xcconfig and DebugRelease.xcconfig to optionally enable
2825         LTO.
2826
2827         * Configurations/Base.xcconfig:
2828         * Configurations/DebugRelease.xcconfig:
2829
2830 2018-08-16  Tomas Popela  <tpopela@redhat.com>
2831
2832         bmalloc: Coverity scan issues
2833         https://bugs.webkit.org/show_bug.cgi?id=186763
2834
2835         Reviewed by Saam Barati.
2836
2837         * bmalloc/DebugHeap.h: Initialize the m_pageSize variable.
2838         * bmalloc/IsoTLS.cpp:
2839         (bmalloc::IsoTLS::ensureEntries): Check the return value of
2840         pthread_key_create return().
2841         * bmalloc/VMAllocate.h:
2842         (bmalloc::vmPageSize): Correctly check the return value of sysconf().
2843
2844 2018-07-27  Mark Lam  <mark.lam@apple.com>
2845
2846         Initialize bmalloc::DebugHeap::m_pageSize for non-Darwin builds.
2847         https://bugs.webkit.org/show_bug.cgi?id=188132
2848         <rdar://problem/40401599>
2849
2850         Reviewed by Saam Barati.
2851
2852         * bmalloc/DebugHeap.cpp:
2853         (bmalloc::DebugHeap::DebugHeap):
2854
2855 2018-07-27  Saam Barati  <sbarati@apple.com>
2856
2857         Explicitly handle memlimit_active < 0
2858         https://bugs.webkit.org/show_bug.cgi?id=188125
2859
2860         Reviewed by Mark Lam.
2861
2862         This may come up during development when someone wants the limit
2863         to be "infinite".
2864
2865         * bmalloc/AvailableMemory.cpp:
2866         (bmalloc::jetsamLimit):
2867
2868 2018-07-27  Saam Barati  <sbarati@apple.com>
2869
2870         Use SPI to compute the jetsam limit on iOS instead of hardcoding 840MB
2871         https://bugs.webkit.org/show_bug.cgi?id=188091
2872         <rdar://problem/42647697>
2873
2874         Reviewed by Simon Fraser.
2875
2876         We want bmalloc to dynamically adapt to the jetsam limit of the process
2877         it's running in. WTF::ramSize() is based off bmalloc's availableMemory,
2878         so it will now reflect the result of the real jetsam limit when we can
2879         read it.
2880         
2881         Reading the jetsam limit requires an entitlement, so this patch opts in
2882         the WebContent/Storage/Network processes. We fall back to 840MB (the
2883         old hard coded value) when the SPI call fails (e.g, when we're in a
2884         process without the proper entitlement).
2885
2886         * bmalloc.xcodeproj/project.pbxproj:
2887         * bmalloc/AvailableMemory.cpp:
2888         (bmalloc::jetsamLimit):
2889         (bmalloc::computeAvailableMemory):
2890         * bmalloc/darwin/MemoryStatusSPI.h: Added.
2891
2892 2018-07-24  Saam Barati  <sbarati@apple.com>
2893
2894         Revert back to using phys_footprint to calculate isUnderMemoryPressure()
2895         https://bugs.webkit.org/show_bug.cgi?id=187919
2896         <rdar://problem/42552888>
2897
2898         Reviewed by Simon Fraser.
2899
2900         Currently on iOS, bmalloc will run the scavenger more frequently when it detects
2901         that the process is under memory pressure. However, it only uses bmalloc's
2902         own footprint as a percentage of the HW available memory to determine if
2903         the process is under memory pressure. This is a change I recently made
2904         in an effort to run the scavenger less when bmalloc wasn't contributing
2905         to the dirty footprint in the process. However, this fails to run the
2906         scavenger eagerly when the process in question has a heap split
2907         between a lot of dirty bmalloc memory as well as a lot of dirty memory
2908         from elsewhere. We also have evidence that we may have increased jetsams
2909         in the Web Content process. Since my original change was not a measurable
2910         speedup, this patch reverts isUnderMemoryPressure() to its previous
2911         behavior of using phys_footprint to determine if 75% of the available 
2912         HW memory is being used.
2913
2914         * bmalloc/AvailableMemory.cpp:
2915         (bmalloc::memoryStatus):
2916
2917 2019-07-12  Michael Saboff  <msaboff@apple.com>
2918
2919         Disable IsoHeaps when Gigacage is off
2920         https://bugs.webkit.org/show_bug.cgi?id=187160
2921
2922         Reviewed by Saam Barati.
2923
2924         Relanding change sets 233547 and 233550 with the added fix that Gigacage is also
2925         enabled for DumpRenderTree.
2926
2927         Updated determineMallocFallbackState to base enabling of Iso Heaps on Gigacage 
2928         being enabled.  We do this because if Gigacage is disabled, it may be due to lack
2929         of address space.
2930
2931         To work around a compiler issue uncovered by the change above, I added explicit
2932         instantiation of PerThread's static variables.  Defined the same explicit
2933         instantiated static variables with export scope in the new file PerThread.cpp
2934         to eliminate separate variables allocations in each linked framework / library.
2935
2936         * CMakeLists.txt:
2937         * bmalloc.xcodeproj/project.pbxproj:
2938         * bmalloc/IsoTLS.cpp:
2939         (bmalloc::IsoTLS::determineMallocFallbackState):
2940         * bmalloc/PerThread.cpp: Added.
2941         * bmalloc/PerThread.h:
2942         * bmalloc/ProcessCheck.mm:
2943         (bmalloc::gigacageEnabledForProcess):
2944
2945 2018-07-09  Commit Queue  <commit-queue@webkit.org>
2946
2947         Unreviewed, rolling out r233547 and r233550.
2948         https://bugs.webkit.org/show_bug.cgi?id=187497
2949
2950         Introduced flakiness for media/fullscreen-* tests on mac-wk1
2951         (Requested by ryanhaddad on #webkit).
2952
2953         Reverted changesets:
2954
2955         "Disable IsoHeaps when Gigacage is off"
2956         https://bugs.webkit.org/show_bug.cgi?id=187160
2957         https://trac.webkit.org/changeset/233547
2958
2959         "Build fix (r233547): Disable IsoHeaps when Gigacage is off"
2960         https://bugs.webkit.org/show_bug.cgi?id=187160
2961         https://trac.webkit.org/changeset/233550
2962
2963 2018-07-05  David Kilzer  <ddkilzer@apple.com>
2964
2965         Build fix (r233547): Disable IsoHeaps when Gigacage is off
2966         <https://webkit.org/b/187160>
2967
2968         * bmalloc/PerThread.cpp: Add #if !HAVE_PTHREAD_MACHDEP_H/#endif
2969         around variables only used when that macro is 0.  Include what
2970         you use: Cache.h and Heap.h.
2971         * bmalloc/PerThread.h: Include <memory> for std::once_flag.
2972
2973 2018-07-05  Michael Saboff  <msaboff@apple.com>
2974
2975         Disable IsoHeaps when Gigacage is off
2976         https://bugs.webkit.org/show_bug.cgi?id=187160
2977
2978         Reviewed by Saam Barati.
2979
2980         Updated determineMallocFallbackState to base enabling of Iso Heaps on Gigacage 
2981         being enabled.  We do this because if Gigacage is disabled, it may be due to lack
2982         of address space.
2983
2984         To work around a compiler issue uncovered by the change above, I added explicit
2985         instantiation of PerThread's static variables.  Defined the same explicit
2986         instantiated static variables with export scope in the new file PerThread.cpp
2987         to eliminate separate variables allocations in each linked framework / library.
2988
2989         * CMakeLists.txt:
2990         * bmalloc.xcodeproj/project.pbxproj:
2991         * bmalloc/IsoTLS.cpp:
2992         (bmalloc::IsoTLS::determineMallocFallbackState):
2993         * bmalloc/PerThread.cpp: Added.
2994         * bmalloc/PerThread.h:
2995
2996 2018-07-04  Tim Horton  <timothy_horton@apple.com>
2997
2998         Introduce PLATFORM(IOSMAC)
2999         https://bugs.webkit.org/show_bug.cgi?id=187315
3000
3001         Reviewed by Dan Bernstein.
3002
3003         * Configurations/Base.xcconfig:
3004
3005 2018-06-29  Ryan Haddad  <ryanhaddad@apple.com>
3006
3007         Unreviewed, rolling out r233347.
3008
3009         Causes crashes during WK1 tests.
3010
3011         Reverted changeset:
3012
3013         "Disable IsoHeaps when Gigacage is off"
3014         https://bugs.webkit.org/show_bug.cgi?id=187160
3015         https://trac.webkit.org/changeset/233347
3016
3017 2018-06-28  Michael Saboff  <msaboff@apple.com>
3018
3019         Disable IsoHeaps when Gigacage is off
3020         https://bugs.webkit.org/show_bug.cgi?id=187160
3021
3022         Reviewed by Saam Barati.
3023
3024         If Gigacage is disabled, it may be due to lack of address space.
3025         Therefore we should also turn off IsoHeaps since it uses more virtual
3026         address space as well.
3027
3028         * bmalloc/IsoTLS.cpp:
3029         (bmalloc::IsoTLS::determineMallocFallbackState):
3030
3031 2018-06-27  Simon Fraser  <simon.fraser@apple.com>
3032
3033         https://hackernoon.com/ uses lots of layer backing store
3034         https://bugs.webkit.org/show_bug.cgi?id=186909
3035         rdar://problem/40257540
3036
3037         Reviewed by Tim Horton.
3038         
3039         Drive-by typo fix.
3040
3041         * bmalloc/Scavenger.cpp:
3042         (bmalloc::dumpStats):
3043
3044 2018-06-26  Saam Barati  <sbarati@apple.com>
3045
3046         Unreviewed followup. Fix the watchos build after r233192.
3047
3048         This patch also correct the changelog entry below to have the correct
3049         bug and title info.
3050
3051         * bmalloc/ProcessCheck.mm:
3052
3053 2018-06-26  Saam Barati  <sbarati@apple.com>
3054
3055         Switch to system malloc on iOS when nano malloc is disabled
3056         https://bugs.webkit.org/show_bug.cgi?id=186322
3057         <rdar://problem/41140257>
3058
3059         Reviewed by Keith Miller.
3060
3061         We have evidence showing that processes with small heaps using the
3062         JS API are more space efficient when using system malloc. Our main
3063         hypothesis as to why this is, is that when dealing with small heaps,
3064         one malloc can be more efficient at optimizing memory usage than
3065         two mallocs.
3066
3067         * bmalloc/BPlatform.h:
3068         * bmalloc/Environment.cpp:
3069         (bmalloc::isNanoMallocEnabled):
3070         (bmalloc::Environment::computeIsDebugHeapEnabled):
3071         * bmalloc/ProcessCheck.h:
3072         (bmalloc::shouldProcessUnconditionallyUseBmalloc):
3073         * bmalloc/ProcessCheck.mm:
3074         (bmalloc::shouldProcessUnconditionallyUseBmalloc):
3075
3076 2018-06-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3077
3078         [bmalloc][Linux] Remove static initializers for PerProcess<>::s_object
3079         https://bugs.webkit.org/show_bug.cgi?id=186966
3080
3081         Reviewed by Anders Carlsson.
3082
3083         chrome/tools/linux/dump-static-initializers.py can dump static initializers
3084         in the binary and we found that PerProcess<>::s_object initialization is done
3085         by static initializers in GCC + Linux environments. The example is the following.
3086
3087         Scavenger.cpp (initializer offset 0x38c210 size 0x3e)
3088             _GLOBAL__sub_I_Scavenger.cpp+0x1e
3089             _GLOBAL__sub_I_Scavenger.cpp+0x2d
3090             _GLOBAL__sub_I_Scavenger.cpp+0x3c
3091             _GLOBAL__sub_I_Scavenger.cpp+0xf
3092             guard variable for bmalloc::PerProcess<bmalloc::AllIsoHeaps>::s_object@@Base-0x3f0d8
3093             guard variable for bmalloc::PerProcess<bmalloc::Environment>::s_object@@Base-0x3f0e8
3094             guard variable for bmalloc::PerProcess<bmalloc::PerHeapKind<bmalloc::Heap> >::s_object@@Base-0x3c600
3095             guard variable for bmalloc::PerProcess<bmalloc::Scavenger>::s_object@@Base-0x38ce8
3096
3097         We can remove this by initializing `nullptr`, which leads to constexpr initialization.
3098         After this change, Linux JSCOnly libJavaScriptCore.so has no static initializers.
3099
3100         * bmalloc/PerProcess.h:
3101
3102 2018-06-09  Dan Bernstein  <mitz@apple.com>
3103
3104         [Xcode] Clean up and modernize some build setting definitions
3105         https://bugs.webkit.org/show_bug.cgi?id=186463
3106
3107         Reviewed by Sam Weinig.
3108
3109         * Configurations/Base.xcconfig: Removed definition for macOS 10.11.
3110         * Configurations/DebugRelease.xcconfig: Ditto.
3111
3112 2018-06-07  Darin Adler  <darin@apple.com>
3113
3114         [Cocoa] Turn on ARC for the single Objective-C++ source file in bmalloc
3115         https://bugs.webkit.org/show_bug.cgi?id=186398
3116
3117         Reviewed by Saam Barati.
3118
3119         * Configurations/Base.xcconfig: Turn on ARC.
3120         * bmalloc/ProcessCheck.mm:
3121         (bmalloc::gigacageEnabledForProcess): Removed the globals from this function,
3122         since it's only called once. If it was called more than once, we could optimize
3123         that with a single boolean global rather than two strings and two booleans.
3124
3125 2018-06-07  David Kilzer  <ddkilzer@apple.com>
3126
3127         bmalloc: Fix 'noreturn' warnings when compiling with -std=gnu++17
3128         <https://webkit.org/b/186400>
3129
3130         Reviewed by Saam Barati.
3131
3132         Fixes the following warnings when compiling with gnu++17:
3133
3134             Source/bmalloc/bmalloc/Scavenger.cpp:363:1: error: function 'threadRunLoop' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
3135             {
3136             ^
3137             Source/bmalloc/bmalloc/Scavenger.cpp:358:1: error: function 'threadEntryPoint' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
3138             {
3139             ^
3140
3141         * bmalloc/BCompiler.h:
3142         (BCOMPILER): Add support for the BCOMPILER() macro, then add
3143         BCOMPILER(GCC_OR_CLANG).  Taken from Source/WTF/wtf/Compiler.h.
3144         (BNO_RETURN): Implement 'norerturn' support using the new
3145         BCOMPILER() macros.  Taken from Source/WTF/wtf/Compiler.h.
3146         * bmalloc/Scavenger.cpp:
3147         (bmalloc::Scavenger::threadRunLoop): Remove the workaround that
3148         tricked older compilers into thinking the while() loop wasn't
3149         infinite.
3150         * bmalloc/Scavenger.h:
3151         (bmalloc::Scavenger::threadEntryPoint): Add BNO_RETURN attribute.
3152         (bmalloc::Scavenger::threadRunLoop): Ditto.
3153
3154 2018-05-29  Saam Barati  <sbarati@apple.com>
3155
3156         JSC should put bmalloc's scavenger into mini mode
3157         https://bugs.webkit.org/show_bug.cgi?id=185988
3158
3159         Reviewed by Michael Saboff.
3160
3161         We expose an API for putting bmalloc into mini mode. All that means now
3162         is that we'll run the scavenger more aggressively.
3163
3164         * bmalloc/Scavenger.cpp:
3165         (bmalloc::Scavenger::enableMiniMode):
3166         (bmalloc::Scavenger::threadRunLoop):
3167         * bmalloc/Scavenger.h:
3168         * bmalloc/Sizes.h:
3169         * bmalloc/bmalloc.cpp:
3170         (bmalloc::api::enableMiniMode):
3171         * bmalloc/bmalloc.h:
3172
3173 2018-05-29  Geoffrey Garen  <ggaren@apple.com>
3174
3175         Fixed the bmalloc build
3176         https://bugs.webkit.org/show_bug.cgi?id=186025
3177
3178         Reviewed by Sam Weinig.
3179
3180         * bmalloc.xcodeproj/project.pbxproj: Link Foundation because the 
3181         gigacage check needs it.
3182
3183 2018-05-23  Antti Koivisto  <antti@apple.com>
3184
3185         Increase the simulated memory size on PLATFORM(IOS_SIMULATOR) from 512MB to 1024MB
3186         https://bugs.webkit.org/show_bug.cgi?id=185908
3187
3188         Reviewed by Geoffrey Garen.
3189
3190         We don't support 512MB devices anymore. This will make the simulator behave more
3191         like a real device.
3192
3193         * bmalloc/AvailableMemory.cpp:
3194         (bmalloc::memorySizeAccordingToKernel):
3195
3196         Factor to a function.
3197         Don't use availableMemoryGuess for the simulator value as it is not a guess.
3198
3199         (bmalloc::computeAvailableMemory):
3200
3201         Apply the same adjustments to the simulated value too.
3202
3203 2018-05-22  Ryan Haddad  <ryanhaddad@apple.com>
3204
3205         Unreviewed, rolling out r232052.
3206
3207         Breaks internal builds.
3208
3209         Reverted changeset:
3210
3211         "Use more C++17"
3212         https://bugs.webkit.org/show_bug.cgi?id=185176
3213         https://trac.webkit.org/changeset/232052
3214
3215 2018-05-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3216
3217         Define GIGACAGE_ALLOCATION_CAN_FAIL on Linux
3218         https://bugs.webkit.org/show_bug.cgi?id=183329
3219
3220         Reviewed by Michael Catanzaro.
3221
3222         We specify `GIGACAGE_ALLOCATION_CAN_FAIL 1` in Linux since
3223         Linux can fail to `mmap` if `vm.overcommit_memory = 2`.
3224         Users can enable Gigacage if users enable overcommit_memory.
3225
3226         * bmalloc/Gigacage.h:
3227
3228 2018-05-21  Yusuke Suzuki  <utatane.tea@gmail.com>
3229
3230         Use more C++17
3231         https://bugs.webkit.org/show_bug.cgi?id=185176
3232
3233         Reviewed by JF Bastien.
3234
3235         Add BNO_RETURN.
3236
3237         * Configurations/Base.xcconfig:
3238         * bmalloc/BCompiler.h:
3239         * bmalloc/Scavenger.h:
3240
3241 2018-05-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3242
3243         [JSC] Remove "using namespace std;" from JSC, bmalloc, WTF
3244         https://bugs.webkit.org/show_bug.cgi?id=185362
3245
3246         Reviewed by Sam Weinig.
3247
3248         * bmalloc/Allocator.cpp:
3249         * bmalloc/Deallocator.cpp:
3250
3251 2018-05-03  Filip Pizlo  <fpizlo@apple.com>
3252
3253         Strings should not be allocated in a gigacage
3254         https://bugs.webkit.org/show_bug.cgi?id=185218
3255
3256         Reviewed by Saam Barati.
3257         
3258         This removes the string gigacage.
3259         
3260         Putting strings in a gigacage prevents read gadgets. The other things that get to be in gigacages
3261         are there to prevent read-write gadgets.
3262         
3263         Also, putting strings in a gigacage seems to have been a bigger regression than putting other
3264         things in gigacages.
3265         
3266         Therefore, to maximize the benefit/cost ratio of gigacages, we should evict strings from them. If
3267         we want to throw away perf for security, there are more beneficial things to sacrifice.
3268
3269         * bmalloc/Gigacage.h:
3270         (Gigacage::name):
3271         (Gigacage::basePtr):
3272         (Gigacage::size):
3273         (Gigacage::forEachKind):
3274         * bmalloc/HeapKind.h:
3275         (bmalloc::isGigacage):
3276         (bmalloc::gigacageKind):
3277         (bmalloc::heapKind):
3278         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
3279         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
3280
3281 2018-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3282
3283         Use WordLock instead of std::mutex for Threading
3284         https://bugs.webkit.org/show_bug.cgi?id=185121
3285
3286         Reviewed by Geoffrey Garen.
3287
3288         Add constexpr to explicitly describe that bmalloc::Mutex constructor is constexpr.
3289
3290         * bmalloc/Mutex.h:
3291
3292 2018-04-23  Ting-Wei Lan  <lantw44@gmail.com>
3293
3294         Include stdio.h before using stderr
3295         https://bugs.webkit.org/show_bug.cgi?id=184872
3296
3297         Reviewed by Yusuke Suzuki.
3298
3299         * bmalloc/PerProcess.cpp:
3300         * bmalloc/Scavenger.cpp:
3301
3302 2018-04-21  Yusuke Suzuki  <utatane.tea@gmail.com>
3303
3304         Unreviewed, follow-up patch after r230474
3305         https://bugs.webkit.org/show_bug.cgi?id=166684
3306
3307         Add "JavaScriptCore" to Darwin name. And use short name "BMScavenger"
3308         for Linux since adding "JavaScriptCore" makes the name too long for Linux.
3309
3310         * bmalloc/Scavenger.cpp:
3311         (bmalloc::Scavenger::threadRunLoop):
3312
3313 2018-04-18  Jer Noble  <jer.noble@apple.com>
3314
3315         Don't put build products into WK_ALTERNATE_WEBKIT_SDK_PATH for engineering builds
3316         https://bugs.webkit.org/show_bug.cgi?id=184762
3317
3318         Reviewed by Dan Bernstein.
3319
3320         * Configurations/Base.xcconfig:
3321
3322 2018-04-20  Daniel Bates  <dabates@apple.com>
3323
3324         Remove code for compilers that did not support NSDMI for aggregates
3325         https://bugs.webkit.org/show_bug.cgi?id=184599
3326
3327         Reviewed by Per Arne Vollan.
3328
3329         Remove workaround for earlier Visual Studio versions that did not support non-static data
3330         member initializers (NSDMI) for aggregates. We have since updated all the build.webkit.org
3331         and EWS bots to a newer version that supports this feature.
3332
3333         * bmalloc/BPlatform.h:
3334         * bmalloc/List.h:
3335         (bmalloc::ListNode::ListNode): Deleted.
3336         (bmalloc::List::iterator::iterator): Deleted.
3337
3338 2018-04-19  David Kilzer  <ddkilzer@apple.com>
3339
3340         Enable Objective-C weak references
3341         <https://webkit.org/b/184789>
3342         <rdar://problem/39571716>
3343
3344         Reviewed by Dan Bernstein.
3345
3346         * Configurations/Base.xcconfig:
3347         (CLANG_ENABLE_OBJC_WEAK): Enable.
3348
3349 2018-04-12  Saam Barati  <sbarati@apple.com>
3350
3351         Lessen partial scavenge interval on x86-64
3352         https://bugs.webkit.org/show_bug.cgi?id=184577
3353
3354         Rubber-stamped by Filip Pizlo.
3355
3356         I initially made the scavenge interval longer because I had thought the
3357         shorter interval caused a JetStream regression. I was mistaken though.
3358         I was looking at the wrong commit range when analyzing perf data.
3359         
3360         This patch shortens the interval, but still keeps x86-64 50% longer than
3361         other architectures. We know that scavenging frequently on Mac is less
3362         important to overall system performance than it is on iOS.
3363
3364         * bmalloc/Scavenger.cpp:
3365         (bmalloc::Scavenger::threadRunLoop):
3366
3367 2018-04-12  Saam Barati  <sbarati@apple.com>
3368
3369         Raise the partial scavenge interval even more on x86-64
3370         https://bugs.webkit.org/show_bug.cgi?id=184551
3371
3372         Rubber-stamped by Filip Pizlo.
3373
3374         The JetStream regression didn't recover from my previous patch.
3375         This is another attempt to get it to recover perf.
3376
3377         * bmalloc/Scavenger.cpp:
3378         (bmalloc::Scavenger::threadRunLoop):
3379
3380 2018-04-11  Saam Barati  <sbarati@apple.com>
3381
3382         raise partial scavenge interval on x86-64
3383         https://bugs.webkit.org/show_bug.cgi?id=184521
3384
3385         Rubber-stamped by Filip Pizlo.
3386
3387         This patch is an attempt to recover the 1-3% JetStream regression
3388         my initial partial scavenging patch introduced on some Macs.
3389
3390         * bmalloc/Scavenger.cpp:
3391         (bmalloc::Scavenger::threadRunLoop):
3392
3393 2018-04-10  Saam Barati  <sbarati@apple.com>
3394
3395         IsoHeapImpl::scavenge* needs to grab the lock
3396         https://bugs.webkit.org/show_bug.cgi?id=184461
3397
3398         Reviewed by Filip Pizlo.
3399
3400         Another thread could be modifying the linked list that the scavenge* methods traverse.
3401
3402         * bmalloc/IsoHeapImplInlines.h:
3403         (bmalloc::IsoHeapImpl<Config>::scavenge):
3404         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
3405
3406 2018-04-10  Saam Barati  <sbarati@apple.com>
3407
3408         bmalloc should do partial scavenges more frequently
3409         https://bugs.webkit.org/show_bug.cgi?id=184176
3410
3411         Reviewed by Filip Pizlo.
3412
3413         This patch adds the ability for bmalloc to do a partial scavenge.
3414         bmalloc will now do a partial scavenge with some frequency even
3415         when the heap is growing.
3416         
3417         For Heap, this means tracking the high water mark of where the Heap
3418         has allocated since the last scavenge. Partial scavenging is just
3419         decommitting entries in the LargeMap that are past this high water
3420         mark. Because we allocate in first fit order out of LargeMap, tracking
3421         the high water mark is a good heuristic of how much memory a partial
3422         scavenge should decommit.
3423         
3424         For IsoHeaps, each IsoDirectory also keeps track of its high water mark
3425         for the furthest page it allocates into. Similar to Heap, we scavenge pages
3426         past that high water mark. IsoHeapImpl then tracks the high water mark
3427         for the IsoDirectory it allocates into. We then scavenge all directories 
3428         including and past the directory high water mark. This includes scavenging
3429         the inline directory when its the only thing we allocate out of since
3430         the last scavenge.
3431         
3432         This patch also adds some other capabilities to bmalloc:
3433         
3434         Heaps and IsoHeaps now track how much memory is freeable. Querying
3435         this number is now cheap.
3436         
3437         Heaps no longer hold the global lock when decommitting large ranges.
3438         Instead, that range is just marked as non eligible to be allocated.
3439         Then, without the lock held, the scavenger will decommit those ranges.
3440         Once this is done, the scavenger will then reacquire the lock and mark
3441         these ranges as eligible. This lessens lock contention between the
3442         scavenger and the allocation slow path since threads that are taking an
3443         allocation slow path can now allocate concurrently to the scavenger's
3444         decommits. The main consideration in adding this functionality is that
3445         a large allocation may fail while the scavenger is in the process of
3446         decommitting memory. When the Heap fails to allocate a large range when
3447         the scavenger is in the middle of a decommit, Heap will wait for the
3448         Scavenger to finish and then it will try to allocate a large range again.
3449         
3450         Decommitting from Heap now aggregates the ranges to decommit and tries to
3451         merge them together to lower the number of calls to vmDeallocatePhysicalPages.
3452         This is analogous to what IsoHeaps already do.
3453
3454         * bmalloc.xcodeproj/project.pbxproj:
3455         * bmalloc/Allocator.cpp:
3456         (bmalloc::Allocator::tryAllocate):
3457         (bmalloc::Allocator::allocateImpl):
3458         (bmalloc::Allocator::reallocate):
3459         (bmalloc::Allocator::refillAllocatorSlowCase):
3460         (bmalloc::Allocator::allocateLarge):
3461         * bmalloc/BulkDecommit.h: Added.
3462         (bmalloc::BulkDecommit::addEager):
3463         (bmalloc::BulkDecommit::addLazy):
3464         (bmalloc::BulkDecommit::processEager):
3465         (bmalloc::BulkDecommit::processLazy):
3466         (bmalloc::BulkDecommit::add):
3467         (bmalloc::BulkDecommit::process):
3468         * bmalloc/Deallocator.cpp:
3469         (bmalloc::Deallocator::scavenge):
3470         (bmalloc::Deallocator::processObjectLog):
3471         (bmalloc::Deallocator::deallocateSlowCase):
3472         * bmalloc/Deallocator.h:
3473         (bmalloc::Deallocator::lineCache):
3474         * bmalloc/Heap.cpp:
3475         (bmalloc::Heap::freeableMemory):
3476         (bmalloc::Heap::markAllLargeAsEligibile):
3477         (bmalloc::Heap::decommitLargeRange):
3478         (bmalloc::Heap::scavenge):
3479         (bmalloc::Heap::scavengeToHighWatermark):
3480         (bmalloc::Heap::deallocateLineCache):
3481         (bmalloc::Heap::allocateSmallChunk):
3482         (bmalloc::Heap::deallocateSmallChunk):
3483         (bmalloc::Heap::allocateSmallPage):
3484         (bmalloc::Heap::deallocateSmallLine):
3485         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
3486         (bmalloc::Heap::allocateSmallBumpRangesByObject):
3487         (bmalloc::Heap::splitAndAllocate):
3488         (bmalloc::Heap::tryAllocateLarge):
3489         (bmalloc::Heap::allocateLarge):
3490         (bmalloc::Heap::isLarge):
3491         (bmalloc::Heap::largeSize):
3492         (bmalloc::Heap::shrinkLarge):
3493         (bmalloc::Heap::deallocateLarge):
3494         (bmalloc::Heap::externalCommit):
3495         (bmalloc::Heap::externalDecommit):
3496         * bmalloc/Heap.h:
3497         (bmalloc::Heap::allocateSmallBumpRanges):
3498         (bmalloc::Heap::derefSmallLine):
3499         * bmalloc/IsoDirectory.h:
3500         * bmalloc/IsoDirectoryInlines.h:
3501         (bmalloc::passedNumPages>::takeFirstEligible):
3502         (bmalloc::passedNumPages>::didBecome):
3503         (bmalloc::passedNumPages>::didDecommit):
3504         (bmalloc::passedNumPages>::scavengePage):
3505         (bmalloc::passedNumPages>::scavenge):
3506         (bmalloc::passedNumPages>::scavengeToHighWatermark):
3507         (bmalloc::passedNumPages>::freeableMemory): Deleted.
3508         * bmalloc/IsoHeapImpl.h:
3509         * bmalloc/IsoHeapImplInlines.h:
3510         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
3511         (bmalloc::IsoHeapImpl<Config>::scavenge):
3512         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
3513         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
3514         (bmalloc::IsoHeapImpl<Config>::isNowFreeable):
3515         (bmalloc::IsoHeapImpl<Config>::isNoLongerFreeable):
3516         * bmalloc/LargeMap.cpp:
3517         (bmalloc::LargeMap::remove):
3518         (bmalloc::LargeMap::markAllAsEligibile):
3519         * bmalloc/LargeMap.h:
3520         (bmalloc::LargeMap::size):
3521         (bmalloc::LargeMap::at):
3522         * bmalloc/LargeRange.h:
3523         (bmalloc::LargeRange::setEligible):
3524         (bmalloc::LargeRange::isEligibile const):
3525         (bmalloc::canMerge):
3526         * bmalloc/ObjectType.cpp:
3527         (bmalloc::objectType):
3528         * bmalloc/Scavenger.cpp:
3529         (bmalloc::PrintTime::PrintTime):
3530         (bmalloc::PrintTime::~PrintTime):
3531         (bmalloc::PrintTime::print):
3532         (bmalloc::Scavenger::timeSinceLastFullScavenge):
3533         (bmalloc::Scavenger::timeSinceLastPartialScavenge):
3534         (bmalloc::Scavenger::scavenge):
3535         (bmalloc::Scavenger::partialScavenge):
3536         (bmalloc::Scavenger::freeableMemory):
3537         (bmalloc::Scavenger::threadRunLoop):
3538         * bmalloc/Scavenger.h:
3539         * bmalloc/SmallLine.h:
3540         (bmalloc::SmallLine::refCount):
3541         (bmalloc::SmallLine::ref):
3542         (bmalloc::SmallLine::deref):
3543         * bmalloc/SmallPage.h:
3544         (bmalloc::SmallPage::refCount):
3545         (bmalloc::SmallPage::hasFreeLines const):
3546         (bmalloc::SmallPage::setHasFreeLines):
3547         (bmalloc::SmallPage::ref):
3548         (bmalloc::SmallPage::deref):
3549         * bmalloc/bmalloc.cpp:
3550         (bmalloc::api::tryLargeZeroedMemalignVirtual):
3551         (bmalloc::api::freeLargeVirtual):
3552
3553 2018-04-09  Yusuke Suzuki  <utatane.tea@gmail.com>
3554
3555         [bmalloc] Name Scavenger thread "bmalloc scavenger"
3556         https://bugs.webkit.org/show_bug.cgi?id=166684
3557
3558         Reviewed by Saam Barati.
3559
3560         We name the thread for bmalloc Scavenger "bmalloc scavenger".
3561         It is useful for debugging. In Linux environment, it will be
3562         shown in GDB.
3563
3564         * bmalloc/Scavenger.cpp:
3565         (bmalloc::Scavenger::threadRunLoop):
3566         (bmalloc::Scavenger::setName):
3567         * bmalloc/Scavenger.h:
3568
3569 2018-04-09  Michael Catanzaro  <mcatanzaro@igalia.com>
3570
3571         Rename UNUSED to BUNUSED
3572         https://bugs.webkit.org/show_bug.cgi?id=184093
3573
3574         Reviewed by Yusuke Suzuki.
3575
3576         * bmalloc/BAssert.h:
3577         * bmalloc/VMAllocate.h:
3578         (bmalloc::vmValidate):
3579         (bmalloc::vmValidatePhysical):
3580
3581 2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>
3582
3583         Use alignas instead of compiler-specific attributes
3584         https://bugs.webkit.org/show_bug.cgi?id=183508
3585
3586         Reviewed by Mark Lam.
3587
3588         Use alignas for g_gigacageBasePtr. We also add reinterpret_cast to fix
3589         compile errors in ARMv7 and MIPS JSCOnly ports.
3590
3591         * bmalloc/Gigacage.cpp:
3592         * bmalloc/Gigacage.h:
3593         (Gigacage::basePtrs):
3594
3595 2018-04-06  Saam Barati  <sbarati@apple.com>
3596
3597         bmalloc virtual allocation API should not treat memory it vends as dirty with respect to how it drives the scavenger
3598         https://bugs.webkit.org/show_bug.cgi?id=184342
3599
3600         Reviewed by Mark Lam.
3601
3602         Currently, the only user of this API is Wasm. Ideally, Wasm would tell
3603         us exactly which page is dirtied. We should really do that at some point:
3604         https://bugs.webkit.org/show_bug.cgi?id=184207
3605         
3606         However, until we do that, it's better to treat none of the virtual memory
3607         we vend as dirty, versus what we do now, which is treat it all as dirty.
3608         This dirty memory tracking helps drive the scavenger, so on iOS, having the
3609         scavenger think its under memory pressure because of memory it can't free isn't
3610         useful.
3611
3612         * bmalloc/bmalloc.cpp:
3613         (bmalloc::api::tryLargeZeroedMemalignVirtual):
3614         (bmalloc::api::freeLargeVirtual):
3615         * bmalloc/bmalloc.h:
3616
3617 2018-04-05  Saam Barati  <sbarati@apple.com>
3618
3619         IsoHeapImpl not IsoHeapImplBase should add itself to AllIsoHeaps
3620         https://bugs.webkit.org/show_bug.cgi?id=184174
3621
3622         Reviewed by Filip Pizlo.
3623
3624         Otherwise, another thread may see a non-fully formed IsoHeapImpl.
3625
3626         * bmalloc/IsoHeapImpl.cpp:
3627         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
3628         (bmalloc::IsoHeapImplBase::addToAllIsoHeaps):
3629         * bmalloc/IsoHeapImpl.h:
3630         * bmalloc/IsoHeapImplInlines.h:
3631         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
3632
3633 2018-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3634
3635         bmalloc StaticMutex's constructor should be constexpr
3636         https://bugs.webkit.org/show_bug.cgi?id=180600
3637
3638         Reviewed by Mark Lam.
3639
3640         StaticMutex and Mutex can be unified. This patch changes std::atomic_flag in StaticMutex
3641         to std::atomic<bool> to add constexpr constructor to StaticMutex. Then, StaticMutex can
3642         be initialized in static storage without calling any static initializers.
3643         And we also rename StaticMutex to Mutex simply.
3644
3645         * CMakeLists.txt:
3646         * bmalloc.xcodeproj/project.pbxproj:
3647         * bmalloc/AllIsoHeaps.cpp:
3648         (bmalloc::AllIsoHeaps::AllIsoHeaps):
3649         * bmalloc/AllIsoHeaps.h:
3650         * bmalloc/Allocator.cpp:
3651         (bmalloc::Allocator::tryAllocate):
3652         (bmalloc::Allocator::allocateImpl):
3653         (bmalloc::Allocator::reallocate):
3654         (bmalloc::Allocator::refillAllocatorSlowCase):
3655         (bmalloc::Allocator::allocateLarge):
3656         * bmalloc/CryptoRandom.cpp:
3657         (bmalloc::ARC4RandomNumberGenerator::ARC4RandomNumberGenerator):
3658         * bmalloc/Deallocator.cpp:
3659         (bmalloc::Deallocator::scavenge):
3660         (bmalloc::Deallocator::processObjectLog):
3661         (bmalloc::Deallocator::deallocateSlowCase):
3662         * bmalloc/Deallocator.h:
3663         (bmalloc::Deallocator::lineCache):
3664         * bmalloc/DebugHeap.cpp:
3665         (bmalloc::DebugHeap::DebugHeap):
3666         * bmalloc/DebugHeap.h:
3667         * bmalloc/Environment.cpp:
3668         (bmalloc::Environment::Environment):
3669         * bmalloc/Environment.h:
3670         * bmalloc/Gigacage.cpp:
3671         (Gigacage::disablePrimitiveGigacage):
3672         (Gigacage::addPrimitiveDisableCallback):
3673         (Gigacage::removePrimitiveDisableCallback):
3674         * bmalloc/Heap.cpp:
3675         (bmalloc::Heap::Heap):
3676         (bmalloc::Heap::freeableMemory):
3677         (bmalloc::Heap::scavenge):
3678         (bmalloc::Heap::deallocateLineCache):
3679         (bmalloc::Heap::allocateSmallChunk):
3680         (bmalloc::Heap::allocateSmallPage):
3681         (bmalloc::Heap::deallocateSmallLine):
3682         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
3683         (bmalloc::Heap::allocateSmallBumpRangesByObject):
3684         (bmalloc::Heap::splitAndAllocate):
3685         (bmalloc::Heap::tryAllocateLarge):
3686         (bmalloc::Heap::allocateLarge):
3687         (bmalloc::Heap::isLarge):
3688         (bmalloc::Heap::largeSize):
3689         (bmalloc::Heap::shrinkLarge):
3690         (bmalloc::Heap::deallocateLarge):
3691         (bmalloc::Heap::externalCommit):
3692         (bmalloc::Heap::externalDecommit):
3693         * bmalloc/Heap.h:
3694         (bmalloc::Heap::mutex):
3695         (bmalloc::Heap::allocateSmallBumpRanges):
3696         (bmalloc::Heap::derefSmallLine):
3697         * bmalloc/IsoDeallocator.h:
3698         * bmalloc/IsoHeap.h:
3699         * bmalloc/IsoTLSDeallocatorEntry.h:
3700         * bmalloc/IsoTLSDeallocatorEntryInlines.h:
3701         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
3702         * bmalloc/IsoTLSInlines.h:
3703         (bmalloc::IsoTLS::ensureHeap):
3704         * bmalloc/IsoTLSLayout.cpp:
3705         (bmalloc::IsoTLSLayout::IsoTLSLayout):
3706         (bmalloc::IsoTLSLayout::add):
3707         * bmalloc/IsoTLSLayout.h:
3708         * bmalloc/Mutex.cpp: Renamed from Source/bmalloc/bmalloc/StaticMutex.cpp.
3709         (bmalloc::Mutex::lockSlowCase):
3710         * bmalloc/Mutex.h:
3711         (bmalloc::sleep):
3712         (bmalloc::waitUntilFalse):
3713         (bmalloc::Mutex::try_lock):
3714         (bmalloc::Mutex::lock):
3715         (bmalloc::Mutex::unlock):
3716         (bmalloc::Mutex::Mutex): Deleted.
3717         * bmalloc/ObjectType.cpp:
3718         (bmalloc::objectType):
3719         * bmalloc/PerProcess.cpp:
3720         (bmalloc::getPerProcessData):
3721         * bmalloc/PerProcess.h:
3722         (bmalloc::PerProcess::mutex):
3723         (bmalloc::PerProcess::getSlowCase):
3724         * bmalloc/Scavenger.cpp:
3725         (bmalloc::Scavenger::Scavenger):
3726         (bmalloc::Scavenger::scavenge):
3727         (bmalloc::Scavenger::freeableMemory):
3728         * bmalloc/Scavenger.h:
3729         * bmalloc/SmallLine.h:
3730         (bmalloc::SmallLine::refCount):
3731         (bmalloc::SmallLine::ref):
3732         (bmalloc::SmallLine::deref):
3733         * bmalloc/SmallPage.h:
3734         (bmalloc::SmallPage::refCount):
3735         (bmalloc::SmallPage::hasFreeLines const):
3736         (bmalloc::SmallPage::setHasFreeLines):
3737         (bmalloc::SmallPage::ref):
3738         (bmalloc::SmallPage::deref):
3739         * bmalloc/StaticMutex.h: Removed.
3740         * bmalloc/VMHeap.cpp:
3741         (bmalloc::VMHeap::VMHeap):
3742         * bmalloc/VMHeap.h:
3743         * bmalloc/Zone.cpp:
3744         (bmalloc::Zone::Zone):
3745         * bmalloc/Zone.h:
3746         * bmalloc/bmalloc.cpp:
3747         (bmalloc::api::tryLargeZeroedMemalignVirtual):
3748         (bmalloc::api::freeLargeVirtual):
3749         (bmalloc::api::isEnabled):
3750         (bmalloc::api::setScavengerThreadQOSClass):
3751         * bmalloc/bmalloc.h:
3752
3753 2018-04-04  Konstantin Tokarev  <annulen@yandex.ru>
3754
3755         Enable Gigacage unconditionally when building JSCOnly on macOS (build fix)
3756         https://bugs.webkit.org/show_bug.cgi?id=184301
3757
3758         Reviewed by Yusuke Suzuki.
3759
3760         bmalloc/ProcessCheck.mm implements specific behavior for Mac and iOS ports,
3761         which is guarded with BPLATFORM(COCOA). if we don't enable BPLATFORM(MAC)
3762         or BPLATFORM(IOS) in JSCOnly, then BPLATFORM(COCOA) won't be defined
3763         as well, and code path from ProcessCheck.mm will not be taken.
3764
3765         * CMakeLists.txt: Exclude ProcessCheck.mm from port-independent file
3766         list.
3767         * PlatformMac.cmake: Build ProcessCheck.mm for Mac port.
3768         * bmalloc/BPlatform.h: Don't enable BPLATFORM(MAC) or BPLATFORM(IOS)
3769         when building JSCOnly port.
3770
3771 2018-04-03  Saam Barati  <sbarati@apple.com>
3772
3773         totalPhysicalSize calculation when splitting a range must account for double rounding effects
3774         https://bugs.webkit.org/show_bug.cgi?id=184275
3775
3776         Reviewed by Mark Lam.
3777
3778         The rounding error could happen when we split a range where the
3779         range's total physical size equals the range's total size. The
3780         rounding may cause the left size to lose a byte, and the right
3781         size to gain a byte. This caused the right side to be a byte
3782         large than its size.
3783
3784         * bmalloc/LargeRange.h:
3785         (bmalloc::LargeRange::LargeRange):
3786         (bmalloc::LargeRange::split const):
3787
3788 2018-04-02  Saam Barati  <sbarati@apple.com>
3789
3790         bmalloc should compute its own estimate of its footprint
3791         https://bugs.webkit.org/show_bug.cgi?id=184121
3792
3793         Reviewed by Filip Pizlo.
3794
3795         This patch makes it so that bmalloc keeps track of its own physical
3796         footprint.
3797         
3798         Doing this for IsoHeaps is trivial. It allocates/deallocates fixed
3799         page sizes at a time. IsoHeapImpl just updates a count every time
3800         a page is committed/decommitted.
3801         
3802         Making Heap keep its footprint was a bit trickier because of how
3803         LargeRange is constructed. Before this patch, LargeRange kept track
3804         of the amount of physical memory at the start of its range. This
3805         patch extends large range to also keep track of the total physical memory
3806         in the range just for footprint bookkeeping. This was needed to make
3807         Heap's footprint come close to resembling reality, because as we merge and split
3808         large ranges, the start physical size often becomes wildly inaccurate.
3809         The total physical size number stored in LargeRange is still just an
3810         estimate. It's possible that as ranges are split, that the total physical
3811         size split amongst the two ranges doesn't resemble reality. This can
3812         happen when the total physical size is really all in one end of the split,
3813         but we mark it as being proportionally split amongst the resulting two
3814         ranges. In practice, I did not notice this being a problem. The footprint
3815         estimate tracks reality very closely (in my testing, within less than 1MB for
3816         heaps with sizes upwards of 1GB). The other nice thing about total physical
3817         size is that even if it diverges from reality in terms of how memory is
3818         using up physical RAM, it stays internally consistent inside bmalloc's
3819         own data structures.
3820         
3821         The main oversight of this patch is how it deals with Wasm memory. All Wasm
3822         memory will be viewed by bmalloc as taking up physical space even when it
3823         may not be. Wasm memory starts off as taking up purely virtual pages. When a
3824         page is first accessed, only then will the OS page it in and cause it to use
3825         physical RAM. I opened a bug to come up with a solution to this problem:
3826         https://bugs.webkit.org/show_bug.cgi?id=184207
3827
3828         * bmalloc.xcodeproj/project.pbxproj:
3829         * bmalloc/AvailableMemory.cpp:
3830         (bmalloc::memoryStatus):
3831         * bmalloc/BPlatform.h:
3832         * bmalloc/Heap.cpp:
3833         (bmalloc::Heap::Heap):
3834         (bmalloc::Heap::freeableMemory):
3835         (bmalloc::Heap::footprint):
3836         (bmalloc::Heap::scavenge):
3837         (bmalloc::Heap::deallocateSmallChunk):
3838         (bmalloc::Heap::allocateSmallPage):
3839         (bmalloc::Heap::splitAndAllocate):
3840         (bmalloc::Heap::tryAllocateLarge):
3841         (bmalloc::Heap::shrinkLarge):
3842         (bmalloc::Heap::deallocateLarge):
3843         (bmalloc::Heap::externalCommit):
3844         (bmalloc::Heap::externalDecommit):
3845         * bmalloc/Heap.h:
3846         * bmalloc/IsoDirectory.h:
3847         * bmalloc/IsoDirectoryInlines.h:
3848         (bmalloc::passedNumPages>::takeFirstEligible):
3849         (bmalloc::passedNumPages>::didDecommit):
3850         (bmalloc::passedNumPages>::freeableMemory):
3851         * bmalloc/IsoHeapImpl.h:
3852         * bmalloc/IsoHeapImplInlines.h:
3853         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
3854         (bmalloc::IsoHeapImpl<Config>::footprint):
3855         (bmalloc::IsoHeapImpl<Config>::didCommit):
3856         (bmalloc::IsoHeapImpl<Config>::didDecommit):
3857         * bmalloc/LargeRange.h:
3858         (bmalloc::LargeRange::LargeRange):
3859         (bmalloc::LargeRange::startPhysicalSize const):
3860         (bmalloc::LargeRange::setStartPhysicalSize):
3861         (bmalloc::LargeRange::totalPhysicalSize const):
3862         (bmalloc::LargeRange::setTotalPhysicalSize):
3863         (bmalloc::merge):
3864         (bmalloc::LargeRange::split const):
3865         (bmalloc::LargeRange::physicalSize const): Deleted.
3866         (bmalloc::LargeRange::setPhysicalSize): Deleted.
3867         * bmalloc/PhysicalPageMap.h: Added.
3868         This class is added for debugging purposes. It's useful when hacking
3869         on the code that calculates the footprint to use this map as a sanity
3870         check. It's just a simple implementation that has a set of all the committed pages.
3871
3872         (bmalloc::PhysicalPageMap::commit):
3873         (bmalloc::PhysicalPageMap::decommit):
3874         (bmalloc::PhysicalPageMap::footprint):
3875         (bmalloc::PhysicalPageMap::forEachPhysicalPage):
3876         * bmalloc/Scavenger.cpp:
3877         (bmalloc::dumpStats):
3878         (bmalloc::Scavenger::scavenge):
3879         (bmalloc::Scavenger::freeableMemory):
3880         This is here just for debugging for now. But we should implement an
3881         efficient version of this to use when driving when to run the
3882         scavenger.
3883
3884         (bmalloc::Scavenger::footprint):
3885         (bmalloc::Scavenger::threadRunLoop):
3886         * bmalloc/Scavenger.h:
3887         * bmalloc/VMAllocate.h:
3888         (bmalloc::physicalPageSizeSloppy):
3889         * bmalloc/VMHeap.cpp:
3890         (bmalloc::VMHeap::tryAllocateLargeChunk):
3891         * bmalloc/bmalloc.cpp:
3892         (bmalloc::api::commitAlignedPhysical):
3893         (bmalloc::api::decommitAlignedPhysical):
3894         * bmalloc/bmalloc.h:
3895
3896 2018-03-28  Commit Queue  <commit-queue@webkit.org>
3897
3898         Unreviewed, rolling out r230005.
3899         https://bugs.webkit.org/show_bug.cgi?id=184115
3900
3901         "it caused a huge regression on iOS" (Requested by saamyjoon
3902         on #webkit).
3903
3904         Reverted changeset:
3905
3906         "memoryStatus() is wrong in certain testing scenarios on iOS"
3907         https://bugs.webkit.org/show_bug.cgi?id=184050
3908         https://trac.webkit.org/changeset/230005
3909
3910 2018-03-27  Saam Barati  <sbarati@apple.com>
3911
3912         memoryStatus() is wrong in certain testing scenarios on iOS
3913         https://bugs.webkit.org/show_bug.cgi?id=184050
3914         <rdar://problem/37959258>
3915
3916         Rubber-stamped by Mark Lam.
3917
3918         This switches us from using "phys_footprint" to using "internal + compressed"
3919         when computing the dirty memory in the current process. There are iOS testing
3920         scenarios where phys_footprint doesn't give us a reliable answer. In my testing,
3921         "internal + compressed" tracks phys_footprint closely (when phys_footprint is
3922         working). They're usually within much less than 1% of each other. We're making
3923         this change to ensure testing in our iOS infrastructure is valid.
3924         
3925         I opened a bug to move back to phys_footprint when it's feasible:
3926         https://bugs.webkit.org/show_bug.cgi?id=184050
3927
3928         * bmalloc/AvailableMemory.cpp:
3929         (bmalloc::memoryStatus):
3930
3931 2018-03-20  Tim Horton  <timothy_horton@apple.com>
3932
3933         Add and adopt WK_PLATFORM_NAME and adjust default feature defines
3934         https://bugs.webkit.org/show_bug.cgi?id=183758
3935         <rdar://problem/38017644>
3936
3937         Reviewed by Dan Bernstein.
3938
3939         * Configurations/Base.xcconfig:
3940
3941 2018-03-16  Filip Pizlo  <fpizlo@apple.com>
3942
3943         Put the DOM in IsoHeaps
3944         https://bugs.webkit.org/show_bug.cgi?id=183546
3945
3946         Reviewed by Simon Fraser.
3947         
3948         Make it easy to runtime-disable IsoHeaps.
3949
3950         * bmalloc/Allocator.h:
3951         * bmalloc/IsoTLS.cpp:
3952         (bmalloc::IsoTLS::determineMallocFallbackState):
3953         * bmalloc/IsoTLS.h:
3954         * bmalloc/IsoTLSInlines.h:
3955         (bmalloc::IsoTLS::allocateSlow):
3956         (bmalloc::IsoTLS::deallocateSlow):
3957
3958 2018-03-16  Michael Catanzaro  <mcatanzaro@igalia.com>
3959
3960         Improve error message when Gigacage cannot allocate virtual memory
3961         https://bugs.webkit.org/show_bug.cgi?id=183329
3962
3963         Reviewed by Filip Pizlo.
3964
3965         We've discovered that Deja Dup monitor sets a virtual memory limit, breaking Gigacage. Since
3966         it runs in the background on a fresh out-of-the-box install of Ubuntu, this is not good.
3967         That will have to be fixed by Deja Dup, but there is concern that other applications might
3968         try this, or that users will set a virtual memory limit for the entire desktop session. Of
3969         particular concern is the possibility that users might have copypasted a ulimit line into
3970         a session startup script without understanding it. Let's try to make it slightly easier to
3971         understand what's going wrong.
3972
3973         * bmalloc/Gigacage.cpp:
3974         (Gigacage::ensureGigacage):
3975
3976 2018-03-13  Tim Horton  <timothy_horton@apple.com>
3977
3978         Add and adopt WK_ALTERNATE_FRAMEWORKS_DIR in WTF and bmalloc
3979         https://bugs.webkit.org/show_bug.cgi?id=183576
3980         <rdar://problem/38396766>
3981
3982         Reviewed by Dan Bernstein.
3983
3984         * Configurations/Base.xcconfig:
3985         * Configurations/bmalloc.xcconfig:
3986         * Configurations/mbmalloc.xcconfig:
3987
3988 2018-03-10  Filip Pizlo  <fpizlo@apple.com>
3989
3990         PerProcess<> should be safe by default
3991         https://bugs.webkit.org/show_bug.cgi?id=183545
3992
3993         Reviewed by Yusuke Suzuki.
3994         
3995         This makes PerProcess<> safe by default, so we don't need SafePerProcess<>.
3996         
3997         The new PerProcess<> design relies on a hash-consing mechanism for PerProcess<> storage based
3998         on the __PRETTY_FUNCTION__ from inside PerProcess<>, which captures the instantiated type in
3999         the string. Therefore, this can be used to runtime-coalesce PerProcess<> instances based on
4000         type.
4001         
4002         I expect this to be perf-neutral. It's an important prerequisite to more bmalloc work, since I
4003         don't want to have more PerProcess<> vs SafePerProcess<> bugs, and SafePerProcess<> can't be
4004         used for everything (I don't see how to use it for isoheaps).
4005
4006         * CMakeLists.txt:
4007         * bmalloc.xcodeproj/project.pbxproj:
4008         * bmalloc/Heap.cpp:
4009         (bmalloc::Heap::Heap):
4010         * bmalloc/IsoDirectoryInlines.h:
4011         (bmalloc::passedNumPages>::takeFirstEligible):
4012         (bmalloc::passedNumPages>::didBecome):
4013         * bmalloc/PerProcess.cpp: Added.
4014         (bmalloc::stringHash):
4015         (bmalloc::allocate):
4016         (bmalloc::getPerProcessData):
4017         * bmalloc/PerProcess.h:
4018         (bmalloc::PerProcess::mutex):
4019         (bmalloc::PerProcess::coalesce):
4020         (bmalloc::PerProcess::getSlowCase):
4021         (): Deleted.
4022         * bmalloc/Scavenger.cpp:
4023         * bmalloc/Scavenger.h:
4024         * bmalloc/bmalloc.cpp:
4025         (bmalloc::api::scavenge):
4026         (bmalloc::api::setScavengerThreadQOSClass):
4027
4028 2018-03-10  Commit Queue  <commit-queue@webkit.org>
4029
4030         Unreviewed, rolling out r229436.
4031         https://bugs.webkit.org/show_bug.cgi?id=183542
4032
4033         seems to have regressed wasm compile times by 10% (Requested
4034         by pizlo-mbp on #webkit).
4035
4036         Reverted changeset:
4037
4038         "bmalloc mutex should be adaptive"
4039         https://bugs.webkit.org/show_bug.cgi?id=177839
4040         https://trac.webkit.org/changeset/229436
4041
4042 2018-03-08  Filip Pizlo  <fpizlo@apple.com>
4043
4044         bmalloc mutex should be adaptive
4045         https://bugs.webkit.org/show_bug.cgi?id=177839
4046
4047         Reviewed by Michael Saboff.
4048         
4049         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
4050         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
4051         anything other than malloc.
4052
4053         Reland after failing to reproduce the WasmBench crash that caused it to get rolled out. Maybe that fixed
4054         itself somehow?
4055
4056         * bmalloc/Algorithm.h:
4057         (bmalloc::compareExchangeWeak):
4058         (bmalloc::compareExchangeStrong):
4059         * bmalloc/PerThread.h:
4060         * bmalloc/StaticMutex.cpp:
4061         (bmalloc::StaticMutex::lockSlow):
4062         (bmalloc::StaticMutex::unlockSlow):
4063         (bmalloc::StaticMutex::lockSlowCase): Deleted.
4064         * bmalloc/StaticMutex.h:
4065         (bmalloc::StaticMutex::try_lock):
4066         (bmalloc::StaticMutex::isLocked const):
4067         (bmalloc::StaticMutex::init):
4068         (bmalloc::StaticMutex::tryLock):
4069         (bmalloc::StaticMutex::lock):
4070         (bmalloc::StaticMutex::unlock):
4071         (bmalloc::sleep): Deleted.
4072         (bmalloc::waitUntilFalse): Deleted.
4073
4074 2018-02-16  Filip Pizlo  <fpizlo@apple.com>
4075
4076         Unreviewed, roll out r228306 (custom memcpy/memset) because the bots say that it was not a