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