Raise the partial scavenge interval even more on x86-64
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2018-04-12  Saam Barati  <sbarati@apple.com>
2
3         Raise the partial scavenge interval even more on x86-64
4         https://bugs.webkit.org/show_bug.cgi?id=184551
5
6         Rubber-stamped by Filip Pizlo.
7
8         The JetStream regression didn't recover from my previous patch.
9         This is another attempt to get it to recover perf.
10
11         * bmalloc/Scavenger.cpp:
12         (bmalloc::Scavenger::threadRunLoop):
13
14 2018-04-11  Saam Barati  <sbarati@apple.com>
15
16         raise partial scavenge interval on x86-64
17         https://bugs.webkit.org/show_bug.cgi?id=184521
18
19         Rubber-stamped by Filip Pizlo.
20
21         This patch is an attempt to recover the 1-3% JetStream regression
22         my initial partial scavenging patch introduced on some Macs.
23
24         * bmalloc/Scavenger.cpp:
25         (bmalloc::Scavenger::threadRunLoop):
26
27 2018-04-10  Saam Barati  <sbarati@apple.com>
28
29         IsoHeapImpl::scavenge* needs to grab the lock
30         https://bugs.webkit.org/show_bug.cgi?id=184461
31
32         Reviewed by Filip Pizlo.
33
34         Another thread could be modifying the linked list that the scavenge* methods traverse.
35
36         * bmalloc/IsoHeapImplInlines.h:
37         (bmalloc::IsoHeapImpl<Config>::scavenge):
38         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
39
40 2018-04-10  Saam Barati  <sbarati@apple.com>
41
42         bmalloc should do partial scavenges more frequently
43         https://bugs.webkit.org/show_bug.cgi?id=184176
44
45         Reviewed by Filip Pizlo.
46
47         This patch adds the ability for bmalloc to do a partial scavenge.
48         bmalloc will now do a partial scavenge with some frequency even
49         when the heap is growing.
50         
51         For Heap, this means tracking the high water mark of where the Heap
52         has allocated since the last scavenge. Partial scavenging is just
53         decommitting entries in the LargeMap that are past this high water
54         mark. Because we allocate in first fit order out of LargeMap, tracking
55         the high water mark is a good heuristic of how much memory a partial
56         scavenge should decommit.
57         
58         For IsoHeaps, each IsoDirectory also keeps track of its high water mark
59         for the furthest page it allocates into. Similar to Heap, we scavenge pages
60         past that high water mark. IsoHeapImpl then tracks the high water mark
61         for the IsoDirectory it allocates into. We then scavenge all directories 
62         including and past the directory high water mark. This includes scavenging
63         the inline directory when its the only thing we allocate out of since
64         the last scavenge.
65         
66         This patch also adds some other capabilities to bmalloc:
67         
68         Heaps and IsoHeaps now track how much memory is freeable. Querying
69         this number is now cheap.
70         
71         Heaps no longer hold the global lock when decommitting large ranges.
72         Instead, that range is just marked as non eligible to be allocated.
73         Then, without the lock held, the scavenger will decommit those ranges.
74         Once this is done, the scavenger will then reacquire the lock and mark
75         these ranges as eligible. This lessens lock contention between the
76         scavenger and the allocation slow path since threads that are taking an
77         allocation slow path can now allocate concurrently to the scavenger's
78         decommits. The main consideration in adding this functionality is that
79         a large allocation may fail while the scavenger is in the process of
80         decommitting memory. When the Heap fails to allocate a large range when
81         the scavenger is in the middle of a decommit, Heap will wait for the
82         Scavenger to finish and then it will try to allocate a large range again.
83         
84         Decommitting from Heap now aggregates the ranges to decommit and tries to
85         merge them together to lower the number of calls to vmDeallocatePhysicalPages.
86         This is analogous to what IsoHeaps already do.
87
88         * bmalloc.xcodeproj/project.pbxproj:
89         * bmalloc/Allocator.cpp:
90         (bmalloc::Allocator::tryAllocate):
91         (bmalloc::Allocator::allocateImpl):
92         (bmalloc::Allocator::reallocate):
93         (bmalloc::Allocator::refillAllocatorSlowCase):
94         (bmalloc::Allocator::allocateLarge):
95         * bmalloc/BulkDecommit.h: Added.
96         (bmalloc::BulkDecommit::addEager):
97         (bmalloc::BulkDecommit::addLazy):
98         (bmalloc::BulkDecommit::processEager):
99         (bmalloc::BulkDecommit::processLazy):
100         (bmalloc::BulkDecommit::add):
101         (bmalloc::BulkDecommit::process):
102         * bmalloc/Deallocator.cpp:
103         (bmalloc::Deallocator::scavenge):
104         (bmalloc::Deallocator::processObjectLog):
105         (bmalloc::Deallocator::deallocateSlowCase):
106         * bmalloc/Deallocator.h:
107         (bmalloc::Deallocator::lineCache):
108         * bmalloc/Heap.cpp:
109         (bmalloc::Heap::freeableMemory):
110         (bmalloc::Heap::markAllLargeAsEligibile):
111         (bmalloc::Heap::decommitLargeRange):
112         (bmalloc::Heap::scavenge):
113         (bmalloc::Heap::scavengeToHighWatermark):
114         (bmalloc::Heap::deallocateLineCache):
115         (bmalloc::Heap::allocateSmallChunk):
116         (bmalloc::Heap::deallocateSmallChunk):
117         (bmalloc::Heap::allocateSmallPage):
118         (bmalloc::Heap::deallocateSmallLine):
119         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
120         (bmalloc::Heap::allocateSmallBumpRangesByObject):
121         (bmalloc::Heap::splitAndAllocate):
122         (bmalloc::Heap::tryAllocateLarge):
123         (bmalloc::Heap::allocateLarge):
124         (bmalloc::Heap::isLarge):
125         (bmalloc::Heap::largeSize):
126         (bmalloc::Heap::shrinkLarge):
127         (bmalloc::Heap::deallocateLarge):
128         (bmalloc::Heap::externalCommit):
129         (bmalloc::Heap::externalDecommit):
130         * bmalloc/Heap.h:
131         (bmalloc::Heap::allocateSmallBumpRanges):
132         (bmalloc::Heap::derefSmallLine):
133         * bmalloc/IsoDirectory.h:
134         * bmalloc/IsoDirectoryInlines.h:
135         (bmalloc::passedNumPages>::takeFirstEligible):
136         (bmalloc::passedNumPages>::didBecome):
137         (bmalloc::passedNumPages>::didDecommit):
138         (bmalloc::passedNumPages>::scavengePage):
139         (bmalloc::passedNumPages>::scavenge):
140         (bmalloc::passedNumPages>::scavengeToHighWatermark):
141         (bmalloc::passedNumPages>::freeableMemory): Deleted.
142         * bmalloc/IsoHeapImpl.h:
143         * bmalloc/IsoHeapImplInlines.h:
144         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
145         (bmalloc::IsoHeapImpl<Config>::scavenge):
146         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
147         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
148         (bmalloc::IsoHeapImpl<Config>::isNowFreeable):
149         (bmalloc::IsoHeapImpl<Config>::isNoLongerFreeable):
150         * bmalloc/LargeMap.cpp:
151         (bmalloc::LargeMap::remove):
152         (bmalloc::LargeMap::markAllAsEligibile):
153         * bmalloc/LargeMap.h:
154         (bmalloc::LargeMap::size):
155         (bmalloc::LargeMap::at):
156         * bmalloc/LargeRange.h:
157         (bmalloc::LargeRange::setEligible):
158         (bmalloc::LargeRange::isEligibile const):
159         (bmalloc::canMerge):
160         * bmalloc/ObjectType.cpp:
161         (bmalloc::objectType):
162         * bmalloc/Scavenger.cpp:
163         (bmalloc::PrintTime::PrintTime):
164         (bmalloc::PrintTime::~PrintTime):
165         (bmalloc::PrintTime::print):
166         (bmalloc::Scavenger::timeSinceLastFullScavenge):
167         (bmalloc::Scavenger::timeSinceLastPartialScavenge):
168         (bmalloc::Scavenger::scavenge):
169         (bmalloc::Scavenger::partialScavenge):
170         (bmalloc::Scavenger::freeableMemory):
171         (bmalloc::Scavenger::threadRunLoop):
172         * bmalloc/Scavenger.h:
173         * bmalloc/SmallLine.h:
174         (bmalloc::SmallLine::refCount):
175         (bmalloc::SmallLine::ref):
176         (bmalloc::SmallLine::deref):
177         * bmalloc/SmallPage.h:
178         (bmalloc::SmallPage::refCount):
179         (bmalloc::SmallPage::hasFreeLines const):
180         (bmalloc::SmallPage::setHasFreeLines):
181         (bmalloc::SmallPage::ref):
182         (bmalloc::SmallPage::deref):
183         * bmalloc/bmalloc.cpp:
184         (bmalloc::api::tryLargeZeroedMemalignVirtual):
185         (bmalloc::api::freeLargeVirtual):
186
187 2018-04-09  Yusuke Suzuki  <utatane.tea@gmail.com>
188
189         [bmalloc] Name Scavenger thread "bmalloc scavenger"
190         https://bugs.webkit.org/show_bug.cgi?id=166684
191
192         Reviewed by Saam Barati.
193
194         We name the thread for bmalloc Scavenger "bmalloc scavenger".
195         It is useful for debugging. In Linux environment, it will be
196         shown in GDB.
197
198         * bmalloc/Scavenger.cpp:
199         (bmalloc::Scavenger::threadRunLoop):
200         (bmalloc::Scavenger::setName):
201         * bmalloc/Scavenger.h:
202
203 2018-04-09  Michael Catanzaro  <mcatanzaro@igalia.com>
204
205         Rename UNUSED to BUNUSED
206         https://bugs.webkit.org/show_bug.cgi?id=184093
207
208         Reviewed by Yusuke Suzuki.
209
210         * bmalloc/BAssert.h:
211         * bmalloc/VMAllocate.h:
212         (bmalloc::vmValidate):
213         (bmalloc::vmValidatePhysical):
214
215 2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>
216
217         Use alignas instead of compiler-specific attributes
218         https://bugs.webkit.org/show_bug.cgi?id=183508
219
220         Reviewed by Mark Lam.
221
222         Use alignas for g_gigacageBasePtr. We also add reinterpret_cast to fix
223         compile errors in ARMv7 and MIPS JSCOnly ports.
224
225         * bmalloc/Gigacage.cpp:
226         * bmalloc/Gigacage.h:
227         (Gigacage::basePtrs):
228
229 2018-04-06  Saam Barati  <sbarati@apple.com>
230
231         bmalloc virtual allocation API should not treat memory it vends as dirty with respect to how it drives the scavenger
232         https://bugs.webkit.org/show_bug.cgi?id=184342
233
234         Reviewed by Mark Lam.
235
236         Currently, the only user of this API is Wasm. Ideally, Wasm would tell
237         us exactly which page is dirtied. We should really do that at some point:
238         https://bugs.webkit.org/show_bug.cgi?id=184207
239         
240         However, until we do that, it's better to treat none of the virtual memory
241         we vend as dirty, versus what we do now, which is treat it all as dirty.
242         This dirty memory tracking helps drive the scavenger, so on iOS, having the
243         scavenger think its under memory pressure because of memory it can't free isn't
244         useful.
245
246         * bmalloc/bmalloc.cpp:
247         (bmalloc::api::tryLargeZeroedMemalignVirtual):
248         (bmalloc::api::freeLargeVirtual):
249         * bmalloc/bmalloc.h:
250
251 2018-04-05  Saam Barati  <sbarati@apple.com>
252
253         IsoHeapImpl not IsoHeapImplBase should add itself to AllIsoHeaps
254         https://bugs.webkit.org/show_bug.cgi?id=184174
255
256         Reviewed by Filip Pizlo.
257
258         Otherwise, another thread may see a non-fully formed IsoHeapImpl.
259
260         * bmalloc/IsoHeapImpl.cpp:
261         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
262         (bmalloc::IsoHeapImplBase::addToAllIsoHeaps):
263         * bmalloc/IsoHeapImpl.h:
264         * bmalloc/IsoHeapImplInlines.h:
265         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
266
267 2018-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
268
269         bmalloc StaticMutex's constructor should be constexpr
270         https://bugs.webkit.org/show_bug.cgi?id=180600
271
272         Reviewed by Mark Lam.
273
274         StaticMutex and Mutex can be unified. This patch changes std::atomic_flag in StaticMutex
275         to std::atomic<bool> to add constexpr constructor to StaticMutex. Then, StaticMutex can
276         be initialized in static storage without calling any static initializers.
277         And we also rename StaticMutex to Mutex simply.
278
279         * CMakeLists.txt:
280         * bmalloc.xcodeproj/project.pbxproj:
281         * bmalloc/AllIsoHeaps.cpp:
282         (bmalloc::AllIsoHeaps::AllIsoHeaps):
283         * bmalloc/AllIsoHeaps.h:
284         * bmalloc/Allocator.cpp:
285         (bmalloc::Allocator::tryAllocate):
286         (bmalloc::Allocator::allocateImpl):
287         (bmalloc::Allocator::reallocate):
288         (bmalloc::Allocator::refillAllocatorSlowCase):
289         (bmalloc::Allocator::allocateLarge):
290         * bmalloc/CryptoRandom.cpp:
291         (bmalloc::ARC4RandomNumberGenerator::ARC4RandomNumberGenerator):
292         * bmalloc/Deallocator.cpp:
293         (bmalloc::Deallocator::scavenge):
294         (bmalloc::Deallocator::processObjectLog):
295         (bmalloc::Deallocator::deallocateSlowCase):
296         * bmalloc/Deallocator.h:
297         (bmalloc::Deallocator::lineCache):
298         * bmalloc/DebugHeap.cpp:
299         (bmalloc::DebugHeap::DebugHeap):
300         * bmalloc/DebugHeap.h:
301         * bmalloc/Environment.cpp:
302         (bmalloc::Environment::Environment):
303         * bmalloc/Environment.h:
304         * bmalloc/Gigacage.cpp:
305         (Gigacage::disablePrimitiveGigacage):
306         (Gigacage::addPrimitiveDisableCallback):
307         (Gigacage::removePrimitiveDisableCallback):
308         * bmalloc/Heap.cpp:
309         (bmalloc::Heap::Heap):
310         (bmalloc::Heap::freeableMemory):
311         (bmalloc::Heap::scavenge):
312         (bmalloc::Heap::deallocateLineCache):
313         (bmalloc::Heap::allocateSmallChunk):
314         (bmalloc::Heap::allocateSmallPage):
315         (bmalloc::Heap::deallocateSmallLine):
316         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
317         (bmalloc::Heap::allocateSmallBumpRangesByObject):
318         (bmalloc::Heap::splitAndAllocate):
319         (bmalloc::Heap::tryAllocateLarge):
320         (bmalloc::Heap::allocateLarge):
321         (bmalloc::Heap::isLarge):
322         (bmalloc::Heap::largeSize):
323         (bmalloc::Heap::shrinkLarge):
324         (bmalloc::Heap::deallocateLarge):
325         (bmalloc::Heap::externalCommit):
326         (bmalloc::Heap::externalDecommit):
327         * bmalloc/Heap.h:
328         (bmalloc::Heap::mutex):
329         (bmalloc::Heap::allocateSmallBumpRanges):
330         (bmalloc::Heap::derefSmallLine):
331         * bmalloc/IsoDeallocator.h:
332         * bmalloc/IsoHeap.h:
333         * bmalloc/IsoTLSDeallocatorEntry.h:
334         * bmalloc/IsoTLSDeallocatorEntryInlines.h:
335         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
336         * bmalloc/IsoTLSInlines.h:
337         (bmalloc::IsoTLS::ensureHeap):
338         * bmalloc/IsoTLSLayout.cpp:
339         (bmalloc::IsoTLSLayout::IsoTLSLayout):
340         (bmalloc::IsoTLSLayout::add):
341         * bmalloc/IsoTLSLayout.h:
342         * bmalloc/Mutex.cpp: Renamed from Source/bmalloc/bmalloc/StaticMutex.cpp.
343         (bmalloc::Mutex::lockSlowCase):
344         * bmalloc/Mutex.h:
345         (bmalloc::sleep):
346         (bmalloc::waitUntilFalse):
347         (bmalloc::Mutex::try_lock):
348         (bmalloc::Mutex::lock):
349         (bmalloc::Mutex::unlock):
350         (bmalloc::Mutex::Mutex): Deleted.
351         * bmalloc/ObjectType.cpp:
352         (bmalloc::objectType):
353         * bmalloc/PerProcess.cpp:
354         (bmalloc::getPerProcessData):
355         * bmalloc/PerProcess.h:
356         (bmalloc::PerProcess::mutex):
357         (bmalloc::PerProcess::getSlowCase):
358         * bmalloc/Scavenger.cpp:
359         (bmalloc::Scavenger::Scavenger):
360         (bmalloc::Scavenger::scavenge):
361         (bmalloc::Scavenger::freeableMemory):
362         * bmalloc/Scavenger.h:
363         * bmalloc/SmallLine.h:
364         (bmalloc::SmallLine::refCount):
365         (bmalloc::SmallLine::ref):
366         (bmalloc::SmallLine::deref):
367         * bmalloc/SmallPage.h:
368         (bmalloc::SmallPage::refCount):
369         (bmalloc::SmallPage::hasFreeLines const):
370         (bmalloc::SmallPage::setHasFreeLines):
371         (bmalloc::SmallPage::ref):
372         (bmalloc::SmallPage::deref):
373         * bmalloc/StaticMutex.h: Removed.
374         * bmalloc/VMHeap.cpp:
375         (bmalloc::VMHeap::VMHeap):
376         * bmalloc/VMHeap.h:
377         * bmalloc/Zone.cpp:
378         (bmalloc::Zone::Zone):
379         * bmalloc/Zone.h:
380         * bmalloc/bmalloc.cpp:
381         (bmalloc::api::tryLargeZeroedMemalignVirtual):
382         (bmalloc::api::freeLargeVirtual):
383         (bmalloc::api::isEnabled):
384         (bmalloc::api::setScavengerThreadQOSClass):
385         * bmalloc/bmalloc.h:
386
387 2018-04-04  Konstantin Tokarev  <annulen@yandex.ru>
388
389         Enable Gigacage unconditionally when building JSCOnly on macOS (build fix)
390         https://bugs.webkit.org/show_bug.cgi?id=184301
391
392         Reviewed by Yusuke Suzuki.
393
394         bmalloc/ProcessCheck.mm implements specific behavior for Mac and iOS ports,
395         which is guarded with BPLATFORM(COCOA). if we don't enable BPLATFORM(MAC)
396         or BPLATFORM(IOS) in JSCOnly, then BPLATFORM(COCOA) won't be defined
397         as well, and code path from ProcessCheck.mm will not be taken.
398
399         * CMakeLists.txt: Exclude ProcessCheck.mm from port-independent file
400         list.
401         * PlatformMac.cmake: Build ProcessCheck.mm for Mac port.
402         * bmalloc/BPlatform.h: Don't enable BPLATFORM(MAC) or BPLATFORM(IOS)
403         when building JSCOnly port.
404
405 2018-04-03  Saam Barati  <sbarati@apple.com>
406
407         totalPhysicalSize calculation when splitting a range must account for double rounding effects
408         https://bugs.webkit.org/show_bug.cgi?id=184275
409
410         Reviewed by Mark Lam.
411
412         The rounding error could happen when we split a range where the
413         range's total physical size equals the range's total size. The
414         rounding may cause the left size to lose a byte, and the right
415         size to gain a byte. This caused the right side to be a byte
416         large than its size.
417
418         * bmalloc/LargeRange.h:
419         (bmalloc::LargeRange::LargeRange):
420         (bmalloc::LargeRange::split const):
421
422 2018-04-02  Saam Barati  <sbarati@apple.com>
423
424         bmalloc should compute its own estimate of its footprint
425         https://bugs.webkit.org/show_bug.cgi?id=184121
426
427         Reviewed by Filip Pizlo.
428
429         This patch makes it so that bmalloc keeps track of its own physical
430         footprint.
431         
432         Doing this for IsoHeaps is trivial. It allocates/deallocates fixed
433         page sizes at a time. IsoHeapImpl just updates a count every time
434         a page is committed/decommitted.
435         
436         Making Heap keep its footprint was a bit trickier because of how
437         LargeRange is constructed. Before this patch, LargeRange kept track
438         of the amount of physical memory at the start of its range. This
439         patch extends large range to also keep track of the total physical memory
440         in the range just for footprint bookkeeping. This was needed to make
441         Heap's footprint come close to resembling reality, because as we merge and split
442         large ranges, the start physical size often becomes wildly inaccurate.
443         The total physical size number stored in LargeRange is still just an
444         estimate. It's possible that as ranges are split, that the total physical
445         size split amongst the two ranges doesn't resemble reality. This can
446         happen when the total physical size is really all in one end of the split,
447         but we mark it as being proportionally split amongst the resulting two
448         ranges. In practice, I did not notice this being a problem. The footprint
449         estimate tracks reality very closely (in my testing, within less than 1MB for
450         heaps with sizes upwards of 1GB). The other nice thing about total physical
451         size is that even if it diverges from reality in terms of how memory is
452         using up physical RAM, it stays internally consistent inside bmalloc's
453         own data structures.
454         
455         The main oversight of this patch is how it deals with Wasm memory. All Wasm
456         memory will be viewed by bmalloc as taking up physical space even when it
457         may not be. Wasm memory starts off as taking up purely virtual pages. When a
458         page is first accessed, only then will the OS page it in and cause it to use
459         physical RAM. I opened a bug to come up with a solution to this problem:
460         https://bugs.webkit.org/show_bug.cgi?id=184207
461
462         * bmalloc.xcodeproj/project.pbxproj:
463         * bmalloc/AvailableMemory.cpp:
464         (bmalloc::memoryStatus):
465         * bmalloc/BPlatform.h:
466         * bmalloc/Heap.cpp:
467         (bmalloc::Heap::Heap):
468         (bmalloc::Heap::freeableMemory):
469         (bmalloc::Heap::footprint):
470         (bmalloc::Heap::scavenge):
471         (bmalloc::Heap::deallocateSmallChunk):
472         (bmalloc::Heap::allocateSmallPage):
473         (bmalloc::Heap::splitAndAllocate):
474         (bmalloc::Heap::tryAllocateLarge):
475         (bmalloc::Heap::shrinkLarge):
476         (bmalloc::Heap::deallocateLarge):
477         (bmalloc::Heap::externalCommit):
478         (bmalloc::Heap::externalDecommit):
479         * bmalloc/Heap.h:
480         * bmalloc/IsoDirectory.h:
481         * bmalloc/IsoDirectoryInlines.h:
482         (bmalloc::passedNumPages>::takeFirstEligible):
483         (bmalloc::passedNumPages>::didDecommit):
484         (bmalloc::passedNumPages>::freeableMemory):
485         * bmalloc/IsoHeapImpl.h:
486         * bmalloc/IsoHeapImplInlines.h:
487         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
488         (bmalloc::IsoHeapImpl<Config>::footprint):
489         (bmalloc::IsoHeapImpl<Config>::didCommit):
490         (bmalloc::IsoHeapImpl<Config>::didDecommit):
491         * bmalloc/LargeRange.h:
492         (bmalloc::LargeRange::LargeRange):
493         (bmalloc::LargeRange::startPhysicalSize const):
494         (bmalloc::LargeRange::setStartPhysicalSize):
495         (bmalloc::LargeRange::totalPhysicalSize const):
496         (bmalloc::LargeRange::setTotalPhysicalSize):
497         (bmalloc::merge):
498         (bmalloc::LargeRange::split const):
499         (bmalloc::LargeRange::physicalSize const): Deleted.
500         (bmalloc::LargeRange::setPhysicalSize): Deleted.
501         * bmalloc/PhysicalPageMap.h: Added.
502         This class is added for debugging purposes. It's useful when hacking
503         on the code that calculates the footprint to use this map as a sanity
504         check. It's just a simple implementation that has a set of all the committed pages.
505
506         (bmalloc::PhysicalPageMap::commit):
507         (bmalloc::PhysicalPageMap::decommit):
508         (bmalloc::PhysicalPageMap::footprint):
509         (bmalloc::PhysicalPageMap::forEachPhysicalPage):
510         * bmalloc/Scavenger.cpp:
511         (bmalloc::dumpStats):
512         (bmalloc::Scavenger::scavenge):
513         (bmalloc::Scavenger::freeableMemory):
514         This is here just for debugging for now. But we should implement an
515         efficient version of this to use when driving when to run the
516         scavenger.
517
518         (bmalloc::Scavenger::footprint):
519         (bmalloc::Scavenger::threadRunLoop):
520         * bmalloc/Scavenger.h:
521         * bmalloc/VMAllocate.h:
522         (bmalloc::physicalPageSizeSloppy):
523         * bmalloc/VMHeap.cpp:
524         (bmalloc::VMHeap::tryAllocateLargeChunk):
525         * bmalloc/bmalloc.cpp:
526         (bmalloc::api::commitAlignedPhysical):
527         (bmalloc::api::decommitAlignedPhysical):
528         * bmalloc/bmalloc.h:
529
530 2018-03-28  Commit Queue  <commit-queue@webkit.org>
531
532         Unreviewed, rolling out r230005.
533         https://bugs.webkit.org/show_bug.cgi?id=184115
534
535         "it caused a huge regression on iOS" (Requested by saamyjoon
536         on #webkit).
537
538         Reverted changeset:
539
540         "memoryStatus() is wrong in certain testing scenarios on iOS"
541         https://bugs.webkit.org/show_bug.cgi?id=184050
542         https://trac.webkit.org/changeset/230005
543
544 2018-03-27  Saam Barati  <sbarati@apple.com>
545
546         memoryStatus() is wrong in certain testing scenarios on iOS
547         https://bugs.webkit.org/show_bug.cgi?id=184050
548         <rdar://problem/37959258>
549
550         Rubber-stamped by Mark Lam.
551
552         This switches us from using "phys_footprint" to using "internal + compressed"
553         when computing the dirty memory in the current process. There are iOS testing
554         scenarios where phys_footprint doesn't give us a reliable answer. In my testing,
555         "internal + compressed" tracks phys_footprint closely (when phys_footprint is
556         working). They're usually within much less than 1% of each other. We're making
557         this change to ensure testing in our iOS infrastructure is valid.
558         
559         I opened a bug to move back to phys_footprint when it's feasible:
560         https://bugs.webkit.org/show_bug.cgi?id=184050
561
562         * bmalloc/AvailableMemory.cpp:
563         (bmalloc::memoryStatus):
564
565 2018-03-20  Tim Horton  <timothy_horton@apple.com>
566
567         Add and adopt WK_PLATFORM_NAME and adjust default feature defines
568         https://bugs.webkit.org/show_bug.cgi?id=183758
569         <rdar://problem/38017644>
570
571         Reviewed by Dan Bernstein.
572
573         * Configurations/Base.xcconfig:
574
575 2018-03-16  Filip Pizlo  <fpizlo@apple.com>
576
577         Put the DOM in IsoHeaps
578         https://bugs.webkit.org/show_bug.cgi?id=183546
579
580         Reviewed by Simon Fraser.
581         
582         Make it easy to runtime-disable IsoHeaps.
583
584         * bmalloc/Allocator.h:
585         * bmalloc/IsoTLS.cpp:
586         (bmalloc::IsoTLS::determineMallocFallbackState):
587         * bmalloc/IsoTLS.h:
588         * bmalloc/IsoTLSInlines.h:
589         (bmalloc::IsoTLS::allocateSlow):
590         (bmalloc::IsoTLS::deallocateSlow):
591
592 2018-03-16  Michael Catanzaro  <mcatanzaro@igalia.com>
593
594         Improve error message when Gigacage cannot allocate virtual memory
595         https://bugs.webkit.org/show_bug.cgi?id=183329
596
597         Reviewed by Filip Pizlo.
598
599         We've discovered that Deja Dup monitor sets a virtual memory limit, breaking Gigacage. Since
600         it runs in the background on a fresh out-of-the-box install of Ubuntu, this is not good.
601         That will have to be fixed by Deja Dup, but there is concern that other applications might
602         try this, or that users will set a virtual memory limit for the entire desktop session. Of
603         particular concern is the possibility that users might have copypasted a ulimit line into
604         a session startup script without understanding it. Let's try to make it slightly easier to
605         understand what's going wrong.
606
607         * bmalloc/Gigacage.cpp:
608         (Gigacage::ensureGigacage):
609
610 2018-03-13  Tim Horton  <timothy_horton@apple.com>
611
612         Add and adopt WK_ALTERNATE_FRAMEWORKS_DIR in WTF and bmalloc
613         https://bugs.webkit.org/show_bug.cgi?id=183576
614         <rdar://problem/38396766>
615
616         Reviewed by Dan Bernstein.
617
618         * Configurations/Base.xcconfig:
619         * Configurations/bmalloc.xcconfig:
620         * Configurations/mbmalloc.xcconfig:
621
622 2018-03-10  Filip Pizlo  <fpizlo@apple.com>
623
624         PerProcess<> should be safe by default
625         https://bugs.webkit.org/show_bug.cgi?id=183545
626
627         Reviewed by Yusuke Suzuki.
628         
629         This makes PerProcess<> safe by default, so we don't need SafePerProcess<>.
630         
631         The new PerProcess<> design relies on a hash-consing mechanism for PerProcess<> storage based
632         on the __PRETTY_FUNCTION__ from inside PerProcess<>, which captures the instantiated type in
633         the string. Therefore, this can be used to runtime-coalesce PerProcess<> instances based on
634         type.
635         
636         I expect this to be perf-neutral. It's an important prerequisite to more bmalloc work, since I
637         don't want to have more PerProcess<> vs SafePerProcess<> bugs, and SafePerProcess<> can't be
638         used for everything (I don't see how to use it for isoheaps).
639
640         * CMakeLists.txt:
641         * bmalloc.xcodeproj/project.pbxproj:
642         * bmalloc/Heap.cpp:
643         (bmalloc::Heap::Heap):
644         * bmalloc/IsoDirectoryInlines.h:
645         (bmalloc::passedNumPages>::takeFirstEligible):
646         (bmalloc::passedNumPages>::didBecome):
647         * bmalloc/PerProcess.cpp: Added.
648         (bmalloc::stringHash):
649         (bmalloc::allocate):
650         (bmalloc::getPerProcessData):
651         * bmalloc/PerProcess.h:
652         (bmalloc::PerProcess::mutex):
653         (bmalloc::PerProcess::coalesce):
654         (bmalloc::PerProcess::getSlowCase):
655         (): Deleted.
656         * bmalloc/Scavenger.cpp:
657         * bmalloc/Scavenger.h:
658         * bmalloc/bmalloc.cpp:
659         (bmalloc::api::scavenge):
660         (bmalloc::api::setScavengerThreadQOSClass):
661
662 2018-03-10  Commit Queue  <commit-queue@webkit.org>
663
664         Unreviewed, rolling out r229436.
665         https://bugs.webkit.org/show_bug.cgi?id=183542
666
667         seems to have regressed wasm compile times by 10% (Requested
668         by pizlo-mbp on #webkit).
669
670         Reverted changeset:
671
672         "bmalloc mutex should be adaptive"
673         https://bugs.webkit.org/show_bug.cgi?id=177839
674         https://trac.webkit.org/changeset/229436
675
676 2018-03-08  Filip Pizlo  <fpizlo@apple.com>
677
678         bmalloc mutex should be adaptive
679         https://bugs.webkit.org/show_bug.cgi?id=177839
680
681         Reviewed by Michael Saboff.
682         
683         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
684         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
685         anything other than malloc.
686
687         Reland after failing to reproduce the WasmBench crash that caused it to get rolled out. Maybe that fixed
688         itself somehow?
689
690         * bmalloc/Algorithm.h:
691         (bmalloc::compareExchangeWeak):
692         (bmalloc::compareExchangeStrong):
693         * bmalloc/PerThread.h:
694         * bmalloc/StaticMutex.cpp:
695         (bmalloc::StaticMutex::lockSlow):
696         (bmalloc::StaticMutex::unlockSlow):
697         (bmalloc::StaticMutex::lockSlowCase): Deleted.
698         * bmalloc/StaticMutex.h:
699         (bmalloc::StaticMutex::try_lock):
700         (bmalloc::StaticMutex::isLocked const):
701         (bmalloc::StaticMutex::init):
702         (bmalloc::StaticMutex::tryLock):
703         (bmalloc::StaticMutex::lock):
704         (bmalloc::StaticMutex::unlock):
705         (bmalloc::sleep): Deleted.
706         (bmalloc::waitUntilFalse): Deleted.
707
708 2018-02-16  Filip Pizlo  <fpizlo@apple.com>
709
710         Unreviewed, roll out r228306 (custom memcpy/memset) because the bots say that it was not a
711         progression.
712
713         * bmalloc/Algorithm.h:
714         (bmalloc::fastCopy): Deleted.
715         (bmalloc::fastZeroFill): Deleted.
716         * bmalloc/Allocator.cpp:
717         (bmalloc::Allocator::reallocate):
718         * bmalloc/Bits.h:
719         (bmalloc::BitsWordOwner::operator=):
720         (bmalloc::BitsWordOwner::clearAll):
721         (bmalloc::BitsWordOwner::set):
722         * bmalloc/IsoPageInlines.h:
723         (bmalloc::IsoPage<Config>::IsoPage):
724         * bmalloc/Vector.h:
725         (bmalloc::Vector<T>::reallocateBuffer):
726
727 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
728
729         Improve of string.h include after r228317.
730         https://bugs.webkit.org/show_bug.cgi?id=182642
731
732         Reviewed by Mark Lam.
733
734         * bmalloc/Algorithm.h: Avoid an architecture-specific #include.
735
736 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
737
738         Fix build for !BCPU(X86_64) after r228306
739         https://bugs.webkit.org/show_bug.cgi?id=182563
740
741         Unreviewed build fix.
742
743         * bmalloc/Algorithm.h:
744
745 2018-02-08  Filip Pizlo  <fpizlo@apple.com>
746
747         Experiment with alternative implementation of memcpy/memset
748         https://bugs.webkit.org/show_bug.cgi?id=182563
749
750         Reviewed by Michael Saboff and Mark Lam.
751         
752         Add a faster x86_64-specific implementation of memcpy and memset. Ideally, this would just be
753         implemented in WTF, but we have to copy it into bmalloc since bmalloc sits below WTF on the
754         stack.
755
756         * bmalloc/Algorithm.h:
757         (bmalloc::fastCopy):
758         (bmalloc::fastZeroFill):
759         * bmalloc/Allocator.cpp:
760         (bmalloc::Allocator::reallocate):
761         * bmalloc/Bits.h:
762         (bmalloc::BitsWordOwner::operator=):
763         (bmalloc::BitsWordOwner::clearAll):
764         (bmalloc::BitsWordOwner::set):
765         * bmalloc/IsoPageInlines.h:
766         (bmalloc::IsoPage<Config>::IsoPage):
767         * bmalloc/Vector.h:
768         (bmalloc::Vector<T>::reallocateBuffer):
769
770 2018-02-05  JF Bastien  <jfbastien@apple.com>
771
772         Gigacage: enable only for WebContent process and token executables
773         https://bugs.webkit.org/show_bug.cgi?id=182457
774         <rdar://problem/35875011>
775
776         Reviewed by Keith Miller.
777
778         Gigacage is a solid security improvement, but it's probably best
779         to roll it out incrementally to the most valuable targets first
780         and progressively try out more and more over time rather than
781         outright enabling it everywhere. We've gotten some reports that it
782         has some side-effects that weren't expected, so for now let's
783         enable it for the WebContent process, JSC, and other executables
784         we know, and then later we'll enable more gigacage uses.
785
786         For now I've chosen the following bundles:
787
788           - com.apple.WebKit.WebContent.Development
789           - com.apple.WebKit.WebContent
790           - com.apple.WebProcess
791
792         And the following processes:
793
794           - jsc
795           - wasm
796           - anything starting with "test", to match the JSC tests
797
798         I tried a different approach first, where I add a function to turn
799         gigacage on or off and crash if gigacage is initialized without
800         having been told what to do. Doing this in ChildProcess and a
801         bunch of the process initialization methods isn't sufficient. I
802         got MiniBrowser working, but some other builds use static globals
803         which themselves use hash and string which are allocate with
804         bmalloc and therefore which initialize gigacage before main is
805         called and before the process gets a chance to opt in our out. It
806         gets tricky with API calls too, because we have to do the right
807         thing in any entry an API user could plausibly use, even the
808         private ones, so I endend up having to initialize gigacage in e.g.
809         WebPreferencesExperimentalFeatures.cpp.erb.
810
811         Another approach could be to create a free-for-all gigacage
812         entitlement, and opt-in the processes we want..
813
814         As a follow-up we can also check that gigacage allocation always
815         succeeds if it was allowed for that process. With my change I
816         expect it to always succeed.
817
818         * CMakeLists.txt:
819         * bmalloc.xcodeproj/project.pbxproj:
820         * bmalloc/BPlatform.h:
821         * bmalloc/Gigacage.cpp:
822         (Gigacage::shouldBeEnabled):
823         * bmalloc/ProcessCheck.h: Added.
824         (bmalloc::gigacageEnabledForProcess):
825         * bmalloc/ProcessCheck.mm: Added.
826         (bmalloc::gigacageEnabledForProcess):
827
828 2018-02-05  Joseph Pecoraro  <pecoraro@apple.com>
829
830         Multiple bmalloc scavenger threads is unexpected
831         https://bugs.webkit.org/show_bug.cgi?id=182474
832         <rdar://problem/37175526>
833
834         Reviewed by Filip Pizlo.
835
836         * bmalloc/Heap.cpp:
837         (bmalloc::Heap::Heap):
838         * bmalloc/IsoDirectoryInlines.h:
839         (bmalloc::passedNumPages>::takeFirstEligible):
840         (bmalloc::passedNumPages>::didBecome):
841         * bmalloc/bmalloc.cpp:
842         (bmalloc::api::scavenge):
843         (bmalloc::api::setScavengerThreadQOSClass):
844         Switch to SafePerProcess for Scavenger to ensure one instance
845         for the entire process.
846
847         * bmalloc/PerProcess.h:
848         (bmalloc::PerProcess::get):
849         (bmalloc::PerProcess::getFastCase):
850         (bmalloc::PerProcess::getSlowCase):
851         (bmalloc::SafePerProcess::get):
852         (bmalloc::SafePerProcess::getFastCase):
853         (bmalloc::SafePerProcess::getSlowCase):
854         Duplicate the class with a version that can ensure
855         single instances by requiring exporting symbols that
856         can be created with macros.
857
858         * bmalloc/Scavenger.cpp:
859         * bmalloc/Scavenger.h:
860         Export symbols to ensure all images get the same instance.
861
862 2018-01-31  Saam Barati  <sbarati@apple.com>
863
864         Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
865         https://bugs.webkit.org/show_bug.cgi?id=182064
866         <rdar://problem/36840132>
867
868         Reviewed by Geoffrey Garen.
869
870         This patch replaces the tryLargeMemalignVirtual API with tryLargeZeroedMemalignVirtual.
871         By doing that, we're able to remove the AllocationKind enum. To zero the memory,
872         tryLargeZeroedMemalignVirtual uses mmap(... MAP_ANON ...) over previously mmapped
873         memory. This both purges the any resident memory for the virtual range and ensures
874         that the pages in the range are zeroed. Most OSs should implement this by taking a
875         page fault and zero filling on first access. Therefore, this API is returning pages
876         that will result in page faults on first access. Hence, the name 'virtual' in the API.
877         This API differs from the old API in that users of it need not call madvise themselves.
878         The memory is ready to go.
879
880         * bmalloc.xcodeproj/project.pbxproj:
881         * bmalloc/AllocationKind.h: Removed.
882         * bmalloc/DebugHeap.cpp:
883         (bmalloc::DebugHeap::memalignLarge):
884         (bmalloc::DebugHeap::freeLarge):
885         * bmalloc/DebugHeap.h:
886         * bmalloc/Heap.cpp:
887         (bmalloc::Heap::splitAndAllocate):
888         (bmalloc::Heap::tryAllocateLarge):
889         (bmalloc::Heap::allocateLarge):
890         (bmalloc::Heap::shrinkLarge):
891         (bmalloc::Heap::deallocateLarge):
892         * bmalloc/Heap.h:
893         * bmalloc/IsoPage.cpp:
894         (bmalloc::IsoPageBase::allocatePageMemory):
895         * bmalloc/VMAllocate.h:
896         (bmalloc::vmZeroAndPurge):
897         * bmalloc/VMHeap.cpp:
898         (bmalloc::VMHeap::tryAllocateLargeChunk):
899         * bmalloc/VMHeap.h:
900         * bmalloc/bmalloc.cpp:
901         (bmalloc::api::tryLargeZeroedMemalignVirtual):
902         (bmalloc::api::freeLargeVirtual):
903         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
904         * bmalloc/bmalloc.h:
905
906 2018-01-19  Keith Miller  <keith_miller@apple.com>
907
908         HaveInternalSDK includes should be "#include?"
909         https://bugs.webkit.org/show_bug.cgi?id=179670
910
911         Reviewed by Dan Bernstein.
912
913         * Configurations/Base.xcconfig:
914
915 2018-01-18  Dan Bernstein  <mitz@apple.com>
916
917         [Xcode] Streamline and future-proof target-macOS-version-dependent build setting definitions
918         https://bugs.webkit.org/show_bug.cgi?id=181803
919
920         Reviewed by Tim Horton.
921
922         * Configurations/Base.xcconfig: Updated.
923         * Configurations/DebugRelease.xcconfig: Ditto.
924
925 2018-01-16  Michael Catanzaro  <mcatanzaro@igalia.com>
926
927         mbmalloc should only be built in developer mode
928         https://bugs.webkit.org/show_bug.cgi?id=181654
929
930         Reviewed by Carlos Garcia Campos.
931
932         * CMakeLists.txt:
933
934 2018-01-15  Michael Catanzaro  <mcatanzaro@igalia.com>
935
936         Improve use of ExportMacros
937         https://bugs.webkit.org/show_bug.cgi?id=181652
938
939         Reviewed by Konstantin Tokarev.
940
941         Disable BEXPORT on Linux ports.
942
943         * bmalloc/BExport.h: Check for BUSE(EXPORT_MACROS).
944         * bmalloc/BPlatform.h: Add BUSE(EXPORT_MACROS) and define it on macOS and iOS.
945
946 2017-12-20  Ting-Wei Lan  <lantw44@gmail.com>
947
948         Include stdio.h before using stderr and _IONBF
949         https://bugs.webkit.org/show_bug.cgi?id=181046
950
951         Reviewed by Alex Christensen.
952
953         * bmalloc/IsoTLS.cpp:
954
955 2017-12-14  David Kilzer  <ddkilzer@apple.com>
956
957         Enable -Wstrict-prototypes for WebKit
958         <https://webkit.org/b/180757>
959         <rdar://problem/36024132>
960
961         Rubber-stamped by Joseph Pecoraro.
962
963         * Configurations/Base.xcconfig:
964         (CLANG_WARN_STRICT_PROTOTYPES): Add. Set to YES.
965
966 2017-12-14  Saam Barati  <sbarati@apple.com>
967
968         logVMFailure should not simulate crash on iOS
969         https://bugs.webkit.org/show_bug.cgi?id=180790
970
971         Reviewed by JF Bastien.
972
973         The Gigacage allocation on iOS is expected to fail in certain circumstances. 
974         Let's not simulate a crash on failure because since this is expected behavior.
975
976         * bmalloc/VMAllocate.h:
977         (bmalloc::tryVMAllocate):
978
979 2017-12-11  Tim Horton  <timothy_horton@apple.com>
980
981         Stop using deprecated target conditional for simulator builds
982         https://bugs.webkit.org/show_bug.cgi?id=180662
983         <rdar://problem/35136156>
984
985         Reviewed by Simon Fraser.
986
987         * bmalloc/BPlatform.h:
988
989 2017-12-08  Saam Barati  <sbarati@apple.com>
990
991         Enable gigacage on iOS with a 32GB runway and ensure it doesn't break WasmBench
992         https://bugs.webkit.org/show_bug.cgi?id=178557
993
994         Reviewed by Mark Lam.
995
996         * bmalloc/Algorithm.h:
997         (bmalloc::isPowerOfTwo):
998         * bmalloc/Gigacage.cpp:
999         * bmalloc/Gigacage.h:
1000
1001 2017-12-05  Andy Estes  <aestes@apple.com>
1002
1003         [Darwin] Simplify use of TargetConditionals
1004         https://bugs.webkit.org/show_bug.cgi?id=180455
1005         <rdar://problem/35142971>
1006
1007         Reviewed by Tim Horton.
1008
1009         There's no need to check if TARGET_* macros are defined on Darwin platforms, since
1010         TargetConditionals.h always defines them. Also, we can simplify
1011         (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE || TARGET_IPHONE_SIMULATOR) to TARGET_OS_IPHONE.
1012
1013         * bmalloc/BPlatform.h:
1014
1015 2017-12-05  Filip Pizlo  <fpizlo@apple.com>
1016
1017         bmalloc IsoHeap needs to allow a thread to deallocate some size for the first time
1018         https://bugs.webkit.org/show_bug.cgi?id=180443
1019
1020         Reviewed by Saam Barati.
1021
1022         It's true that we can expect a heap to already be initialized if we try to deallocate in it.  But it
1023         may not have its deallocator initialized on this thread yet.
1024         
1025         This is easily fixed by adding a null check on the deallocate path. That's probably not going to
1026         change perf at all. But doing that allows me to get rid of a lot of weird stuff I previously did to
1027         avoid that null check, like creating a dummy TLS in the DebugHeap case.
1028
1029         * bmalloc/IsoTLS.cpp:
1030         (bmalloc::IsoTLS::debugFree):
1031         (bmalloc::IsoTLS::deallocateSlow): Deleted.
1032         * bmalloc/IsoTLS.h:
1033         * bmalloc/IsoTLSInlines.h:
1034         (bmalloc::IsoTLS::allocateImpl):
1035         (bmalloc::IsoTLS::allocateSlow):
1036         (bmalloc::IsoTLS::deallocateImpl):
1037         (bmalloc::IsoTLS::deallocateSlow):
1038         (bmalloc::IsoTLS::ensureHeapAndEntries):
1039
1040 2017-12-01  Michael Saboff  <msaboff@apple.com>
1041
1042         Gigacage should not be enabled for ARM64_32
1043         https://bugs.webkit.org/show_bug.cgi?id=180265
1044
1045         Reviewed by Saam Barati.
1046
1047         Disabled Gigacage for ARM64_32.
1048         In the process, restructured Gigacage::shouldBeEnabled() with GIGACAGE_ENABLED set
1049         to 0 to avoid a dead code compiler warning.
1050
1051         * bmalloc/Gigacage.cpp:
1052         (Gigacage::shouldBeEnabled):
1053         * bmalloc/Gigacage.h:
1054
1055 2017-11-29  JF Bastien  <jfbastien@apple.com>
1056
1057         WTF / bmalloc: don't write to 0xbbadbeef when ASAN is looking
1058         https://bugs.webkit.org/show_bug.cgi?id=180175
1059
1060         Reviewed by Mark Lam.
1061
1062         ASAN knows that 0xbbadbeef is a bbad aaddress, and tells us so
1063         when we write to it, say in an assert. That creates bbad error
1064         reports where ASAN thinks we write to an invalid address, instead
1065         of thinking that we hit an assertion. In some cases, tooling that
1066         use fuzzers aggregate similar issues, and think that we just have
1067         the one bug and not a bunch of different asserts.
1068
1069         At the same time, bmalloc's version of CRASH just writes to
1070         0xbbadbeef and assumes that's invalid and will crash, which isn't
1071         necessarily true on non-Mac platforms. WTF's version then makes
1072         sure there's a crash, so bmalloc should do the same.
1073
1074         * bmalloc.xcodeproj/project.pbxproj:
1075         * bmalloc/BAssert.h:
1076         * bmalloc/BCompiler.h: Added.
1077         * bmalloc/BPlatform.h:
1078
1079 2017-11-27  Filip Pizlo  <fpizlo@apple.com>
1080
1081         Don't crash in forEachEntry when DebugHeap is enabled.
1082
1083         Unreviewed, fixing crashes on leaks bots by removing an assertion.
1084
1085         * bmalloc/IsoTLS.cpp:
1086         (bmalloc::IsoTLS::forEachEntry):
1087         * test/testbmalloc.cpp: Make this test work with DebugHeap so I can catch this kind of problem in the future.
1088
1089 2017-11-16  Filip Pizlo  <fpizlo@apple.com>
1090
1091         Isolated Heaps caused an increase in reported leaks on the bots
1092         https://bugs.webkit.org/show_bug.cgi?id=179463
1093
1094         Reviewed by Darin Adler.
1095         
1096         This fixes the way isoheaps interact with system tools:
1097         
1098         - Opts into the VMHeap API so that the leaks tool can find isoheap memory.
1099         
1100         - Opts into the DebugHeap/Environment APIs so that we turn off isoheap allocation if memory
1101           debugging options are in use.
1102
1103         * bmalloc.xcodeproj/project.pbxproj:
1104         * bmalloc/DebugHeap.h:
1105         * bmalloc/IsoHeap.h:
1106         * bmalloc/IsoPage.cpp: Added.
1107         (bmalloc::IsoPageBase::allocatePageMemory):
1108         * bmalloc/IsoPage.h:
1109         * bmalloc/IsoPageInlines.h:
1110         (bmalloc::IsoPage<Config>::tryCreate):
1111         * bmalloc/IsoTLS.cpp:
1112         (bmalloc::IsoTLS::deallocateSlow):
1113         (bmalloc::IsoTLS::ensureEntries):
1114         (bmalloc::IsoTLS::isUsingDebugHeap):
1115         (bmalloc::IsoTLS::debugMalloc):
1116         * bmalloc/IsoTLS.h:
1117         * bmalloc/IsoTLSInlines.h:
1118         (bmalloc::IsoTLS::allocate):
1119         (bmalloc::IsoTLS::deallocate):
1120         (bmalloc::IsoTLS::allocateImpl):
1121         (bmalloc::IsoTLS::allocateFast):
1122         (bmalloc::IsoTLS::allocateSlow):
1123         (bmalloc::IsoTLS::deallocateImpl):
1124         (bmalloc::IsoTLS::deallocateFast):
1125         (bmalloc::IsoTLS::ensureHeapAndEntries):
1126         (bmalloc::IsoTLS::allocator): Deleted.
1127         (bmalloc::IsoTLS::deallocator): Deleted.
1128         * bmalloc/bmalloc.cpp:
1129         (bmalloc::api::tryLargeMemalignVirtual):
1130         (bmalloc::api::freeLargeVirtual):
1131         (bmalloc::api::scavenge):
1132         (bmalloc::api::isEnabled):
1133         (bmalloc::api::setScavengerThreadQOSClass):
1134         * bmalloc/bmalloc.h:
1135         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
1136         (bmalloc::api::freeLargeVirtual): Deleted.
1137         (bmalloc::api::scavenge): Deleted.
1138         (bmalloc::api::isEnabled): Deleted.
1139         (bmalloc::api::setScavengerThreadQOSClass): Deleted.
1140
1141 2017-11-14  Saam Barati  <sbarati@apple.com>
1142
1143         Make the gigacage runway 32GB
1144         https://bugs.webkit.org/show_bug.cgi?id=175062
1145
1146         Reviewed by Mark Lam.
1147
1148         Making the gigacage runway 32GB defends us against buffer overflows in the
1149         cage reaching memory outside the cage assuming indices are 32-bit unsigned
1150         integers and the type they're indexing into has size <= 8 bytes. This is
1151         exactly the case for many things in JSC. For example, butterfly access in
1152         JSC meet this criteria, as does typed array access.
1153         
1154         The 32GB comes from 8 * 2^32 = 32GB.
1155
1156         * bmalloc/Gigacage.cpp:
1157
1158 2017-11-08  Michael Catanzaro  <mcatanzaro@igalia.com>
1159
1160         Gigacage.cpp:44:46: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
1161         https://bugs.webkit.org/show_bug.cgi?id=179427
1162
1163         Reviewed by Saam Barati.
1164
1165         Tweak the conditional to suppress the warning.
1166
1167         * bmalloc/Gigacage.cpp:
1168         (Gigacage::ensureGigacage):
1169
1170 2017-11-07  Saam Barati  <sbarati@apple.com>
1171
1172         We should PROT_NONE the Gigacage runway so OOB accesses crash
1173         https://bugs.webkit.org/show_bug.cgi?id=179392
1174
1175         Reviewed by Mark Lam.
1176
1177         If we assume that an attacker will exploit JSC and cause OOB accesses,
1178         we should make OOB accesses in the Gigacage runway crash.
1179
1180         * bmalloc/Gigacage.cpp:
1181         (Gigacage::ensureGigacage):
1182
1183 2017-10-31  Filip Pizlo  <fpizlo@apple.com>
1184
1185         bmalloc should support strictly type-segregated isolated heaps
1186         https://bugs.webkit.org/show_bug.cgi?id=178108
1187
1188         Reviewed by Saam Barati, Simon Fraser, and Ryosuke Niwa.
1189         
1190         This introduces a new allocation API in bmalloc called IsoHeap. An IsoHeap is templatized by
1191         type and created in static storage. When unused, it takes only a few words. When you do use
1192         it, each IsoHeap gets a bag of virtual pages unique to it. This prevents use-after-free bugs
1193         in one IsoHeap from affecting any other memory. At worst, two pointers of the same type will
1194         point to the same object even though they should not have.
1195         
1196         IsoHeaps allocate using a first-fit discipline that combines ideas from bmalloc and Riptide
1197         (the JSC GC):
1198         
1199         Like Riptide, it uses a bump'n'pop allocator. What Riptide calls blocks, IsoHeaps calls
1200         pages. Pages are collected into directories. Directories track pages using bitvectors, so
1201         that it's easy to quickly find a completely free page or one that has at least one free
1202         object. I think that the bump'n'pop allocator is as fast as the bmalloc Immix-style (page and
1203         line) allocator, but is better at allocating in holes. It's guaranteed to follow a first-fit
1204         discipline. However, the real reason why I wrote it that was is that this is what I'm more
1205         familiar with. This is a part of the design I want to revisit (bug 179278).
1206         
1207         Like bmalloc, it uses a deallocation log. This means that the internal IsoHeap data
1208         structures can be locked with a coarse-grained lock, since the deallocator only grabs it when
1209         flushing the log. Similarly, the allocator only grabs it when refilling the bump'n'pop
1210         FreeList.
1211         
1212         This adds a unit test for IsoHeaps. In this change, IsoHeaps are adopted only by WebCore's
1213         RenderObject.
1214         
1215         Note that despite the use of GC concepts, it's not a goal to make this code directly sharable
1216         with GC. The GC will probably have to do isolated heaps its own way (likely a special
1217         Subspace or something like that).
1218
1219         * bmalloc.xcodeproj/project.pbxproj:
1220         * bmalloc/Algorithm.h:
1221         (bmalloc::findBitInWord):
1222         * bmalloc/AllIsoHeaps.cpp: Added.
1223         (bmalloc::AllIsoHeaps::AllIsoHeaps):
1224         (bmalloc::AllIsoHeaps::add):
1225         (bmalloc::AllIsoHeaps::head):
1226         * bmalloc/AllIsoHeaps.h: Added.
1227         * bmalloc/AllIsoHeapsInlines.h: Added.
1228         (bmalloc::AllIsoHeaps::forEach):
1229         * bmalloc/BMalloced.h: Added.
1230         * bmalloc/Bits.h: Added.
1231         (bmalloc::bitsArrayLength):
1232         (bmalloc::BitsWordView::BitsWordView):
1233         (bmalloc::BitsWordView::numBits const):
1234         (bmalloc::BitsWordView::word const):
1235         (bmalloc::BitsWordOwner::BitsWordOwner):
1236         (bmalloc::BitsWordOwner::view const):
1237         (bmalloc::BitsWordOwner::operator=):
1238         (bmalloc::BitsWordOwner::setAll):
1239         (bmalloc::BitsWordOwner::clearAll):
1240         (bmalloc::BitsWordOwner::set):
1241         (bmalloc::BitsWordOwner::numBits const):
1242         (bmalloc::BitsWordOwner::arrayLength const):
1243         (bmalloc::BitsWordOwner::word const):
1244         (bmalloc::BitsWordOwner::word):
1245         (bmalloc::BitsWordOwner::words const):
1246         (bmalloc::BitsWordOwner::words):
1247         (bmalloc::BitsAndWords::BitsAndWords):
1248         (bmalloc::BitsAndWords::view const):
1249         (bmalloc::BitsAndWords::numBits const):
1250         (bmalloc::BitsAndWords::word const):
1251         (bmalloc::BitsOrWords::BitsOrWords):
1252         (bmalloc::BitsOrWords::view const):
1253         (bmalloc::BitsOrWords::numBits const):
1254         (bmalloc::BitsOrWords::word const):
1255         (bmalloc::BitsNotWords::BitsNotWords):
1256         (bmalloc::BitsNotWords::view const):
1257         (bmalloc::BitsNotWords::numBits const):
1258         (bmalloc::BitsNotWords::word const):
1259         (bmalloc::BitsImpl::BitsImpl):
1260         (bmalloc::BitsImpl::numBits const):
1261         (bmalloc::BitsImpl::size const):
1262         (bmalloc::BitsImpl::arrayLength const):
1263         (bmalloc::BitsImpl::operator== const):
1264         (bmalloc::BitsImpl::operator!= const):
1265         (bmalloc::BitsImpl::at const):
1266         (bmalloc::BitsImpl::operator[] const):
1267         (bmalloc::BitsImpl::isEmpty const):
1268         (bmalloc::BitsImpl::operator& const):
1269         (bmalloc::BitsImpl::operator| const):
1270         (bmalloc::BitsImpl::operator~ const):
1271         (bmalloc::BitsImpl::forEachSetBit const):
1272         (bmalloc::BitsImpl::forEachClearBit const):
1273         (bmalloc::BitsImpl::forEachBit const):
1274         (bmalloc::BitsImpl::findBit const):
1275         (bmalloc::BitsImpl::findSetBit const):
1276         (bmalloc::BitsImpl::findClearBit const):
1277         (bmalloc::BitsImpl::wordView const):
1278         (bmalloc::BitsImpl::atImpl const):
1279         (bmalloc::Bits::Bits):
1280         (bmalloc::Bits::operator=):
1281         (bmalloc::Bits::resize):
1282         (bmalloc::Bits::setAll):
1283         (bmalloc::Bits::clearAll):
1284         (bmalloc::Bits::setAndCheck):
1285         (bmalloc::Bits::operator|=):
1286         (bmalloc::Bits::operator&=):
1287         (bmalloc::Bits::at const):
1288         (bmalloc::Bits::operator[] const):
1289         (bmalloc::Bits::BitReference::BitReference):
1290         (bmalloc::Bits::BitReference::operator bool const):
1291         (bmalloc::Bits::BitReference::operator=):
1292         (bmalloc::Bits::at):
1293         (bmalloc::Bits::operator[]):
1294         * bmalloc/CryptoRandom.cpp: Replaced with Source/bmalloc/bmalloc/CryptoRandom.cpp.
1295         (bmalloc::cryptoRandom):
1296         * bmalloc/CryptoRandom.h: Replaced with Source/bmalloc/bmalloc/CryptoRandom.h.
1297         * bmalloc/DeferredDecommit.h: Added.
1298         * bmalloc/DeferredDecommitInlines.h: Added.
1299         (bmalloc::DeferredDecommit::DeferredDecommit):
1300         * bmalloc/DeferredTrigger.h: Added.
1301         (bmalloc::DeferredTrigger::DeferredTrigger):
1302         * bmalloc/DeferredTriggerInlines.h: Added.
1303         (bmalloc::DeferredTrigger<trigger>::didBecome):
1304         (bmalloc::DeferredTrigger<trigger>::handleDeferral):
1305         * bmalloc/EligibilityResult.h: Added.
1306         (bmalloc::EligibilityResult::EligibilityResult):
1307         * bmalloc/EligibilityResultInlines.h: Added.
1308         (bmalloc::EligibilityResult<Config>::EligibilityResult):
1309         * bmalloc/FixedVector.h:
1310         * bmalloc/FreeList.cpp: Added.
1311         (bmalloc::FreeList::FreeList):
1312         (bmalloc::FreeList::~FreeList):
1313         (bmalloc::FreeList::clear):
1314         (bmalloc::FreeList::initializeList):
1315         (bmalloc::FreeList::initializeBump):
1316         (bmalloc::FreeList::contains const):
1317         * bmalloc/FreeList.h: Added.
1318         (bmalloc::FreeCell::scramble):
1319         (bmalloc::FreeCell::descramble):
1320         (bmalloc::FreeCell::setNext):
1321         (bmalloc::FreeCell::next const):
1322         (bmalloc::FreeList::allocationWillFail const):
1323         (bmalloc::FreeList::allocationWillSucceed const):
1324         (bmalloc::FreeList::originalSize const):
1325         (bmalloc::FreeList::head const):
1326         * bmalloc/FreeListInlines.h: Added.
1327         (bmalloc::FreeList::allocate):
1328         (bmalloc::FreeList::forEach const):
1329         * bmalloc/IsoAllocator.h: Added.
1330         * bmalloc/IsoAllocatorInlines.h: Added.
1331         (bmalloc::IsoAllocator<Config>::IsoAllocator):
1332         (bmalloc::IsoAllocator<Config>::~IsoAllocator):
1333         (bmalloc::IsoAllocator<Config>::allocate):
1334         (bmalloc::IsoAllocator<Config>::allocateSlow):
1335         (bmalloc::IsoAllocator<Config>::scavenge):
1336         * bmalloc/IsoConfig.h: Added.
1337         * bmalloc/IsoDeallocator.h: Added.
1338         * bmalloc/IsoDeallocatorInlines.h: Added.
1339         (bmalloc::IsoDeallocator<Config>::IsoDeallocator):
1340         (bmalloc::IsoDeallocator<Config>::~IsoDeallocator):
1341         (bmalloc::IsoDeallocator<Config>::deallocate):
1342         (bmalloc::IsoDeallocator<Config>::scavenge):
1343         * bmalloc/IsoDirectory.h: Added.
1344         (bmalloc::IsoDirectoryBaseBase::IsoDirectoryBaseBase):
1345         (bmalloc::IsoDirectoryBaseBase::~IsoDirectoryBaseBase):
1346         (bmalloc::IsoDirectoryBase::heap):
1347         * bmalloc/IsoDirectoryInlines.h: Added.
1348         (bmalloc::IsoDirectoryBase<Config>::IsoDirectoryBase):
1349         (bmalloc::passedNumPages>::IsoDirectory):
1350         (bmalloc::passedNumPages>::takeFirstEligible):
1351         (bmalloc::passedNumPages>::didBecome):
1352         (bmalloc::passedNumPages>::didDecommit):
1353         (bmalloc::passedNumPages>::scavenge):
1354         (bmalloc::passedNumPages>::forEachCommittedPage):
1355         * bmalloc/IsoDirectoryPage.h: Added.
1356         (bmalloc::IsoDirectoryPage::index const):
1357         * bmalloc/IsoDirectoryPageInlines.h: Added.
1358         (bmalloc::IsoDirectoryPage<Config>::IsoDirectoryPage):
1359         (bmalloc::IsoDirectoryPage<Config>::pageFor):
1360         * bmalloc/IsoHeap.h: Added.
1361         (bmalloc::api::IsoHeap::allocatorOffset):
1362         (bmalloc::api::IsoHeap::setAllocatorOffset):
1363         (bmalloc::api::IsoHeap::deallocatorOffset):
1364         (bmalloc::api::IsoHeap::setDeallocatorOffset):
1365         * bmalloc/IsoHeapImpl.cpp: Added.
1366         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
1367         (bmalloc::IsoHeapImplBase::~IsoHeapImplBase):
1368         (bmalloc::IsoHeapImplBase::scavengeNow):
1369         (bmalloc::IsoHeapImplBase::finishScavenging):
1370         * bmalloc/IsoHeapImpl.h: Added.
1371         * bmalloc/IsoHeapImplInlines.h: Added.
1372         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
1373         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
1374         (bmalloc::IsoHeapImpl<Config>::didBecomeEligible):
1375         (bmalloc::IsoHeapImpl<Config>::scavenge):
1376         (bmalloc::IsoHeapImpl<Config>::allocatorOffset):
1377         (bmalloc::IsoHeapImpl<Config>::deallocatorOffset):
1378         (bmalloc::IsoHeapImpl<Config>::numLiveObjects):
1379         (bmalloc::IsoHeapImpl<Config>::numCommittedPages):
1380         (bmalloc::IsoHeapImpl<Config>::forEachDirectory):
1381         (bmalloc::IsoHeapImpl<Config>::forEachCommittedPage):
1382         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
1383         * bmalloc/IsoHeapInlines.h: Added.
1384         (bmalloc::api::IsoHeap<Type>::allocate):
1385         (bmalloc::api::IsoHeap<Type>::tryAllocate):
1386         (bmalloc::api::IsoHeap<Type>::deallocate):
1387         (bmalloc::api::IsoHeap<Type>::scavenge):
1388         (bmalloc::api::IsoHeap<Type>::isInitialized):
1389         (bmalloc::api::IsoHeap<Type>::impl):
1390         * bmalloc/IsoPage.h: Added.
1391         (bmalloc::IsoPage::index const):
1392         (bmalloc::IsoPage::directory):
1393         (bmalloc::IsoPage::isInUseForAllocation const):
1394         (bmalloc::IsoPage::indexOfFirstObject):
1395         * bmalloc/IsoPageInlines.h: Added.
1396         (bmalloc::IsoPage<Config>::tryCreate):
1397         (bmalloc::IsoPage<Config>::IsoPage):
1398         (bmalloc::IsoPage<Config>::free):
1399         (bmalloc::IsoPage<Config>::startAllocating):
1400         (bmalloc::IsoPage<Config>::stopAllocating):
1401         (bmalloc::IsoPage<Config>::forEachLiveObject):
1402         * bmalloc/IsoPageTrigger.h: Added.
1403         * bmalloc/IsoTLS.cpp: Added.
1404         (bmalloc::IsoTLS::scavenge):
1405         (bmalloc::IsoTLS::IsoTLS):
1406         (bmalloc::IsoTLS::ensureEntries):
1407         (bmalloc::IsoTLS::destructor):
1408         (bmalloc::IsoTLS::sizeForCapacity):
1409         (bmalloc::IsoTLS::capacityForSize):
1410         (bmalloc::IsoTLS::size):
1411         (bmalloc::IsoTLS::forEachEntry):
1412         * bmalloc/IsoTLS.h: Added.
1413         * bmalloc/IsoTLSAllocatorEntry.h: Added.
1414         * bmalloc/IsoTLSAllocatorEntryInlines.h: Added.
1415         (bmalloc::IsoTLSAllocatorEntry<Config>::IsoTLSAllocatorEntry):
1416         (bmalloc::IsoTLSAllocatorEntry<Config>::~IsoTLSAllocatorEntry):
1417         (bmalloc::IsoTLSAllocatorEntry<Config>::construct):
1418         * bmalloc/IsoTLSDeallocatorEntry.h: Added.
1419         * bmalloc/IsoTLSDeallocatorEntryInlines.h: Added.
1420         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
1421         (bmalloc::IsoTLSDeallocatorEntry<Config>::~IsoTLSDeallocatorEntry):
1422         (bmalloc::IsoTLSDeallocatorEntry<Config>::construct):
1423         * bmalloc/IsoTLSEntry.cpp: Added.
1424         (bmalloc::IsoTLSEntry::IsoTLSEntry):
1425         (bmalloc::IsoTLSEntry::~IsoTLSEntry):
1426         * bmalloc/IsoTLSEntry.h: Added.
1427         (bmalloc::IsoTLSEntry::offset const):
1428         (bmalloc::IsoTLSEntry::alignment const):
1429         (bmalloc::IsoTLSEntry::size const):
1430         (bmalloc::IsoTLSEntry::extent const):
1431         * bmalloc/IsoTLSEntryInlines.h: Added.
1432         (bmalloc::IsoTLSEntry::walkUpToInclusive):
1433         (bmalloc::DefaultIsoTLSEntry<EntryType>::DefaultIsoTLSEntry):
1434         (bmalloc::DefaultIsoTLSEntry<EntryType>::~DefaultIsoTLSEntry):
1435         (bmalloc::DefaultIsoTLSEntry<EntryType>::move):
1436         (bmalloc::DefaultIsoTLSEntry<EntryType>::destruct):
1437         (bmalloc::DefaultIsoTLSEntry<EntryType>::scavenge):
1438         * bmalloc/IsoTLSInlines.h: Added.
1439         (bmalloc::IsoTLS::allocate):
1440         (bmalloc::IsoTLS::deallocate):
1441         (bmalloc::IsoTLS::scavenge):
1442         (bmalloc::IsoTLS::allocator):
1443         (bmalloc::IsoTLS::deallocator):
1444         (bmalloc::IsoTLS::get):
1445         (bmalloc::IsoTLS::set):
1446         (bmalloc::IsoTLS::ensureHeap):
1447         (bmalloc::IsoTLS::ensureHeapAndEntries):
1448         * bmalloc/IsoTLSLayout.cpp: Added.
1449         (bmalloc::IsoTLSLayout::IsoTLSLayout):
1450         (bmalloc::IsoTLSLayout::add):
1451         * bmalloc/IsoTLSLayout.h: Added.
1452         (bmalloc::IsoTLSLayout::head const):
1453         * bmalloc/PerHeapKind.h:
1454         * bmalloc/PerProcess.h:
1455         (bmalloc::PerProcess<T>::getFastCase):
1456         * bmalloc/Scavenger.cpp:
1457         (bmalloc::Scavenger::scavenge):
1458         * bmalloc/Scavenger.h:
1459         * bmalloc/bmalloc.h:
1460         (bmalloc::api::scavengeThisThread):
1461         * test: Added.
1462         * test/testbmalloc.cpp: Added.
1463         (hiddenTruthBecauseNoReturnIsStupid):
1464         (usage):
1465         (assertEmptyPointerSet):
1466         (assertHasObjects):
1467         (assertHasOnlyObjects):
1468         (assertClean):
1469         (testIsoSimple):
1470         (testIsoSimpleScavengeBeforeDealloc):
1471         (testIsoFlipFlopFragmentedPages):
1472         (testIsoFlipFlopFragmentedPagesScavengeInMiddle):
1473         (BisoMalloced::BisoMalloced):
1474         (testBisoMalloced):
1475         (BisoMallocedInline::BisoMallocedInline):
1476         (testBisoMallocedInline):
1477         (run):
1478         (main):
1479
1480 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
1481
1482         [ARM64][Linux] Re-enable Gigacage
1483         https://bugs.webkit.org/show_bug.cgi?id=178130
1484
1485         Reviewed by Michael Catanzaro.
1486
1487         * bmalloc/Gigacage.h: Re-enable Gigacage on ARM64 Linux.
1488
1489 2017-10-25  Commit Queue  <commit-queue@webkit.org>
1490
1491         Unreviewed, rolling out r222945.
1492         https://bugs.webkit.org/show_bug.cgi?id=178818
1493
1494         "It made WasmBench crash" (Requested by saamyjoon on #webkit).
1495
1496         Reverted changeset:
1497
1498         "bmalloc mutex should be adaptive"
1499         https://bugs.webkit.org/show_bug.cgi?id=177839
1500         https://trac.webkit.org/changeset/222945
1501
1502 2017-10-24  Zan Dobersek  <zdobersek@igalia.com>
1503
1504         [Linux] Enable Gigacage in x64 Linux environment
1505         https://bugs.webkit.org/show_bug.cgi?id=177745
1506         <rdar://problem/34773148>
1507
1508         Reviewed by Yusuke Suzuki.
1509
1510         Re-enable Gigacage on x86_64 Linux platforms after it was disabled in 223877.
1511
1512         The cause for the revert was problems with huge coredumps being generated
1513         while Gigacage was enabled. The feature virtually allocates about 80GB of
1514         memory at the beginning of the process lifetime. This is not a problem in
1515         itself since the memory range is marked as not needed through madvise(),
1516         but all this memory was still included upon core dump generation on Linux.
1517         Since there are reasonable limits enforced upon core dumps, these were
1518         being truncated every time, not yielding any useful information.
1519
1520         To avoid this, on Linux, invocations of madvise() with the MADV_NORMAL and
1521         MADV_DONTNEED advice parameters should be accompanied with respectively
1522         matching MADV_DODUMP and MADV_DONTDUMP madvise() calls. This correctly
1523         avoids core-dumping any memory that's not yet been physically allocated.
1524
1525         * bmalloc/Gigacage.h:
1526         * bmalloc/VMAllocate.h:
1527         (bmalloc::vmDeallocatePhysicalPages):
1528         (bmalloc::vmAllocatePhysicalPages):
1529
1530 2017-10-24  David Kilzer  <ddkilzer@apple.com>
1531
1532         Need to pass non-nil argument to SimulateCrash() in bmalloc::logVMFailure()
1533         <https://webkit.org/b/178740>
1534         <rdar://problem/35154943>
1535
1536         Reviewed by Saam Barati.
1537
1538         * bmalloc/BPlatform.h:
1539         (BUNUSED_PARAM): Define macro.
1540         * bmalloc/Logging.cpp:
1541         (SimulateCrash): Change third argument of SimulateCrash() to
1542         CFStringRef since it's an NSString * in Objective-C.
1543         (bmalloc::logVMFailure): Create a CFStringRef to use as a
1544         description string.  Use new vmSize parameter to log size.
1545         * bmalloc/Logging.h:
1546         (bmalloc::logVMFailure): Update function signature to take a
1547         size_t parameter representing vmSize.
1548         * bmalloc/VMAllocate.h:
1549         (bmalloc::tryVMAllocate): Pass vmSize into logVMFailure().
1550
1551 2017-10-23  Michael Catanzaro  <mcatanzaro@igalia.com>
1552
1553         Unreviewed, roll out r222731
1554         https://bugs.webkit.org/show_bug.cgi?id=177745
1555         <rdar://problem/34773148>
1556
1557         Unfortunately Gigacage has broken core dump generation.
1558
1559         * bmalloc/Gigacage.h:
1560
1561 2017-10-23  Zan Dobersek  <zdobersek@igalia.com>
1562
1563         bmalloc::api::tryLargeMemalignVirtual() shouldn't assert on a failed allocation
1564         https://bugs.webkit.org/show_bug.cgi?id=178654
1565
1566         Reviewed by Geoffrey Garen.
1567
1568         * bmalloc/bmalloc.h:
1569         (bmalloc::api::tryLargeMemalignVirtual): Call Heap::tryAllocateLarge()
1570         instead of Heap::allocateLarge(). The former will return a null pointer
1571         upon a failed allocation, allowing the caller to fail gracefully just as
1572         the API entrypoint implies, while the latter currently provokes a crash
1573         in these circumstances.
1574
1575 2017-10-19  Saam Barati  <sbarati@apple.com>
1576
1577         Runtime disable gigacage on iOS because it broke WasmBench
1578         https://bugs.webkit.org/show_bug.cgi?id=178556
1579
1580         Reviewed by Keith Miller.
1581
1582         * bmalloc/Gigacage.cpp:
1583         (Gigacage::shouldBeEnabled):
1584
1585 2017-10-17  Filip Pizlo  <fpizlo@apple.com>
1586
1587         You can't vmDeallocate null
1588         <rdar://problem/35038926>
1589
1590         Reviewed by Michael Saboff.
1591         
1592         After failing allocation, we would try to deallocate the thing we failed to allocate. The fix is to
1593         not try to deallocate something that is obviously null.
1594
1595         * bmalloc/Gigacage.cpp:
1596         (Gigacage::ensureGigacage):
1597
1598 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1599
1600         Enable gigacage on iOS
1601         https://bugs.webkit.org/show_bug.cgi?id=177586
1602
1603         Reviewed by JF Bastien.
1604         
1605         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1606         allocation fails, we free all of the gigacages and turn off gigacage support.
1607         
1608         Roll this back in after discussion.
1609
1610         * CMakeLists.txt:
1611         * bmalloc.xcodeproj/project.pbxproj:
1612         * bmalloc/Cache.cpp:
1613         (bmalloc::Cache::scavenge):
1614         * bmalloc/Cache.h:
1615         (bmalloc::Cache::tryAllocate):
1616         (bmalloc::Cache::allocate):
1617         (bmalloc::Cache::deallocate):
1618         (bmalloc::Cache::reallocate):
1619         * bmalloc/Gigacage.cpp:
1620         (Gigacage::ensureGigacage):
1621         (Gigacage::runway):
1622         (Gigacage::totalSize):
1623         (Gigacage::shouldBeEnabled):
1624         (): Deleted.
1625         (Gigacage::Callback::Callback): Deleted.
1626         (Gigacage::Callback::function): Deleted.
1627         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1628         * bmalloc/Gigacage.h:
1629         (Gigacage::wasEnabled):
1630         (Gigacage::isEnabled):
1631         (Gigacage::runway): Deleted.
1632         (Gigacage::totalSize): Deleted.
1633         * bmalloc/HeapKind.cpp: Added.
1634         (bmalloc::isActiveHeapKind):
1635         (bmalloc::mapToActiveHeapKind):
1636         * bmalloc/HeapKind.h:
1637         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1638         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1639         * bmalloc/Scavenger.cpp:
1640         (bmalloc::Scavenger::scavenge):
1641         * bmalloc/bmalloc.h:
1642         (bmalloc::api::tryLargeMemalignVirtual):
1643         (bmalloc::api::freeLargeVirtual):
1644         (bmalloc::api::isEnabled):
1645
1646 2017-10-11  Commit Queue  <commit-queue@webkit.org>
1647
1648         Unreviewed, rolling out r223113 and r223121.
1649         https://bugs.webkit.org/show_bug.cgi?id=178182
1650
1651         Reintroduced 20% regression on Kraken (Requested by rniwa on
1652         #webkit).
1653
1654         Reverted changesets:
1655
1656         "Enable gigacage on iOS"
1657         https://bugs.webkit.org/show_bug.cgi?id=177586
1658         https://trac.webkit.org/changeset/223113
1659
1660         "Use one virtual allocation for all gigacages and their
1661         runways"
1662         https://bugs.webkit.org/show_bug.cgi?id=178050
1663         https://trac.webkit.org/changeset/223121
1664
1665 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
1666
1667         Use one virtual allocation for all gigacages and their runways
1668         https://bugs.webkit.org/show_bug.cgi?id=178050
1669
1670         Reviewed by Saam Barati.
1671
1672         * bmalloc/Gigacage.cpp:
1673         (Gigacage::ensureGigacage):
1674         (Gigacage::runway): Deleted.
1675         (Gigacage::totalSize): Deleted.
1676         * bmalloc/Gigacage.h:
1677
1678 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1679
1680         Enable gigacage on iOS
1681         https://bugs.webkit.org/show_bug.cgi?id=177586
1682
1683         Reviewed by JF Bastien.
1684         
1685         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1686         allocation fails, we free all of the gigacages and turn off gigacage support.
1687         
1688         Reland this after confirming that the 20% Kraken regression was a one-bot fluke. Local testing on the
1689         same kind of system did not show the regression. Saam and I both tried independently.
1690
1691         * CMakeLists.txt:
1692         * bmalloc.xcodeproj/project.pbxproj:
1693         * bmalloc/Cache.cpp:
1694         (bmalloc::Cache::scavenge):
1695         * bmalloc/Cache.h:
1696         (bmalloc::Cache::tryAllocate):
1697         (bmalloc::Cache::allocate):
1698         (bmalloc::Cache::deallocate):
1699         (bmalloc::Cache::reallocate):
1700         * bmalloc/Gigacage.cpp:
1701         (Gigacage::ensureGigacage):
1702         (Gigacage::runway):
1703         (Gigacage::totalSize):
1704         (Gigacage::shouldBeEnabled):
1705         (): Deleted.
1706         (Gigacage::Callback::Callback): Deleted.
1707         (Gigacage::Callback::function): Deleted.
1708         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1709         * bmalloc/Gigacage.h:
1710         (Gigacage::wasEnabled):
1711         (Gigacage::isEnabled):
1712         (Gigacage::runway): Deleted.
1713         (Gigacage::totalSize): Deleted.
1714         * bmalloc/HeapKind.cpp: Added.
1715         (bmalloc::isActiveHeapKind):
1716         (bmalloc::mapToActiveHeapKind):
1717         * bmalloc/HeapKind.h:
1718         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1719         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1720         * bmalloc/Scavenger.cpp:
1721         (bmalloc::Scavenger::scavenge):
1722         * bmalloc/bmalloc.h:
1723         (bmalloc::api::tryLargeMemalignVirtual):
1724         (bmalloc::api::freeLargeVirtual):
1725         (bmalloc::api::isEnabled):
1726
1727 2017-10-09  Commit Queue  <commit-queue@webkit.org>
1728
1729         Unreviewed, rolling out r223015 and r223025.
1730         https://bugs.webkit.org/show_bug.cgi?id=178093
1731
1732         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
1733         #webkit).
1734
1735         Reverted changesets:
1736
1737         "Enable gigacage on iOS"
1738         https://bugs.webkit.org/show_bug.cgi?id=177586
1739         http://trac.webkit.org/changeset/223015
1740
1741         "Unreviewed, disable Gigacage on ARM64 Linux"
1742         https://bugs.webkit.org/show_bug.cgi?id=177586
1743         http://trac.webkit.org/changeset/223025
1744
1745 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1746
1747         Unreviewed, disable Gigacage on ARM64 Linux
1748         https://bugs.webkit.org/show_bug.cgi?id=177586
1749
1750         Gigacage's LLInt change breaks ARM64 Linux.
1751         Currently we do not have maintainers for this.
1752         Let's simply disable it.
1753
1754         * bmalloc/Gigacage.h:
1755
1756 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1757
1758         Enable gigacage on iOS
1759         https://bugs.webkit.org/show_bug.cgi?id=177586
1760
1761         Reviewed by JF Bastien.
1762         
1763         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1764         allocation fails, we free all of the gigacages and turn off gigacage support.
1765
1766         * CMakeLists.txt:
1767         * bmalloc.xcodeproj/project.pbxproj:
1768         * bmalloc/Cache.cpp:
1769         (bmalloc::Cache::scavenge):
1770         * bmalloc/Cache.h:
1771         (bmalloc::Cache::tryAllocate):
1772         (bmalloc::Cache::allocate):
1773         (bmalloc::Cache::deallocate):
1774         (bmalloc::Cache::reallocate):
1775         * bmalloc/Gigacage.cpp:
1776         (Gigacage::ensureGigacage):
1777         (Gigacage::runway):
1778         (Gigacage::totalSize):
1779         (Gigacage::shouldBeEnabled):
1780         (): Deleted.
1781         (Gigacage::Callback::Callback): Deleted.
1782         (Gigacage::Callback::function): Deleted.
1783         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1784         * bmalloc/Gigacage.h:
1785         (Gigacage::wasEnabled):
1786         (Gigacage::isEnabled):
1787         (Gigacage::runway): Deleted.
1788         (Gigacage::totalSize): Deleted.
1789         * bmalloc/HeapKind.cpp: Added.
1790         (bmalloc::isActiveHeapKind):
1791         (bmalloc::mapToActiveHeapKind):
1792         * bmalloc/HeapKind.h:
1793         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1794         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1795         * bmalloc/Scavenger.cpp:
1796         (bmalloc::Scavenger::scavenge):
1797         * bmalloc/bmalloc.h:
1798         (bmalloc::api::tryLargeMemalignVirtual):
1799         (bmalloc::api::freeLargeVirtual):
1800         (bmalloc::api::isEnabled):
1801
1802 2017-10-05  Filip Pizlo  <fpizlo@apple.com>
1803
1804         Use one Scavenger thread for all Heaps
1805         https://bugs.webkit.org/show_bug.cgi?id=174973
1806
1807         Reviewed by JF Bastien.
1808         
1809         This combines the scavengers from all Heap instances into a single scavenger. It also combines
1810         the accounting for deciding when to run. Each Heap still controls what it means to scavenge
1811         itself (it's all in Heap::scavenge) but the policy decisions are all controlled by Scavenger.
1812         Because Scavenger is also the only thing that needs an AsyncTask, this removes AsyncTask and
1813         moves all of AsyncTask's logic into Scavenger.
1814         
1815         This appears to be a 1% progression on JetStream (with high statistical confidence: p = 0.0049).
1816
1817         * bmalloc.xcodeproj/project.pbxproj:
1818         * bmalloc/AsyncTask.h: Removed.
1819         * bmalloc/Heap.cpp:
1820         (bmalloc::Heap::Heap):
1821         (bmalloc::Heap::allocateSmallChunk):
1822         (bmalloc::Heap::allocateSmallPage):
1823         (bmalloc::Heap::deallocateSmallLine):
1824         (bmalloc::Heap::splitAndAllocate):
1825         (bmalloc::Heap::tryAllocateLarge):
1826         (bmalloc::Heap::shrinkLarge):
1827         (bmalloc::Heap::deallocateLarge):
1828         (bmalloc::Heap::concurrentScavenge): Deleted.
1829         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Deleted.
1830         (bmalloc::Heap::scheduleScavenger): Deleted.
1831         * bmalloc/Heap.h:
1832         * bmalloc/Scavenger.cpp:
1833         (bmalloc::Scavenger::Scavenger):
1834         (bmalloc::Scavenger::run):
1835         (bmalloc::Scavenger::runHoldingLock):
1836         (bmalloc::Scavenger::runSoon):
1837         (bmalloc::Scavenger::runSoonHoldingLock):
1838         (bmalloc::Scavenger::didStartGrowing):
1839         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
1840         (bmalloc::Scavenger::scheduleIfUnderMemoryPressureHoldingLock):
1841         (bmalloc::Scavenger::schedule):
1842         (bmalloc::Scavenger::threadEntryPoint):
1843         (bmalloc::Scavenger::threadRunLoop):
1844         (bmalloc::Scavenger::setSelfQOSClass):
1845         * bmalloc/Scavenger.h:
1846         (bmalloc::Scavenger::willRun):
1847         (bmalloc::Scavenger::willRunSoon):
1848
1849 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
1850
1851         bmalloc mutex should be adaptive
1852         https://bugs.webkit.org/show_bug.cgi?id=177839
1853
1854         Reviewed by Michael Saboff.
1855         
1856         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
1857         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
1858         anything other than malloc.
1859
1860         Reland after fixing ancient WordLock bug: the notify_one has to happen with the lock held
1861         to ensure it doesn't run after that thread has died.
1862
1863         * bmalloc/Algorithm.h:
1864         (bmalloc::compareExchangeWeak):
1865         (bmalloc::compareExchangeStrong):
1866         * bmalloc/PerThread.h:
1867         * bmalloc/StaticMutex.cpp:
1868         (bmalloc::StaticMutex::lockSlow):
1869         (bmalloc::StaticMutex::unlockSlow):
1870         (bmalloc::StaticMutex::lockSlowCase): Deleted.
1871         * bmalloc/StaticMutex.h:
1872         (bmalloc::StaticMutex::try_lock):
1873         (bmalloc::StaticMutex::isLocked const):
1874         (bmalloc::StaticMutex::init):
1875         (bmalloc::StaticMutex::tryLock):
1876         (bmalloc::StaticMutex::lock):
1877         (bmalloc::StaticMutex::unlock):
1878         (bmalloc::sleep): Deleted.
1879         (bmalloc::waitUntilFalse): Deleted.
1880
1881 2017-10-05  Matt Lewis  <jlewis3@apple.com>
1882
1883         Unreviewed, rolling out r222893.
1884
1885         This caused multiple API failures.
1886
1887         Reverted changeset:
1888
1889         "bmalloc mutex should be adaptive"
1890         https://bugs.webkit.org/show_bug.cgi?id=177839
1891         http://trac.webkit.org/changeset/222893
1892
1893 2017-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1894
1895         [Linux] Port MallocBench
1896         https://bugs.webkit.org/show_bug.cgi?id=177856
1897
1898         Reviewed by Filip Pizlo.
1899
1900         * CMakeLists.txt:
1901
1902 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
1903
1904         bmalloc mutex should be adaptive
1905         https://bugs.webkit.org/show_bug.cgi?id=177839
1906
1907         Reviewed by Michael Saboff.
1908         
1909         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
1910         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
1911         anything other than malloc.
1912
1913         * bmalloc/Algorithm.h:
1914         (bmalloc::compareExchangeWeak):
1915         (bmalloc::compareExchangeStrong):
1916         * bmalloc/PerThread.h:
1917         * bmalloc/StaticMutex.cpp:
1918         (bmalloc::StaticMutex::lockSlow):
1919         (bmalloc::StaticMutex::unlockSlow):
1920         (bmalloc::StaticMutex::lockSlowCase): Deleted.
1921         * bmalloc/StaticMutex.h:
1922         (bmalloc::StaticMutex::try_lock):
1923         (bmalloc::StaticMutex::isLocked const):
1924         (bmalloc::StaticMutex::init):
1925         (bmalloc::StaticMutex::tryLock):
1926         (bmalloc::StaticMutex::lock):
1927         (bmalloc::StaticMutex::unlock):
1928         (bmalloc::sleep): Deleted.
1929         (bmalloc::waitUntilFalse): Deleted.
1930
1931 2017-10-02  Yusuke Suzuki  <utatane.tea@gmail.com>
1932
1933         [Linux] Enable Gigacage in x64 Linux environment
1934         https://bugs.webkit.org/show_bug.cgi?id=177745
1935
1936         Reviewed by Carlos Garcia Campos.
1937
1938         This patch enables Gigacage in x64 Linux environment.
1939         Gigacage enforces a caged pointer to reference to the
1940         specific memory region. This reduces the effectiveness
1941         of some types of attacks setting a pointer to ArrayBuffer
1942         and modifying arbitrary memory region.
1943
1944         * bmalloc/Gigacage.h:
1945
1946 2017-09-29  Commit Queue  <commit-queue@webkit.org>
1947
1948         Unreviewed, rolling out r222625.
1949         https://bugs.webkit.org/show_bug.cgi?id=177664
1950
1951         causes crashes on iOS (Requested by pizlo-mbp on #webkit).
1952
1953         Reverted changeset:
1954
1955         "Enable gigacage on iOS"
1956         https://bugs.webkit.org/show_bug.cgi?id=177586
1957         http://trac.webkit.org/changeset/222625
1958
1959 2017-09-28  Filip Pizlo  <fpizlo@apple.com>
1960
1961         Enable gigacage on iOS
1962         https://bugs.webkit.org/show_bug.cgi?id=177586
1963
1964         Reviewed by Michael Saboff.
1965         
1966         This enables Gigacage on iOS using a much smaller cage size. It's not necessary for it to be so
1967         small, but this is a good conservative starting point to start to exercise the code.
1968
1969         * bmalloc/Gigacage.h:
1970
1971 2017-09-26  Filip Pizlo  <fpizlo@apple.com>
1972
1973         Put g_gigacageBasePtr into its own page and make it read-only
1974         https://bugs.webkit.org/show_bug.cgi?id=174972
1975
1976         Reviewed by Michael Saboff.
1977         
1978         This puts the gigacage base pointers into their own page and makes that page read-only.
1979
1980         * bmalloc/Gigacage.cpp:
1981         (Gigacage::ensureGigacage):
1982         (Gigacage::disablePrimitiveGigacage):
1983         (Gigacage::addPrimitiveDisableCallback):
1984         * bmalloc/Gigacage.h:
1985         (Gigacage::basePtr):
1986         (Gigacage::basePtrs):
1987
1988 2017-09-04  Adrian Perez de Castro  <aperez@igalia.com>
1989
1990         Unreviewed build fix for Clang with libc++
1991
1992         Fixes a build failure when building with Clang, -stdlib=libc++, and gigacage
1993         support enabled, which resulted in "stderr" being undefined.
1994
1995         * bmalloc/Gigacage.cpp: Add missing <ctsdio> include to pull the definition.
1996
1997 2017-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1998
1999         Large virtual memory region allocation requires MMAP_NORESERVE in Linux
2000         https://bugs.webkit.org/show_bug.cgi?id=176211
2001
2002         Reviewed by Geoffrey Garen.
2003
2004         In Linux, we cannot allocate very large memory region without MMAP_NORESERVE.
2005         Linux kernel needs to reserve swap area for allocated memory region. If the
2006         swap area is exhausted, kernel fails to allocate the memory region with ENOMEM.
2007
2008         This patch adds MMAP_NORESERVE to mmap flags in Linux. By adding this flag,
2009         mmap does not need to reserve swap area for the reserved memory region.
2010         This allows us to reserve very large memory region that is necessary for Gigacage.
2011
2012         * bmalloc/BPlatform.h:
2013         * bmalloc/VMAllocate.h:
2014         (bmalloc::tryVMAllocate):
2015
2016 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
2017
2018         Strings need to be in some kind of gigacage
2019         https://bugs.webkit.org/show_bug.cgi?id=174924
2020
2021         Reviewed by Oliver Hunt.
2022         
2023         This adds a StringGigacage.
2024
2025         * bmalloc/Gigacage.cpp:
2026         * bmalloc/Gigacage.h:
2027         (Gigacage::name):
2028         (Gigacage::basePtr):
2029         (Gigacage::forEachKind):
2030         * bmalloc/HeapKind.h:
2031         (bmalloc::isGigacage):
2032         (bmalloc::gigacageKind):
2033         (bmalloc::heapKind):
2034
2035 2017-08-30  Matt Lewis  <jlewis3@apple.com>
2036
2037         Unreviewed, rolling out r221384.
2038
2039         This patch caused multiple 32-bit JSC test failures.
2040
2041         Reverted changeset:
2042
2043         "Strings need to be in some kind of gigacage"
2044         https://bugs.webkit.org/show_bug.cgi?id=174924
2045         http://trac.webkit.org/changeset/221384
2046
2047 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
2048
2049         Strings need to be in some kind of gigacage
2050         https://bugs.webkit.org/show_bug.cgi?id=174924
2051
2052         Reviewed by Oliver Hunt.
2053         
2054         This adds a StringGigacage.
2055
2056         * bmalloc/Gigacage.cpp:
2057         * bmalloc/Gigacage.h:
2058         (Gigacage::name):
2059         (Gigacage::basePtr):
2060         (Gigacage::forEachKind):
2061         * bmalloc/HeapKind.h:
2062         (bmalloc::isGigacage):
2063         (bmalloc::gigacageKind):
2064         (bmalloc::heapKind):
2065
2066 2017-08-25  Daniel Bates  <dabates@apple.com>
2067
2068         Demarcate code added due to lack of NSDMI for aggregates
2069         https://bugs.webkit.org/show_bug.cgi?id=175990
2070
2071         Reviewed by Andy Estes.
2072
2073         * bmalloc/BPlatform.h:
2074         * bmalloc/List.h: Be explicit when initializing m_node to improve readability.
2075         (bmalloc::ListNode::ListNode):
2076
2077 2017-08-23  Filip Pizlo  <fpizlo@apple.com>
2078
2079         Reduce Gigacage sizes
2080         https://bugs.webkit.org/show_bug.cgi?id=175920
2081
2082         Reviewed by Mark Lam.
2083
2084         This introduces the ability to have different gigacage sizes for different gigacages, and uses it to reduce the size of both
2085         gigacages, but to different extents: Primitive gets 32GB with a 16GB runway and JSValue gets 16GB.
2086
2087         This is a ~10% membuster progression on my Mac Pro.
2088
2089         * bmalloc/Gigacage.cpp:
2090         (Gigacage::ensureGigacage):
2091         * bmalloc/Gigacage.h:
2092         (Gigacage::size):
2093         (Gigacage::alignment):
2094         (Gigacage::mask):
2095         (Gigacage::runway):
2096         (Gigacage::totalSize):
2097         (Gigacage::caged):
2098         * bmalloc/Heap.cpp:
2099         (bmalloc::Heap::Heap):
2100         (bmalloc::Heap::gigacageSize):
2101         * bmalloc/Heap.h:
2102
2103 2017-08-08  Filip Pizlo  <fpizlo@apple.com>
2104
2105         Baseline JIT should do caging
2106         https://bugs.webkit.org/show_bug.cgi?id=175037
2107
2108         Reviewed by Mark Lam.
2109         
2110         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
2111         and WebProcess.
2112         
2113         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
2114         checks on each typed array access.
2115
2116         * bmalloc/Gigacage.cpp:
2117         (Gigacage::primitiveGigacageDisabled):
2118         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2119         (Gigacage::isDisablingPrimitiveGigacageDisabled):
2120         * bmalloc/Gigacage.h:
2121         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
2122         (Gigacage::canPrimitiveGigacageBeDisabled):
2123
2124 2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>
2125
2126         Unreviewed, rolling out r220368.
2127
2128         This change caused WK1 tests to exit early with crashes.
2129
2130         Reverted changeset:
2131
2132         "Baseline JIT should do caging"
2133         https://bugs.webkit.org/show_bug.cgi?id=175037
2134         http://trac.webkit.org/changeset/220368
2135
2136 2017-08-07  Filip Pizlo  <fpizlo@apple.com>
2137
2138         Baseline JIT should do caging
2139         https://bugs.webkit.org/show_bug.cgi?id=175037
2140
2141         Reviewed by Mark Lam.
2142         
2143         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
2144         and WebProcess.
2145         
2146         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
2147         checks on each typed array access.
2148
2149         * bmalloc/Gigacage.cpp:
2150         (Gigacage::primitiveGigacageDisabled):
2151         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2152         (Gigacage::isDisablingPrimitiveGigacageDisabled):
2153         * bmalloc/Gigacage.h:
2154         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
2155         (Gigacage::canPrimitiveGigacageBeDisabled):
2156
2157 2017-08-06  Filip Pizlo  <fpizlo@apple.com>
2158
2159         Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
2160         https://bugs.webkit.org/show_bug.cgi?id=174919
2161
2162         Reviewed by Keith Miller.
2163         
2164         This introduces two kinds of Gigacage, Primitive and JSValue. This translates to two kinds of
2165         HeapKind, PrimitiveGigacage and JSValueGigacage.
2166         
2167         The new support functionality required turning Inline.h into BInline.h, and INLINE into BINLINE, and
2168         NO_INLINE into BNO_INLINE.
2169
2170         * bmalloc.xcodeproj/project.pbxproj:
2171         * bmalloc/Allocator.cpp:
2172         (bmalloc::Allocator::refillAllocatorSlowCase):
2173         (bmalloc::Allocator::refillAllocator):
2174         (bmalloc::Allocator::allocateLarge):
2175         (bmalloc::Allocator::allocateLogSizeClass):
2176         * bmalloc/AsyncTask.h:
2177         * bmalloc/BInline.h: Copied from Source/bmalloc/bmalloc/Inline.h.
2178         * bmalloc/Cache.cpp:
2179         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2180         (bmalloc::Cache::allocateSlowCaseNullCache):
2181         (bmalloc::Cache::deallocateSlowCaseNullCache):
2182         (bmalloc::Cache::reallocateSlowCaseNullCache):
2183         * bmalloc/Deallocator.cpp:
2184         * bmalloc/Gigacage.cpp:
2185         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
2186         (Gigacage::ensureGigacage):
2187         (Gigacage::disablePrimitiveGigacage):
2188         (Gigacage::addPrimitiveDisableCallback):
2189         (Gigacage::removePrimitiveDisableCallback):
2190         (Gigacage::Callbacks::Callbacks): Deleted.
2191         (Gigacage::disableGigacage): Deleted.
2192         (Gigacage::addDisableCallback): Deleted.
2193         (Gigacage::removeDisableCallback): Deleted.
2194         * bmalloc/Gigacage.h:
2195         (Gigacage::name):
2196         (Gigacage::basePtr):
2197         (Gigacage::forEachKind):
2198         (Gigacage::caged):
2199         (Gigacage::isCaged):
2200         * bmalloc/Heap.cpp:
2201         (bmalloc::Heap::Heap):
2202         (bmalloc::Heap::usingGigacage):
2203         (bmalloc::Heap::gigacageBasePtr):
2204         * bmalloc/Heap.h:
2205         * bmalloc/HeapKind.h:
2206         (bmalloc::isGigacage):
2207         (bmalloc::gigacageKind):
2208         (bmalloc::heapKind):
2209         * bmalloc/Inline.h: Removed.
2210         * bmalloc/Map.h:
2211         * bmalloc/PerProcess.h:
2212         (bmalloc::PerProcess<T>::getFastCase):
2213         (bmalloc::PerProcess<T>::get):
2214         (bmalloc::PerProcess<T>::getSlowCase):
2215         * bmalloc/PerThread.h:
2216         (bmalloc::PerThread<T>::getFastCase):
2217         * bmalloc/Vector.h:
2218         (bmalloc::Vector<T>::push):
2219         (bmalloc::Vector<T>::shrinkCapacity):
2220         (bmalloc::Vector<T>::growCapacity):
2221
2222 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
2223
2224         If Gigacage is disabled, bmalloc should service large aligned memory allocation requests through vmAllocate
2225         https://bugs.webkit.org/show_bug.cgi?id=175085
2226
2227         Reviewed by Saam Barati.
2228         
2229         This fixes a problem where if we used gmalloc, WebAssembly memory allocations would still use
2230         bmalloc's large allocator.
2231         
2232         We want to use the page allocator for those "large" allocations when the Gigacage is disabled.
2233
2234         * bmalloc/DebugHeap.cpp:
2235         (bmalloc::DebugHeap::DebugHeap):
2236         (bmalloc::DebugHeap::memalignLarge):
2237         (bmalloc::DebugHeap::freeLarge):
2238         * bmalloc/DebugHeap.h:
2239         * bmalloc/Heap.cpp:
2240         (bmalloc::Heap::tryAllocateLarge):
2241         (bmalloc::Heap::deallocateLarge):
2242
2243 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
2244
2245         We should be OK with the gigacage being disabled on gmalloc
2246         https://bugs.webkit.org/show_bug.cgi?id=175082
2247
2248         Reviewed by Michael Saboff.
2249         
2250         This adds Gigacage::shouldBeEnabled(), which returns false when we're using gmalloc or other things
2251         that enable DebugHeap.
2252
2253         * bmalloc/Environment.cpp:
2254         (bmalloc::Environment::Environment):
2255         * bmalloc/Environment.h:
2256         * bmalloc/Gigacage.cpp:
2257         (Gigacage::ensureGigacage):
2258         (Gigacage::shouldBeEnabled):
2259         * bmalloc/Gigacage.h:
2260         * bmalloc/Heap.cpp:
2261         (bmalloc::Heap::Heap):
2262         * bmalloc/Heap.h:
2263
2264 2017-08-01  Filip Pizlo  <fpizlo@apple.com>
2265
2266         Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
2267         https://bugs.webkit.org/show_bug.cgi?id=174727
2268
2269         Reviewed by Mark Lam.
2270         
2271         This adds a mechanism for managing multiple isolated heaps in bmalloc. For now, these isoheaps
2272         (isolated heaps) have a very simple relationship with each other and with the rest of bmalloc:
2273         
2274         - You have to choose how many isoheaps you will have statically. See numHeaps in HeapKind.h.
2275         
2276         - Because numHeaps is static, each isoheap gets fast thread-local allocation. Basically, we have a
2277           Cache for each heap kind.
2278         
2279         - Each isoheap gets its own Heap.
2280         
2281         - Each Heap gets a scavenger thread.
2282         
2283         - Some things, like Zone/VMHeap/Scavenger, are per-process.
2284         
2285         Most of the per-HeapKind functionality is handled by PerHeapKind<>.
2286         
2287         This approach is ideal for supporting special per-HeapKind behaviors. For now we have two heaps:
2288         the Primary heap for normal malloc and the Gigacage. The gigacage is a 64GB-aligned 64GB virtual
2289         region that we now use for variable-length random-access allocations. No Primary allocations will
2290         go into the Gigacage.
2291
2292         * CMakeLists.txt:
2293         * bmalloc.xcodeproj/project.pbxproj:
2294         * bmalloc/AllocationKind.h: Added.
2295         * bmalloc/Allocator.cpp:
2296         (bmalloc::Allocator::Allocator):
2297         (bmalloc::Allocator::tryAllocate):
2298         (bmalloc::Allocator::allocateImpl):
2299         (bmalloc::Allocator::reallocate):
2300         (bmalloc::Allocator::refillAllocatorSlowCase):
2301         (bmalloc::Allocator::allocateLarge):
2302         * bmalloc/Allocator.h:
2303         * bmalloc/BExport.h: Added.
2304         * bmalloc/Cache.cpp:
2305         (bmalloc::Cache::scavenge):
2306         (bmalloc::Cache::Cache):
2307         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2308         (bmalloc::Cache::allocateSlowCaseNullCache):
2309         (bmalloc::Cache::deallocateSlowCaseNullCache):
2310         (bmalloc::Cache::reallocateSlowCaseNullCache):
2311         (bmalloc::Cache::operator new): Deleted.
2312         (bmalloc::Cache::operator delete): Deleted.
2313         * bmalloc/Cache.h:
2314         (bmalloc::Cache::tryAllocate):
2315         (bmalloc::Cache::allocate):
2316         (bmalloc::Cache::deallocate):
2317         (bmalloc::Cache::reallocate):
2318         * bmalloc/Deallocator.cpp:
2319         (bmalloc::Deallocator::Deallocator):
2320         (bmalloc::Deallocator::scavenge):
2321         (bmalloc::Deallocator::processObjectLog):
2322         (bmalloc::Deallocator::deallocateSlowCase):
2323         * bmalloc/Deallocator.h:
2324         * bmalloc/Gigacage.cpp: Added.
2325         (Gigacage::Callback::Callback):
2326         (Gigacage::Callback::function):
2327         (Gigacage::Callbacks::Callbacks):
2328         (Gigacage::ensureGigacage):
2329         (Gigacage::disableGigacage):
2330         (Gigacage::addDisableCallback):
2331         (Gigacage::removeDisableCallback):
2332         * bmalloc/Gigacage.h: Added.
2333         (Gigacage::caged):
2334         (Gigacage::isCaged):
2335         * bmalloc/Heap.cpp:
2336         (bmalloc::Heap::Heap):
2337         (bmalloc::Heap::usingGigacage):
2338         (bmalloc::Heap::concurrentScavenge):
2339         (bmalloc::Heap::splitAndAllocate):
2340         (bmalloc::Heap::tryAllocateLarge):
2341         (bmalloc::Heap::allocateLarge):
2342         (bmalloc::Heap::shrinkLarge):
2343         (bmalloc::Heap::deallocateLarge):
2344         * bmalloc/Heap.h:
2345         (bmalloc::Heap::mutex):
2346         (bmalloc::Heap::kind const):
2347         (bmalloc::Heap::setScavengerThreadQOSClass): Deleted.
2348         * bmalloc/HeapKind.h: Added.
2349         * bmalloc/ObjectType.cpp:
2350         (bmalloc::objectType):
2351         * bmalloc/ObjectType.h:
2352         * bmalloc/PerHeapKind.h: Added.
2353         (bmalloc::PerHeapKindBase::PerHeapKindBase):
2354         (bmalloc::PerHeapKindBase::size):
2355         (bmalloc::PerHeapKindBase::at):
2356         (bmalloc::PerHeapKindBase::at const):
2357         (bmalloc::PerHeapKindBase::operator[]):
2358         (bmalloc::PerHeapKindBase::operator[] const):
2359         (bmalloc::StaticPerHeapKind::StaticPerHeapKind):
2360         (bmalloc::PerHeapKind::PerHeapKind):
2361         (bmalloc::PerHeapKind::~PerHeapKind):
2362         * bmalloc/PerThread.h:
2363         (bmalloc::PerThread<T>::destructor):
2364         (bmalloc::PerThread<T>::getSlowCase):
2365         (bmalloc::PerThreadStorage<Cache>::get): Deleted.
2366         (bmalloc::PerThreadStorage<Cache>::init): Deleted.
2367         * bmalloc/Scavenger.cpp: Added.
2368         (bmalloc::Scavenger::Scavenger):
2369         (bmalloc::Scavenger::scavenge):
2370         * bmalloc/Scavenger.h: Added.
2371         (bmalloc::Scavenger::setScavengerThreadQOSClass):
2372         (bmalloc::Scavenger::requestedScavengerThreadQOSClass const):
2373         * bmalloc/VMHeap.cpp:
2374         (bmalloc::VMHeap::VMHeap):
2375         (bmalloc::VMHeap::tryAllocateLargeChunk):
2376         * bmalloc/VMHeap.h:
2377         * bmalloc/Zone.cpp:
2378         (bmalloc::Zone::Zone):
2379         * bmalloc/Zone.h:
2380         * bmalloc/bmalloc.h:
2381         (bmalloc::api::tryMalloc):
2382         (bmalloc::api::malloc):
2383         (bmalloc::api::tryMemalign):
2384         (bmalloc::api::memalign):
2385         (bmalloc::api::realloc):
2386         (bmalloc::api::tryLargeMemalignVirtual):
2387         (bmalloc::api::free):
2388         (bmalloc::api::freeLargeVirtual):
2389         (bmalloc::api::scavengeThisThread):
2390         (bmalloc::api::scavenge):
2391         (bmalloc::api::isEnabled):
2392         (bmalloc::api::setScavengerThreadQOSClass):
2393         * bmalloc/mbmalloc.cpp:
2394
2395 2017-08-01  Daewoong Jang  <daewoong.jang@navercorp.com>
2396
2397         Implement __builtin_clzl for MSVC
2398         https://bugs.webkit.org/show_bug.cgi?id=174232
2399
2400         Reviewed by Geoffrey Garen.
2401
2402         * bmalloc/Algorithm.h:
2403         (bmalloc::clzl):
2404         (bmalloc::clzl<1>):
2405         (bmalloc::__builtin_clzl):
2406         * bmalloc/BPlatform.h:
2407
2408 2017-07-31  Mark Lam  <mark.lam@apple.com>
2409
2410         Fixed some comment typos.
2411
2412         Not reviewed.
2413
2414         * bmalloc/PerProcess.h:
2415
2416 2017-07-14  Filip Pizlo  <fpizlo@apple.com>
2417
2418         It should be easy to decide how WebKit yields
2419         https://bugs.webkit.org/show_bug.cgi?id=174298
2420
2421         Reviewed by Saam Barati.
2422         
2423         Use sched_yield() explicitly.
2424
2425         * bmalloc/StaticMutex.cpp:
2426         (bmalloc::StaticMutex::lockSlowCase):
2427
2428 2017-07-20  Chris Dumez  <cdumez@apple.com>
2429
2430         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
2431         https://bugs.webkit.org/show_bug.cgi?id=174660
2432
2433         Reviewed by Geoffrey Garen.
2434
2435         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
2436         This essentially replaces a branch to figure out if the new size is less or greater than the
2437         current size by an assertion.
2438
2439         * bmalloc/Map.h:
2440         (bmalloc::Hash>::rehash):
2441
2442 2017-07-18  Andy Estes  <aestes@apple.com>
2443
2444         [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
2445         https://bugs.webkit.org/show_bug.cgi?id=174631
2446
2447         Reviewed by Tim Horton.
2448
2449         * Configurations/Base.xcconfig:
2450
2451 2017-07-18  Andy Estes  <aestes@apple.com>
2452
2453         [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
2454         https://bugs.webkit.org/show_bug.cgi?id=174631
2455
2456         Reviewed by Sam Weinig.
2457
2458         * Configurations/Base.xcconfig:
2459
2460 2017-07-18  Andy Estes  <aestes@apple.com>
2461
2462         [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
2463         https://bugs.webkit.org/show_bug.cgi?id=174631
2464
2465         Reviewed by Dan Bernstein.
2466
2467         * Configurations/Base.xcconfig:
2468
2469 2017-07-18  Andy Estes  <aestes@apple.com>
2470
2471         [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
2472         https://bugs.webkit.org/show_bug.cgi?id=174631
2473
2474         Reviewed by Darin Adler.
2475
2476         * Configurations/Base.xcconfig:
2477
2478 2017-07-12  Adrian Perez de Castro  <aperez@igalia.com>
2479
2480         bmalloc: Failure to build when the compiler specifically targets ARMv8-A / defines __ARM_ARCH_8A__
2481         https://bugs.webkit.org/show_bug.cgi?id=174424
2482
2483         Reviewed by Michael Catanzaro.
2484
2485         * bmalloc/BPlatform.h: Also check for __ARCH_ARM_8A__ to detect ARMv8.
2486
2487 2017-07-05  Daewoong Jang  <daewoong.jang@navercorp.com>
2488
2489         reinterpret_cast does not evaluate to constexpr
2490         https://bugs.webkit.org/show_bug.cgi?id=173622
2491
2492         Reviewed by Yusuke Suzuki.
2493
2494         * bmalloc/Algorithm.h:
2495         (bmalloc::mask):
2496         (bmalloc::roundUpToMultipleOf):
2497
2498 2017-07-03  Andy Estes  <aestes@apple.com>
2499
2500         [Xcode] Add an experimental setting to build with ccache
2501         https://bugs.webkit.org/show_bug.cgi?id=173875
2502
2503         Reviewed by Tim Horton.
2504
2505         * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.
2506
2507 2017-07-01  Dan Bernstein  <mitz@apple.com>
2508
2509         [iOS] Remove code only needed when building for iOS 9.x
2510         https://bugs.webkit.org/show_bug.cgi?id=174068
2511
2512         Reviewed by Tim Horton.
2513
2514         * bmalloc/BPlatform.h:
2515         * bmalloc/VMAllocate.h:
2516         (bmalloc::vmPageSizePhysical):
2517
2518 2017-07-01  Dan Bernstein  <mitz@apple.com>
2519
2520         [macOS] Remove code only needed when building for OS X Yosemite
2521         https://bugs.webkit.org/show_bug.cgi?id=174067
2522
2523         Reviewed by Tim Horton.
2524
2525         * Configurations/Base.xcconfig:
2526         * Configurations/DebugRelease.xcconfig:
2527
2528 2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>
2529
2530         Ran sort-Xcode-project-file.
2531
2532         * bmalloc.xcodeproj/project.pbxproj:
2533
2534 2017-06-19  Geoffrey Garen  <ggaren@apple.com>
2535
2536         bmalloc: Add a per-thread line cache
2537         https://bugs.webkit.org/show_bug.cgi?id=173552
2538
2539         Reviewed by Darin Adler.
2540
2541         Previously, any thread could allocate out of any page with free lines.
2542         Now, the first thread to free a line in a page owns that page's free
2543         lines until the whole page becomes free.
2544
2545         This patch is a big speedup on multi-threaded benchmarks.
2546         tree_churn --parallel gets 14% faster on a 2-core (4-hyper-core) MacBook
2547         Air and 2.85X faster on 12-core (24-hyper-core) Mac Pro. Other parallel
2548         benchmarks show significant but smaller speedups.
2549
2550         Thread affinity is a great predictor of object lifetime. The per-thread
2551         line cache avoids the pathology of shuffling pages between threads,
2552         turning predictable lifetimes into unpredictable lifetimes, increasing
2553         fragmentation. On tree_churn --parallel, the per-thread line cache
2554         increases free memory found per page scanned by 2.85X.
2555
2556         Free line scanning in fragmented pages is pretty expensive relative to
2557         other allocate / initialize / free operations. According to Instruments,
2558         on tree_churn --parallel, scanning is about 10X more expensive than
2559         freeing. This explains why a 2.85X improvement in scanning efficiency
2560         translates into a 2.85X overall speedup on tree_churn --parallel.
2561
2562         * bmalloc/Allocator.cpp:
2563         (bmalloc::Allocator::refillAllocatorSlowCase): Pass through our line
2564         cache so the Heap can fill it.
2565
2566         * bmalloc/Deallocator.cpp:
2567         (bmalloc::Deallocator::scavenge): Scavenge our line cache.
2568
2569         (bmalloc::Deallocator::processObjectLog): Deleted.
2570
2571         * bmalloc/Deallocator.h:
2572         (bmalloc::Deallocator::lineCache): Added a line cache.
2573
2574         * bmalloc/Heap.cpp:
2575         (bmalloc::Heap::deallocateLineCache): Deallocation function for thread
2576         destruction.
2577
2578         (bmalloc::Heap::allocateSmallPage):
2579         (bmalloc::Heap::deallocateSmallLine):
2580         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2581         (bmalloc::Heap::allocateSmallBumpRangesByObject): Consult the new per-thread line
2582         cache for allocation and deallocation.
2583
2584         * bmalloc/Heap.h:
2585         (bmalloc::Heap::allocateSmallBumpRanges):
2586         (bmalloc::Heap::derefSmallLine):
2587
2588         * bmalloc/List.h:
2589         (bmalloc::List::remove): Remove has always been a logically static
2590         operation. Declare it static now so that the Heap can remove a page from
2591         a thread's line cache without holding a direct pointer to the cache.
2592
2593         * bmalloc/SmallPage.h:
2594
2595 2017-06-10  Dan Bernstein  <mitz@apple.com>
2596
2597         Reverted r218056 because it made the IDE reindex constantly.
2598
2599         * Configurations/DebugRelease.xcconfig:
2600
2601 2017-06-10  Dan Bernstein  <mitz@apple.com>
2602
2603         [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
2604         https://bugs.webkit.org/show_bug.cgi?id=173223
2605
2606         Reviewed by Sam Weinig.
2607
2608         The rebuilds were happening due to a difference in the compiler options that the IDE and
2609         xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
2610         xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
2611         specify an appropriate path in CLANG_INDEX_STORE_PATH.
2612
2613         * Configurations/DebugRelease.xcconfig:
2614
2615 2017-06-07  Geoffrey Garen  <ggaren@apple.com>
2616
2617         bmalloc: memory APIs don't need to be heap members
2618         https://bugs.webkit.org/show_bug.cgi?id=173076
2619
2620         Reviewed by Sam Weinig.
2621
2622         Asking the OS about memory use is unrelated to the state of bmalloc's
2623         heap, so it's a better separation of concerns if related code is not 
2624         part of the heap.
2625
2626         * bmalloc/AvailableMemory.cpp:
2627         (bmalloc::memoryStatus):
2628         * bmalloc/AvailableMemory.h:
2629         (bmalloc::MemoryStatus::MemoryStatus):
2630         (bmalloc::isUnderMemoryPressure):
2631         (bmalloc::memoryFootprint):
2632         (bmalloc::percentAvailableMemoryInUse):
2633         * bmalloc/Heap.cpp:
2634         (bmalloc::Heap::Heap):
2635         (bmalloc::Heap::updateMemoryInUseParameters): Deleted.
2636         * bmalloc/Heap.h:
2637         (bmalloc::Heap::isUnderMemoryPressure): Deleted.
2638         (bmalloc::Heap::memoryFootprint): Deleted.
2639         (bmalloc::Heap::percentAvailableMemoryInUse): Deleted.
2640
2641 2017-06-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2642
2643         struct does not accept initializer-form if member has initializers in GCC 4.9
2644         https://bugs.webkit.org/show_bug.cgi?id=172974
2645
2646         Reviewed by Carlos Garcia Campos.
2647
2648         struct cannot accept initializer-form constructor (like, `ListNode<T> t { ... }`) if
2649         the member of the struct has a default initializer.
2650         Here is a simple snippet.
2651
2652         template<typename T>
2653         struct Pair {
2654             T* prev { nullptr };
2655             T* next { nullptr };
2656         };
2657
2658         Pair<int> pair { nullptr, nullptr };  // compile erorr in GCC 4.9.
2659
2660         Instead, we define a default constructor (to invoke default initializers) and a constructor
2661         to accept the above initialization.
2662
2663         * bmalloc/List.h:
2664         (bmalloc::ListNode::ListNode):
2665         (bmalloc::List::iterator::iterator):
2666
2667 2017-06-06  Geoffrey Garen  <ggaren@apple.com>
2668
2669         Try to fix the GTK build.
2670
2671         Unreviewed.
2672
2673         * bmalloc/List.h:
2674         (bmalloc::List::List):
2675
2676 2017-06-05  Geoffrey Garen  <ggaren@apple.com>
2677
2678         Try to fix the GTK build.
2679
2680         Unreviewed.
2681
2682         * bmalloc/List.h:
2683
2684 2017-06-02  Geoffrey Garen  <ggaren@apple.com>
2685
2686         bmalloc: Small and large objects should share memory
2687         https://bugs.webkit.org/show_bug.cgi?id=172880
2688         <rdar://problem/31494732>
2689
2690         Reviewed by Sam Weinig.
2691
2692         This reduces our high water mark memory usage on JetStream on macOS
2693         by 10%-20%. It also has the nice side effect that we can free small
2694         object metadata after returning from a high water mark.
2695
2696         No change in throughput.
2697
2698         Our old algorithm allocated small object chunks and large objects in
2699         segregated virtual memory and never recycled addresses between them.
2700         This provided a slight security benefit because we could apply guard
2701         pages between the segregated ranges and we would never reuse the same
2702         virtual address for object and metadata memory.
2703
2704         Our new algorithm allocates small object chunks from the large object
2705         allocator. This naturally recycles memory between small chunks and large
2706         objects, and between small chunks of different page classes. This allows
2707         us to shift memory between allocation types as a program moves between
2708         different phases of allocation, and to delete small object chunk metadata
2709         when a program shrinks back from a high water mark.
2710
2711         Two intuitions I had about memory use turned out to be backwards in
2712         this context:
2713
2714         (1) I thought that this optimization would work because it allowed you to
2715         allocate and free a 4MB object and then reuse that large allocation to
2716         service small allocations. In practice, the common benefit seems to be
2717         the opposite: After you allocate and free many small objects, you can
2718         stitch them together to allocate a large object without growing the heap.
2719
2720         (2) I thought that it would be more memory-efficient to allocate
2721         fine-grained pages from the large object allocator. In practice, giving
2722         the large object allocator too many arbitrarily-sized ranges to manage
2723         leads to fragmentation. Meanwhile, segregated fit is a powerful memory
2724         optimization. So, it's best to return small object memory to the large
2725         allocator only when a whole small object chunk is free.
2726
2727         * bmalloc/Chunk.h:
2728         (bmalloc::Chunk::ref):
2729         (bmalloc::Chunk::deref):
2730         (bmalloc::Chunk::refCount):
2731         (bmalloc::Chunk::freePages): We keep a free list per chunk and refcount
2732         each chunk so we can notice when a chunk becomes empty, and return it
2733         to the large allocator.
2734
2735         (bmalloc::forEachPage): A new helper function for iterating the pages
2736         in a Chunk.
2737
2738         (bmalloc::Chunk::Chunk): Use forEachPage instead of manual iteration.
2739         Use { } initialization because we don't get zero-initialized by the OS
2740         anymore.
2741
2742         * bmalloc/Heap.cpp:
2743         (bmalloc::Heap::Heap):
2744         (bmalloc::Heap::concurrentScavenge):
2745         (bmalloc::Heap::scavenge): Don't bother unlocking while scavenging. I
2746         wasn't able to show it to be a consistent speedup. A more promising
2747         approach, if we find a motivating example, is for the scavenger to give
2748         up and return early if any other client is waiting on the lock.
2749
2750         (bmalloc::Heap::allocateSmallChunk): New helper function for allocating
2751         a small chunk. It allocates through the large allocator to facilitate
2752         sharing. We still allocate a chunk at a time instead of a page at a time.
2753         Surprisingly, more precise page-at-a-time allocation is worse for memory
2754         use because of fragmentation. Segregated fit is a powerful optimization.
2755
2756         (bmalloc::Heap::deallocateSmallChunk): New helper function for deallocating
2757         a small chunk.
2758
2759         (bmalloc::Heap::allocateSmallPage): Updated for new APIs.
2760
2761         (bmalloc::Heap::deallocateSmallLine):  Updated for new APIs. Note that
2762         we cache one free chunk per page class. This avoids churn in the large
2763         allocator when you free(malloc(X)).
2764
2765         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2766         (bmalloc::Heap::allocateSmallBumpRangesByObject):
2767         (bmalloc::Heap::tryAllocateLarge):
2768         (bmalloc::Heap::scavengeSmallPages): Deleted.
2769         (bmalloc::Heap::scavengeLargeObjects): Deleted.
2770         * bmalloc/Heap.h:
2771
2772         * bmalloc/LargeMap.h:
2773         (bmalloc::LargeMap::begin):
2774         (bmalloc::LargeMap::end): Added iteration helpers for scavenging.
2775
2776         * bmalloc/LargeRange.h:
2777         (bmalloc::LargeRange::physicalSize): Added a comment about something
2778         that I confused myself about in this patch.
2779
2780         * bmalloc/List.h:
2781         (bmalloc::List::iterator::operator*):
2782         (bmalloc::List::iterator::operator->):
2783         (bmalloc::List::iterator::operator!=):
2784         (bmalloc::List::iterator::operator++):
2785         (bmalloc::List::begin):
2786         (bmalloc::List::end):
2787         (bmalloc::List::pushFront):
2788         (bmalloc::List::remove):
2789         (bmalloc::ListNode::ListNode): Deleted. Added iteration helpers for
2790         scavenging. Changed the default state of a Node to null pointers instead
2791         of self pointers to distinguish the null node from the empty node for
2792         easier debugging.
2793
2794         * bmalloc/Sizes.h: Changed the chunk size to 1MB to increase the chances
2795         of a chunk becoming free and recyclable.
2796
2797         * bmalloc/SmallPage.h:
2798         (bmalloc::SmallPage::hasPhysicalPages):
2799         (bmalloc::SmallPage::setHasPhysicalPages): Track physical state by page
2800         instead of implicitly by which list a page is in. It's simpler not
2801         to have to move chunks and pages between physical vs virtual lists.
2802
2803         (bmalloc::SmallPage::SmallPage): Deleted.
2804
2805         * bmalloc/VMHeap.cpp:
2806         (bmalloc::VMHeap::tryAllocateLargeChunk):
2807         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
2808         * bmalloc/VMHeap.h:
2809         (bmalloc::VMHeap::allocateSmallPage): Deleted.
2810         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Small chunk allocation
2811         just forwards to the large allocator now.
2812
2813         * bmalloc/bmalloc.h:
2814         (bmalloc::api::scavenge):
2815
2816 2017-05-28  Dan Bernstein  <mitz@apple.com>
2817
2818         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
2819         https://bugs.webkit.org/show_bug.cgi?id=172691
2820
2821         Reviewed by Tim Horton.
2822
2823         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
2824
2825 2017-05-25  Geoffrey Garen  <ggaren@apple.com> and Michael Saboff  <msaboff@apple.com>
2826
2827         bmalloc: scavenger runs too much on JetStream
2828         https://bugs.webkit.org/show_bug.cgi?id=172373
2829
2830         Reviewed by Geoffrey Garen.
2831
2832         Instruments says that JetStream on macOS spends about 3% of its time in
2833         madvise.
2834
2835         In <https://bugs.webkit.org/show_bug.cgi?id=160098>, Ben saw some
2836         evidence that madvise was the reason that switching to bmalloc for
2837         DFG::Node allocations was a slowdown the first time around.
2838
2839         In <https://bugs.webkit.org/show_bug.cgi?id=172124>, Michael saw that
2840         scavening policy can affect JetStream.
2841
2842         Intuitively, it seems wrong for the heap to idle shrink during hardcore
2843         benchmarking.
2844
2845         The strategy here is to back off in response to any heap growth event,
2846         and to wait 2s instead of 0.5s for heap growth to take place -- but we
2847         scavenge immediately in response to critical memory pressure, to avoid
2848         jetsam.
2849
2850         One hole in this strategy is that a workload with a perfectly
2851         unfragmented heap that allocates and deallocates ~16kB every 2s will
2852         never shrink its heap. This doesn't seem to be a problem in practice.
2853
2854         This looks like a 2% - 4% speedup on JetStream on Mac Pro and MacBook Air.
2855
2856         * bmalloc/AsyncTask.h:
2857         (bmalloc::AsyncTask::willRun):
2858         (bmalloc::AsyncTask::willRunSoon):
2859         (bmalloc::Function>::AsyncTask):
2860         (bmalloc::Function>::run):
2861         (bmalloc::Function>::runSoon):
2862         (bmalloc::Function>::threadRunLoop):
2863         (bmalloc::Function>::runSlowCase): Deleted. Added a "run soon" state
2864         so that execution delay is modeled directly instead of implicitly
2865         through sleep events. This enables the Heap to issue a "run now" event
2866         at any moment in response ot memory pressure.
2867
2868         * bmalloc/Heap.cpp:
2869         (bmalloc::Heap::Heap): Don't call into our own API -- that's a layering
2870         violation.
2871
2872         (bmalloc::Heap::updateMemoryInUseParameters): No need for
2873         m_scavengeSleepDuration anymore.
2874
2875         (bmalloc::Heap::concurrentScavenge): Added a back-off policy when the
2876         heap is growing.
2877         (bmalloc::Heap::scavenge):
2878
2879         (bmalloc::Heap::scavengeSmallPages):
2880         (bmalloc::Heap::scavengeLargeObjects): Don't try to give up in the middle
2881         of a scavenge event. Our new backoff policy supplants that design. Also,
2882         it's easier to profile and understand scavenging behavior if it always
2883         runs to completion once started.
2884
2885         (bmalloc::Heap::scheduleScavenger):
2886         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Added a
2887         synchronous amortized check for memory pressure. This check has the
2888         benefit that it runs immediately during high rates of heap activity,
2889         so we can detect memory pressure right away and wake the scavenger
2890         instead of waiting for the scavenger to wake up.
2891
2892         (bmalloc::Heap::allocateSmallPage):
2893         (bmalloc::Heap::deallocateSmallLine):
2894         (bmalloc::Heap::splitAndAllocate):
2895         (bmalloc::Heap::tryAllocateLarge):
2896         (bmalloc::Heap::shrinkLarge):
2897         (bmalloc::Heap::deallocateLarge):
2898         * bmalloc/Heap.h:
2899         (bmalloc::Heap::isUnderMemoryPressure):
2900         * bmalloc/Sizes.h:
2901         * bmalloc/VMHeap.h:
2902         (bmalloc::VMHeap::deallocateSmallPage):
2903         * bmalloc/bmalloc.h:
2904         (bmalloc::api::scavenge): Updated for API changes above.
2905
2906 2017-05-17  Michael Saboff  <msaboff@apple.com>
2907
2908         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info (172186)
2909         https://bugs.webkit.org/show_bug.cgi?id=172186
2910
2911         Reviewed by Geoffrey Garen.
2912
2913         The calls memoryFootprint() and percentAvailableMemoryInUse() now make a system call to get
2914         the current memory footprint value.
2915
2916         * bmalloc/Heap.h:
2917         (bmalloc::Heap::memoryFootprint):
2918         (bmalloc::Heap::percentAvailableMemoryInUse):
2919
2920 2017-05-16  Michael Saboff  <msaboff@apple.com>
2921
2922         REGRESSION(r216763): JetStream is 1% slower on Mac
2923         https://bugs.webkit.org/show_bug.cgi?id=172124
2924
2925         Reviewed by Filip Pizlo.
2926
2927         It appears that changing maxScavengeSleepDuration from 512 to 250ms in r216763 is
2928         responsible for the regression.
2929
2930         * bmalloc/Sizes.h:
2931
2932 2017-05-15  Geoffrey Garen  <ggaren@apple.com>
2933
2934         bmalloc: Bump the size of the deallocator log to 512
2935         https://bugs.webkit.org/show_bug.cgi?id=172143
2936
2937         Reviewed by Michael Saboff.
2938
2939         This is a speedup on parallel workloads for machines with lots of CPUs.
2940
2941         * bmalloc/Sizes.h:
2942
2943 2017-05-12  Michael Saboff  <msaboff@apple.com>
2944
2945         [iOS] Use memory footprint to dynamically adjust behavior of allocators
2946         https://bugs.webkit.org/show_bug.cgi?id=171944
2947
2948         Reviewed by Filip Pizlo.
2949
2950         This change is iOS only.
2951
2952         After the scavenger thread completes scavenging, it asks the OS for how much total memory the
2953         process is using.  This information is used to update the sleep delay for the scanvenger thread,
2954         as well as to provide memory in use data for other parts of the system.
2955
2956         The scavenger sleep time is calculated using the following quadradic equation.
2957
2958             scavengerSleep = 1.2*percentFreeMemory^2 - percentFreeMemory + 2
2959
2960         Where percentFreeMemory is between 0 and 100.  The result is constrained to the values 2 and 250.
2961
2962         This equation empirically works out to providing a 2ms sleep time when we have less than 10%
2963         memory available, 30ms when 20% is available and 250ms when 50% or more is available.  In testing,
2964         this exponentially agressive scavenging delay by itself reduced memory usage and made it much
2965         more deterministic when used without the corresponding change in the JSC Heap.
2966
2967         Changed the scavenger thread to use the User Initiated QOS priority to ensure it doesn't
2968         get starved.
2969
2970         Moved the non-Windows functionality of WTF::RAMSize() to new files AvailableMemory.{cpp,h}
2971         and implemented in the function availableMemory().  That functions limits the value returned
2972         on iOS to a maximum of 840MB as that is the jetsam soft memory limit.
2973         Added a new API availableMemory() so that WTF::RAMSize() will use this value.
2974
2975         * CMakeLists.txt:
2976         * bmalloc.xcodeproj/project.pbxproj:
2977         * bmalloc/BPlatform.h:
2978         * bmalloc/Heap.cpp:
2979         (bmalloc::Heap::Heap):
2980         (bmalloc::Heap::updateMemoryInUseParameters):
2981         (bmalloc::Heap::concurrentScavenge):
2982         (bmalloc::Heap::scavenge):
2983         * bmalloc/Heap.h:
2984         (bmalloc::Heap::memoryFootprint):
2985         (bmalloc::Heap::percentAvailableMemoryInUse):
2986         * bmalloc/Sizes.h:
2987         * bmalloc/bmalloc.h:
2988         (bmalloc::api::availableMemory):
2989         (bmalloc::api::memoryFootprint):
2990         (bmalloc::api::percentAvailableMemoryInUse):
2991         * bmalloc/AvailableMemory.cpp: Added.
2992         (bmalloc::computeAvailableMemory):
2993         (bmalloc::availableMemory):
2994         * bmalloc/AvailableMemory.h: Added.
2995
2996 2017-05-05  Joseph Pecoraro  <pecoraro@apple.com>
2997
2998         Leaks always reports "WebKit Malloc Memory Pressure Handler" dispatch_queue/source as leaking
2999         https://bugs.webkit.org/show_bug.cgi?id=171532
3000
3001         Reviewed by Geoffrey Garen.
3002
3003         * bmalloc/Heap.cpp:
3004         (bmalloc::Heap::Heap):
3005         * bmalloc/Heap.h:
3006         Store the dispatch_source_t in a member to avoid a false positive leak.
3007
3008 2017-04-27  Michael Saboff  <msaboff@apple.com>
3009
3010         bmalloc scavenger should know what page classes are allocating
3011         https://bugs.webkit.org/show_bug.cgi?id=171384
3012
3013         Reviewed by Geoffrey Garen.
3014
3015         This change replaces m_isAllocatingPages with a per page class flag to track which page
3016         classes are currently allocating.  When scavenging, we skip page classes that are actively
3017         allocating and come back to them on a subsequent pass.  This reduces the amount of time it
3018         takes for scavenger to free up pages as well as the total time it takes to handle all
3019         page classes.
3020
3021         * bmalloc/Heap.cpp:
3022         (bmalloc::Heap::Heap):
3023         (bmalloc::Heap::concurrentScavenge):
3024         (bmalloc::Heap::scavenge):
3025         (bmalloc::Heap::scavengeSmallPages):
3026         (bmalloc::Heap::scavengeLargeObjects):
3027         (bmalloc::Heap::allocateSmallPage):
3028         (bmalloc::Heap::splitAndAllocate):
3029         (bmalloc::Heap::deallocateLarge):
3030         * bmalloc/Heap.h:
3031         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass): Deleted.
3032         * bmalloc/VMHeap.h:
3033         (bmalloc::VMHeap::deallocateSmallPage):
3034         * bmalloc/bmalloc.h:
3035         (bmalloc::api::scavenge):
3036
3037 2017-04-25  Michael Saboff  <msaboff@apple.com>
3038
3039         Call bmalloc scavenger first when handling a memory pressure event
3040         https://bugs.webkit.org/show_bug.cgi?id=171289
3041
3042         Reviewed by Geoffrey Garen.
3043
3044         Registered a critical memory pressure handler.  We add this handler in addition to the
3045         call to release bmalloc memory in the WebCore releaseMemory handler for the case of
3046         JSC API users that don't use WebCore.  When both handlers are in the process, it is
3047         basically a race.  One will win, but the loser won't do any more work, so it is harmless.
3048
3049         * bmalloc/Heap.cpp:
3050         (bmalloc::Heap::Heap):
3051
3052 2017-04-14  Mark Lam  <mark.lam@apple.com>
3053
3054         Update architectures in xcconfig files.
3055         https://bugs.webkit.org/show_bug.cgi?id=170867
3056         <rdar://problem/31628104>
3057
3058         Reviewed by Joseph Pecoraro.
3059
3060         * Configurations/Base.xcconfig:
3061
3062 2017-04-12  Dan Bernstein  <mitz@apple.com>
3063
3064         [Mac] Future-proof .xcconfig files
3065         https://bugs.webkit.org/show_bug.cgi?id=170802
3066
3067         Reviewed by Tim Horton.
3068
3069         * Configurations/Base.xcconfig:
3070         * Configurations/DebugRelease.xcconfig:
3071
3072 2017-02-03  Ting-Wei Lan  <lantw44@gmail.com>
3073
3074         Include cstdlib before using ::malloc and posix_memalign
3075         https://bugs.webkit.org/show_bug.cgi?id=167800
3076
3077         Reviewed by Geoffrey Garen.
3078
3079         * bmalloc/DebugHeap.cpp:
3080
3081 2017-02-01  Andreas Kling  <akling@apple.com>
3082
3083         Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
3084         <https://webkit.org/b/167387>
3085         <rdar://problem/29711409>
3086
3087         Reviewed by Antti Koivisto.
3088
3089         Support changing the QoS level of the scavenger thread asynchronously through
3090         a request variable. This is not the most elegant thing in the world, but since
3091         threads are only allowed to change their own QoS class, our options are limited.
3092
3093         * bmalloc/Heap.cpp:
3094         (bmalloc::Heap::concurrentScavenge):
3095         * bmalloc/Heap.h:
3096         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
3097         (bmalloc::Heap::setScavengerThreadQOSClass):
3098         * bmalloc/bmalloc.h:
3099         (bmalloc::api::setScavengerThreadQOSClass):
3100
3101 2017-01-13  Geoffrey Garen  <ggaren@apple.com>
3102
3103         bmalloc: Use a separate zone when using system malloc
3104         https://bugs.webkit.org/show_bug.cgi?id=167014
3105
3106         Reviewed by Filip Pizlo.
3107
3108         Harris asked for this so he could separate Safari and WebKit memory use
3109         when doing memory analysis.
3110
3111         This patch adds an explicit DebugHeap class that contains all our
3112         code for specialized allocation with debugging.
3113
3114         * bmalloc.xcodeproj/project.pbxproj:
3115
3116         * bmalloc/Allocator.cpp:
3117         (bmalloc::Allocator::Allocator):
3118         (bmalloc::Allocator::tryAllocate):
3119         (bmalloc::Allocator::allocateImpl):
3120         (bmalloc::Allocator::reallocate):
3121         (bmalloc::Allocator::allocateSlowCase):
3122         * bmalloc/Allocator.h: Forward to DebugHeap instead of inlining all the
3123         code. This is required for our new interface, and it is also a nice
3124         simplification that moves some not-very-important code out of the way.
3125
3126         * bmalloc/Deallocator.cpp:
3127         (bmalloc::Deallocator::Deallocator):
3128         (bmalloc::Deallocator::scavenge):
3129         (bmalloc::Deallocator::deallocateSlowCase):
3130         * bmalloc/Deallocator.h: Ditto.
3131
3132         * bmalloc/DebugHeap.cpp: Added.
3133         (bmalloc::DebugHeap::DebugHeap):
3134         (bmalloc::DebugHeap::malloc):
3135         (bmalloc::DebugHeap::memalign):
3136         (bmalloc::DebugHeap::realloc):
3137         (bmalloc::DebugHeap::free):
3138         * bmalloc/DebugHeap.h: Added. New class for overriding normal heap
3139         behavior. Right now, it just adds a malloc zone and then forwards to
3140         system malloc -- but we can add lots more kinds of debug heaps in the
3141         future if we find them useful.
3142
3143         * bmalloc/Environment.cpp:
3144         (bmalloc::Environment::Environment):
3145         (bmalloc::Environment::computeIsDebugHeapEnabled):
3146         (bmalloc::Environment::computeIsBmallocEnabled): Deleted.
3147         * bmalloc/Environment.h:
3148         (bmalloc::Environment::isDebugHeapEnabled):
3149         (bmalloc::Environment::isBmallocEnabled): Deleted. Renamed everything to
3150         reflect our new use of DebugHeap.
3151
3152         * bmalloc/Heap.cpp:
3153         (bmalloc::Heap::Heap):
3154         * bmalloc/Heap.h:
3155         (bmalloc::Heap::debugHeap): Updated to use DebugHeap.
3156         (bmalloc::Heap::environment): Deleted. 
3157
3158         * bmalloc/bmalloc.h:
3159         (bmalloc::api::isEnabled): Updated to use DebugHeap.
3160
3161 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
3162
3163         Sort Xcode project files
3164         https://bugs.webkit.org/show_bug.cgi?id=165937
3165
3166         Reviewed by Simon Fraser.
3167
3168         * bmalloc.xcodeproj/project.pbxproj:
3169
3170 2016-12-08  David Kilzer  <ddkilzer@apple.com>
3171
3172         Always check the return value of pthread_key_create()
3173         <https://webkit.org/b/165274>
3174
3175         Reviewed by Darin Adler.
3176
3177         * bmalloc/PerThread.h:
3178         (bmalloc::PerThreadStorage::init): Call BCRASH() if
3179         pthread_key_create() returns an error.  The error code will be
3180         stored in a register available in a crash log, so no need to log
3181         the value explicitly.
3182
3183 2016-12-06  Alexey Proskuryakov  <ap@apple.com>
3184
3185         Correct SDKROOT values in xcconfig files
3186         https://bugs.webkit.org/show_bug.cgi?id=165487
3187         rdar://problem/29539209
3188
3189         Reviewed by Dan Bernstein.
3190
3191         Fix suggested by Dan Bernstein.
3192
3193         * Configurations/DebugRelease.xcconfig:
3194
3195 2016-11-29  Andy Estes  <aestes@apple.com>
3196
3197         [Cocoa] Enable two clang warnings recommended by Xcode
3198         https://bugs.webkit.org/show_bug.cgi?id=164498
3199
3200         Reviewed by Mark Lam.
3201
3202         * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
3203
3204 2016-11-10  Geoffrey Garen  <ggaren@apple.com>
3205
3206         bmalloc threads should have a non-default QoS
3207         https://bugs.webkit.org/show_bug.cgi?id=164612
3208
3209         Reviewed by Filip Pizlo.
3210
3211         * bmalloc/AsyncTask.h:
3212         (bmalloc::Function>::threadEntryPoint): Request user-interactive quality
3213         of service because user-interactive tasks use malloc.
3214
3215 2016-10-20  Mark Lam  <mark.lam@apple.com>
3216
3217         bmalloc api should crash on failure to allocate when !isBmallocEnabled.
3218         https://bugs.webkit.org/show_bug.cgi?id=163766
3219
3220         Reviewed by Keith Miller and Filip Pizlo.
3221
3222         We want to crash in bmalloc on failure to allocate even when !isBmallocEnabled.
3223         This is so that failures to allocate memory will manifest as crashes with a
3224         unique signature (i.e. as a SIGTRAP on release builds, or as a write to illegal
3225         address 0xbbadbeef on debug builds) and the crash will manifest inside bmalloc.
3226         This distinguishes allocation failures from other crashing bugs that manifest as
3227         SIGSEGVs due to random pointer dereferences in the clients of bmalloc.
3228
3229         * bmalloc/Allocator.cpp:
3230         (bmalloc::Allocator::allocateImpl):
3231         (bmalloc::Allocator::reallocate):
3232         (bmalloc::Allocator::allocateSlowCase):
3233
3234 2016-09-26  Yoshiaki Jitsukawa  <Yoshiaki.Jitsukawa@sony.com>
3235
3236         Avoid implicit conversion from iterator to pointer
3237         https://bugs.webkit.org/show_bug.cgi?id=162482
3238
3239         Reviewed by Geoffrey Garen.
3240
3241         Not every STL supporting such conversion, we should get a pointer explicitly.
3242
3243         * bmalloc/Chunk.h:
3244         (bmalloc::Chunk::lines):
3245         (bmalloc::Chunk::pages):
3246         * bmalloc/FixedVector.h:
3247         (bmalloc::FixedVector::begin):
3248
3249 2016-08-31  Filip Pizlo  <fpizlo@apple.com>
3250
3251         Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
3252         https://bugs.webkit.org/show_bug.cgi?id=160125
3253
3254         Reviewed by Geoffrey Garen and Keith Miller.
3255         
3256         I needed to tryMemalign, so I added such a thing.
3257
3258         * bmalloc/Allocator.cpp:
3259         (bmalloc::Allocator::allocate):
3260         (bmalloc::Allocator::tryAllocate):
3261         (bmalloc::Allocator::allocateImpl):
3262         * bmalloc/Allocator.h:
3263         * bmalloc/Cache.h:
3264         (bmalloc::Cache::tryAllocate):
3265         * bmalloc/bmalloc.h:
3266         (bmalloc::api::tryMemalign):
3267
3268 2016-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3269
3270         Unreviewed, build fix for GCC ports
3271
3272         std::forward is declared in <utility> header.
3273
3274         * bmalloc/ScopeExit.h:
3275
3276 2016-08-30  Geoffrey Garen  <ggaren@apple.com>
3277
3278         bmalloc: speed up the lock slow path
3279         https://bugs.webkit.org/show_bug.cgi?id=161058
3280
3281         Unreviewed roll-in - with regression fixed.
3282
3283         Revert to using yield() instead of swtch() because very low priority
3284         background tasks can cause priority inversion and deadlock. In the
3285         network process, that happened with com.apple.WebKit.Cache.Storage.serialBackground.
3286
3287         Still a big speedup on MallocBench.
3288
3289         * bmalloc.xcodeproj/project.pbxproj:
3290         * bmalloc/ScopeExit.h: Added.
3291         (bmalloc::ScopeExit::ScopeExit):
3292         (bmalloc::ScopeExit::~ScopeExit):
3293         (bmalloc::makeScopeExit):
3294         * bmalloc/StaticMutex.cpp:
3295         (bmalloc::StaticMutex::lockSlowCase):
3296         * bmalloc/StaticMutex.h:
3297         (bmalloc::StaticMutex::init):
3298
3299 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
3300
3301         Unreviewed build fix.
3302
3303         Fix the CMake build.
3304
3305         * CMakeLists.txt:
3306
3307 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
3308
3309         Renamed XLarge* => Large*
3310         https://bugs.webkit.org/show_bug.cgi?id=161261
3311
3312         Reviewed by Andreas Kling.
3313
3314         XLarge is not a thing anymore: We just have Small and Large.
3315
3316         * bmalloc.xcodeproj/project.pbxproj:
3317         * bmalloc/Heap.cpp:
3318         (bmalloc::Heap::splitAndAllocate):
3319         (bmalloc::Heap::tryAllocateLarge):
3320         (bmalloc::Heap::shrinkLarge):
3321         (bmalloc::Heap::deallocateLarge):
3322         * bmalloc/Heap.h:
3323         * bmalloc/LargeMap.cpp: Copied from Source/bmalloc/bmalloc/XLargeMap.cpp.
3324         (bmalloc::LargeMap::remove):
3325         (bmalloc::LargeMap::add):
3326         (bmalloc::XLargeMap::remove): Deleted.
3327         (bmalloc::XLargeMap::add): Deleted.
3328         * bmalloc/LargeMap.h: Copied from Source/bmalloc/bmalloc/XLargeMap.h.
3329         (bmalloc::LargeMap::ranges):
3330         (bmalloc::XLargeMap::ranges): Deleted.
3331         * bmalloc/LargeRange.h: Copied from Source/bmalloc/bmalloc/XLargeRange.h.
3332         (bmalloc::LargeRange::LargeRange):
3333         (bmalloc::LargeRange::operator<):
3334         (bmalloc::canMerge):
3335         (bmalloc::merge):
3336         (bmalloc::LargeRange::split):
3337         (bmalloc::XLargeRange::XLargeRange): Deleted.
3338         (bmalloc::XLargeRange::operator<): Deleted.
3339         (bmalloc::XLargeRange::split): Deleted.
3340         * bmalloc/VMHeap.cpp:
3341         (bmalloc::VMHeap::tryAllocateLargeChunk):
3342         * bmalloc/VMHeap.h:
3343         * bmalloc/XLargeMap.cpp: Removed.
3344         * bmalloc/XLargeMap.h: Removed.
3345         * bmalloc/XLargeRange.h: Removed.
3346
3347 2016-08-26  Gavin Barraclough  <barraclough@apple.com>
3348
3349         bmalloc: speed up the lock slow path
3350         https://bugs.webkit.org/show_bug.cgi?id=161058
3351
3352         Unreviewed rollout - this caused regressions <rdar://problem/28026089>.
3353
3354         * bmalloc.xcodeproj/project.pbxproj:
3355         * bmalloc/ScopeExit.h: Removed.
3356         * bmalloc/StaticMutex.cpp:
3357         (bmalloc::StaticMutex::lockSlowCase):
3358         * bmalloc/StaticMutex.h:
3359         (bmalloc::StaticMutex::init):
3360         * bmalloc/ThreadSwitch.h: Removed.
3361
3362 2016-08-24  Andreas Kling  <akling@apple.com>
3363
3364         Add bmalloc::api::isEnabled().
3365         <https://webkit.org/b/160534>
3366
3367         Reviewed by Joseph Pecoraro.
3368
3369         * bmalloc/bmalloc.h:
3370         (bmalloc::api::isEnabled):
3371
3372 2016-08-24  Filip Pizlo  <fpizlo@apple.com>
3373
3374         Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.
3375
3376         * bmalloc/Allocator.cpp:
3377         (bmalloc::Allocator::allocate):
3378         (bmalloc::Allocator::tryAllocate): Deleted.
3379         (bmalloc::Allocator::allocateImpl): Deleted.
3380         * bmalloc/Allocator.h:
3381         * bmalloc/Cache.h:
3382         (bmalloc::Cache::tryAllocate): Deleted.
3383         * bmalloc/bmalloc.h:
3384         (bmalloc::api::tryMemalign): Deleted.
3385
3386 2016-08-12  Filip Pizlo  <fpizlo@apple.com>
3387
3388         Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
3389         https://bugs.webkit.org/show_bug.cgi?id=160125
3390
3391         Reviewed by Geoffrey Garen.
3392         
3393         I needed to tryMemalign, so I added such a thing.
3394
3395         * bmalloc/Allocator.cpp:
3396         (bmalloc::Allocator::allocate):
3397         (bmalloc::Allocator::tryAllocate):
3398         (bmalloc::Allocator::allocateImpl):
3399         (bmalloc::Allocator::reallocate):
3400         * bmalloc/Allocator.h:
3401         * bmalloc/Cache.h:
3402         (bmalloc::Cache::allocate):
3403         (bmalloc::Cache::tryAllocate):
3404         * bmalloc/bmalloc.h:
3405         (bmalloc::api::malloc):
3406         (bmalloc::api::tryMemalign):
3407         (bmalloc::api::memalign):
3408
3409 2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3410
3411         Unreviewed, build fix on GCC environment
3412         https://bugs.webkit.org/show_bug.cgi?id=161058
3413
3414         std::forward is declared in <utility> header.
3415
3416         * bmalloc/ScopeExit.h:
3417
3418 2016-08-22  Geoffrey Garen  <ggaren@apple.com>
3419
3420         bmalloc: speed up the lock slow path
3421         https://bugs.webkit.org/show_bug.cgi?id=161058
3422
3423         Reviewed by Filip Pizlo.
3424
3425         It is generally accepted practice that a lock should yield instead of
3426         spinning when a lock acquisition fails, to avoid wasting CPU and power.
3427
3428         There are two problems with this generally accepted practice:
3429
3430         (1) It's a fallacy that yielding is free. In reality, yielding itself
3431         consumes CPU and power -- by performing a syscall, running the OS
3432         scheduler, and possibly performing a context switch. (Instruments
3433         traces of MallocBench show the cost of yielding.) Therefore, spinning a
3434         little to avoid yielding can actually *save* CPU and power.
3435
3436         (2) std::this_thread_yield() on Darwin is way too aggressive: It not only
3437         yields but also depresses your priority to absolute zero for 10ms. A
3438         recent PLT trace showed a few spots where the main thread just gave up
3439         on loading and rendering a page for 10ms so an unimportant background
3440         task could run.
3441
3442         To correct these problems, this patch adds a little bit of spinning to
3443         the bmalloc lock slow path.
3444
3445         Below are performance results on various CPUs.
3446
3447         Mac Pro (12 hyperthreaded cores = 24 threads):
3448
3449                                                             Baseline                       Patch                           Δ
3450             Execution Time:
3451                 message_one                                    173ms                       173ms                            
3452                 message_many                                   953ms                       927ms              ^ 1.03x faster
3453                 churn --parallel                                60ms                        41ms              ^ 1.46x faster
3454                 list_allocate --parallel                       224ms                       143ms              ^ 1.57x faster
3455                 tree_allocate --parallel                     1,190ms                       758ms              ^ 1.57x faster
3456                 tree_churn --parallel                        1,517ms                       906ms              ^ 1.67x faster
3457                 facebook --parallel                          6,519ms                     4,580ms              ^ 1.42x faster
3458                 reddit --parallel                            5,097ms                     3,411ms              ^ 1.49x faster
3459                 flickr --parallel                            4,903ms                     3,501ms               ^ 1.4x faster
3460                 theverge --parallel                          6,641ms                     4,505ms              ^ 1.47x faster
3461
3462                 <geometric mean>                             1,158ms                       832ms              ^ 1.39x faster
3463                 <arithmetic mean>                            2,728ms                     1,895ms              ^ 1.44x faster
3464                 <harmonic mean>                                332ms                       240ms              ^ 1.38x faster
3465
3466         MacBook Air (2 hyperthreaded cores = 4 threads):
3467
3468                                                             Baseline                       Patch                           Δ
3469             Execution Time:
3470                 message_one                                    911ms                       907ms               ^ 1.0x faster
3471                 message_many                                   515ms                       513ms               ^ 1.0x faster
3472                 churn --parallel                               132ms                       134ms              ! 1.02x slower
3473                 list_allocate --parallel                       104ms                       102ms              ^ 1.02x faster
3474                 tree_allocate --parallel                       117ms                       111ms              ^ 1.05x faster
3475                 tree_churn --parallel                          154ms                       151ms              ^ 1.02x faster
3476                 facebook --parallel                            719ms                       687ms              ^ 1.05x faster
3477                 reddit --parallel                              382ms                       341ms              ^ 1.12x faster
3478                 flickr --parallel                              372ms                       345ms              ^ 1.08x faster
3479                 theverge --parallel                            489ms                       444ms               ^ 1.1x faster
3480
3481                 <geometric mean>                               299ms                       287ms              ^ 1.04x faster
3482                 <arithmetic mean>                              390ms                       374ms              ^ 1.04x faster
3483                 <harmonic mean>                                227ms                       220ms              ^ 1.03x faster
3484
3485         iPad (2 cores = 2 threads):
3486
3487             [ Doesn't run Ruby, so no pretty subtest output. ]
3488
3489                                                             Baseline                       Patch                           Δ
3490             Execution Time:                                 174.14ms                     171.5ms              ^ 1.02x faster
3491
3492         * bmalloc.xcodeproj/project.pbxproj:
3493
3494         * bmalloc/ScopeExit.h: Added. A barebones very wimpy version of
3495         WTF::ScopeExit.
3496         (bmalloc::ScopeExit::ScopeExit):
3497         (bmalloc::ScopeExit::~ScopeExit):
3498         (bmalloc::makeScopeExit):
3499
3500         * bmalloc/StaticMutex.cpp:
3501         (bmalloc::StaticMutex::lockSlowCase): Spin before yielding -- that's the
3502         speedup. Don't spin if another CPU is already spinning. In theory, more
3503         than one spinner accomplishes nothing, and I found that there's a cutoff
3504         around 8 or 16 spinners that becomes performance negative on Mac Pro.
3505
3506         (Note: Another way to accomplish a similar result, if you don't want to
3507         use a bit of state in the lock, is to spin for a random duration between
3508         0 and aLot. I tested a version of WTF::WeakRandom with unsynchronized
3509         static state and it worked great. But I ultimately opted for the explicit
3510         bit because I thought it was clearer.)
3511
3512         * bmalloc/StaticMutex.h:
3513         (bmalloc::StaticMutex::init): Initialize our new bit.
3514
3515         * bmalloc/ThreadSwitch.h: Added.
3516         (bmalloc::threadSwitch): Don't call yield() on Darwin because it's too
3517         aggressive. swtch() does what we want: Go run something else, without
3518         any other side-effects.
3519
3520 2016-08-03  Geoffrey Garen  <ggaren@apple.com>
3521
3522         [bmalloc] Merging of XLargeRanges can leak the upper range
3523         https://bugs.webkit.org/show_bug.cgi?id=160403
3524
3525         Reviewed by Michael Saboff.
3526
3527         * bmalloc/Heap.cpp:
3528         (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
3529         Recorded physical size is a performance optimization. It is not the
3530         truth. So it might be zero even if a range contains physical pages.
3531
3532         Instead, iterate each range in the map unconditionally.
3533
3534         The map can shrink when we release the lock, so we must clamp our
3535         iterator each time through the loop.
3536
3537         The map can grow when we release the lock, but we don't care because
3538         growth restarts the scavenger from the beginning.
3539
3540         * bmalloc/XLargeMap.cpp:
3541         (bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.
3542
3543         * bmalloc/XLargeMap.h:
3544         (bmalloc::XLargeMap::ranges): Added direct access for the sake of
3545         scavengeLargeObjects. (This violates our naming conventions -- I'll do
3546         a rename in a follow-up patch.)
3547
3548 2016-07-13  Enrica Casucci  <enrica@apple.com>
3549
3550         Update supported platforms in xcconfig files to match the sdk names.
3551         https://bugs.webkit.org/show_bug.cgi?id=159728
3552
3553         Reviewed by Tim Horton.
3554
3555         * Configurations/Base.xcconfig:
3556
3557 2016-07-11  Geoffrey Garen  <ggaren@apple.com>
3558
3559         Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
3560         https://bugs.webkit.org/show_bug.cgi?id=159655
3561
3562         Reviewed by Sam Weinig.
3563
3564         It's not entirely clear what was happening in these crashes, but our
3565         use of detach() was 100% forward-looking, so we can just remove it for
3566         now.
3567
3568         This patch removes the ability for the scavenger owner to die before
3569         the scavenger thread dies (which was unused) and also removes the
3570         ability for the scavenger thread to exit (which was used, but we
3571         messed up and did thread joining lazily, so we never got any benefit
3572         from thread exit.)
3573
3574         We can add these features back when we need them, and make them work then.
3575
3576         * bmalloc/AsyncTask.h:
3577         (bmalloc::Function>::AsyncTask): We start out in the running state now
3578         because we know that starting our thread will run it.
3579
3580         (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
3581
3582         (bmalloc::Function>::runSlowCase): I removed the Exited state.
3583
3584         (bmalloc::Function>::threadRunLoop): I removed the Exited and
3585         ExitRequested states.
3586
3587         * bmalloc/Heap.h:
3588
3589         * bmalloc/VMHeap.h:
3590
3591 2016-06-12  David Kilzer  <ddkilzer@apple.com>
3592
3593         Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
3594         <https://webkit.org/b/158660>
3595         <rdar://problem/25652686>
3596
3597         Reviewed by Darin Adler.
3598
3599         * bmalloc/Logging.cpp: Switch to use
3600         BSOFT_LINK_PRIVATE_FRAMEWORK() to link
3601         CrashReporterSupport.framework.
3602         * bmalloc/darwin/BSoftLinking.h:
3603         (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
3604         Switch to use /System/Library/PrivateFrameworks/.
3605
3606 2016-06-11  David Kilzer  <ddkilzer@apple.com>
3607
3608         Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
3609         <http://webkit.org/b/155992>
3610
3611         Reviewed by Geoff Garen.
3612
3613         * bmalloc/BAssert.h:
3614         (BLOG_ERROR): Add method to always log error messages.
3615         (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
3616         logging in Debug builds.
3617         * bmalloc/BPlatform.h:
3618         (BPLATFORM_MAC): Add.
3619         (BUSE): Add BUSE() macro.
3620         (BATTRIBUTE_PRINTF): Add.
3621         (BUSE_OS_LOG): Add.
3622         * bmalloc/Logging.cpp:
3623         (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
3624         stderr.
3625         * bmalloc/Logging.h:
3626         (bmalloc::reportAssertionFailureWithMessage): Add declaration.
3627
3628 2016-06-07  Pranjal Jumde  <pjumde@apple.com>
3629
3630         Prevents integer overflow in Vector.h
3631         https://bugs.webkit.org/show_bug.cgi?id=158455
3632         <rdar://problem/20235469>
3633
3634         Reviewed by Mark Lam.
3635
3636         * bmalloc/Vector.h:
3637         (bmalloc::Vector<T>::reallocateBuffer):
3638
3639 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
3640
3641         [cmake] Deduplicated bmalloc/Zone.cpp handling.
3642         https://bugs.webkit.org/show_bug.cgi?id=158154
3643
3644         Reviewed by Alex Christensen.
3645
3646         File bmalloc/Zone.cpp is required on Darwin irrespectively from what
3647         port is being built.
3648
3649         Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
3650         unlikely that bmalloc will ever need port-specific customizations (as
3651         opposed to OS-specific customizations which should be done in
3652         CMakeLists.txt).
3653
3654         * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
3655         * PlatformGTK.cmake: Removed.
3656         * PlatformMac.cmake: Removed.
3657
3658 2016-05-22  Brady Eidson  <beidson@apple.com>
3659
3660         Move to C++14.
3661         https://bugs.webkit.org/show_bug.cgi?id=157948
3662
3663         Reviewed by Michael Catanzaro.
3664
3665         * Configurations/Base.xcconfig:
3666
3667 2016-05-17  Geoffrey Garen  <ggaren@apple.com>
3668
3669         REGRESSION: JetStream crashes on some iPhones
3670         https://bugs.webkit.org/show_bug.cgi?id=157814
3671
3672         Reviewed by Michael Saboff.
3673
3674         * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
3675
3676         Previous justification for 64kB was:
3677
3678             * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
3679             reasonable, since sizes between 16kB and 32kB share page sizes. I went
3680             all the way up to 64kB because the GC uses 64kB blocks, and also just
3681             for extra padding to ensure that large allocations are indeed rare.
3682
3683         It turns out that the bump to 64kB substantially increases our memory
3684         high water mark on JetStream, leading to jetsam crashes. Also, there
3685         doesn't seem to be a practical performance problem to putting objects in
3686         the (32kB - 64kB) range in the large allocator.
3687
3688 2016-05-16  Geoffrey Garen  <ggaren@apple.com>
3689
3690         REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
3691         https://bugs.webkit.org/show_bug.cgi?id=157764
3692
3693         Reviewed by Gavin Barraclough.
3694
3695         We need to allow for guard pages and only report unguarded pages to the
3696         leaks tool -- otherwise, it will try to remote map our guarded pages,
3697         and crash.
3698
3699         * bmalloc/VMHeap.cpp:
3700         (bmalloc::VMHeap::tryAllocateLargeChunk):
3701         (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
3702         a range instead of a Chunk*, and report the unguarded range.
3703
3704         This also fixes a separate bug -- very large allocations would not
3705         fully participate in pointer scanning because they would only report 2MB
3706         (chunkSize) in size. This could cause false-positive leak reports.
3707
3708         * bmalloc/Zone.cpp:
3709         (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
3710         Chunk pointers.
3711
3712         * bmalloc/Zone.h:
3713         (bmalloc::Zone::ranges):
3714         (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
3715         pointers because our VM ranges have variable sizes -- both due to guard
3716         pages and due to large allocations.
3717
3718         (bmalloc::Zone::chunks): Deleted.
3719         (bmalloc::Zone::addChunk): Deleted.
3720
3721 2016-05-10  David Kilzer  <ddkilzer@apple.com>
3722
3723         bmalloc should automatically disable itself when ThreadSanitizer is used
3724         <https://webkit.org/b/157527>
3725
3726         Reviewed by Michael Catanzaro.
3727
3728         * bmalloc/Environment.cpp:
3729         (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
3730         (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
3731         support for detecting ThreadSanitizer.
3732         (bmalloc::Environment::computeIsBmallocEnabled): Switch from
3733         isASanEnabled to isSanitizerEnabled.
3734
3735 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
3736
3737         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3738         https://bugs.webkit.org/show_bug.cgi?id=157047
3739
3740         Reviewed by Filip Pizlo.
3741
3742         Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
3743
3744         * bmalloc/Algorithm.h:
3745         (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
3746         (bmalloc::roundUpToMultipleOfSloppy): Deleted.
3747         * bmalloc/VMHeap.cpp:
3748         (bmalloc::VMHeap::allocateSmallChunk):
3749
3750 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
3751
3752         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3753         https://bugs.webkit.org/show_bug.cgi?id=157047
3754
3755         Reviewed by Filip Pizlo.
3756
3757         The previous fix aligned the guard page sizes correctly but forgot to
3758         align the guard page start address correctly.
3759
3760         * bmalloc/Algorithm.h:
3761         (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
3762         up when not working with a power of two, instead of writing out the
3763         math by hand.
3764
3765         * bmalloc/VMHeap.cpp:
3766         (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
3767         page start address in addition to its size. Assert at the very end to
3768         try to catch more bugs.
3769
3770 2016-04-27  Geoffrey Garen  <ggaren@apple.com>
3771
3772         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3773         https://bugs.webkit.org/show_bug.cgi?id=157047
3774
3775         Reviewed by Darin Adler.
3776
3777         * bmalloc/Chunk.h:
3778         (bmalloc::Chunk::Chunk):
3779         (bmalloc::Chunk::get):
3780         (bmalloc::Chunk::offset):
3781         (bmalloc::Chunk::address):
3782         (bmalloc::Object::Object):
3783         (bmalloc::Object::address):
3784         (bmalloc::Object::line):
3785         (bmalloc::Chunk::object): Deleted.
3786         (bmalloc::Object::begin): Deleted.
3787         * bmalloc/Heap.cpp:
3788         (bmalloc::Heap::allocateSmallBumpRangesByObject):
3789         * bmalloc/Object.h:
3790         (bmalloc::Object::chunk):
3791         (bmalloc::Object::offset): Renamed begin() to address() because this is
3792         not an iterator.
3793
3794         * bmalloc/VMHeap.cpp:
3795         (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
3796         multiple because pageSize might be smaller than vmPageSize, but we
3797         think the VM system requires vmPageSize-aligned values.
3798
3799 2016-04-25  Geoffrey Garen  <ggaren@apple.com>
3800
3801         bmalloc: vm allocations should plant guard pages
3802         https://bugs.webkit.org/show_bug.cgi?id=156937
3803
3804         Rolling back in r199936 with a fix for the memory regression.
3805
3806 2016-04-23  Gavin Barraclough  <barraclough@apple.com>
3807
3808         bmalloc: vm allocations should plant guard pages
3809         https://bugs.webkit.org/show_bug.cgi?id=156937
3810
3811         Rolling out - looks like this is memory regression.
3812
3813         * bmalloc/Object.h:
3814         (bmalloc::Object::operator+):
3815         (bmalloc::Object::operator<=):
3816         (bmalloc::Object::operator-): Deleted.
3817         * bmalloc/VMAllocate.h:
3818         (bmalloc::vmDeallocate):
3819         (bmalloc::vmRevokePermissions): Deleted.
3820         * bmalloc/VMHeap.cpp:
3821         (bmalloc::VMHeap::allocateSmallChunk):
3822
3823 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
3824
3825         bmalloc: vm allocations should plant guard pages
3826         https://bugs.webkit.org/show_bug.cgi?id=156937
3827
3828         Reviewed by Michael Saboff.
3829
3830         * bmalloc/Object.h:
3831         (bmalloc::Object::operator-): Added a - helper.
3832
3833         * bmalloc/VMAllocate.h:
3834         (bmalloc::vmRevokePermissions): Added a helper to revoke permissions on
3835         a VM region. We use this for guard pages.
3836
3837         * bmalloc/VMHeap.cpp:
3838         (bmalloc::VMHeap::allocateSmallChunk): Add guard pages to the start and
3839         end of the chunk.
3840
3841         Note that we don't guard large chunks becuase we need to be able to merge
3842         them. Otherwise, we will run out of virtual addresses.
3843
3844 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
3845
3846         bmalloc: Constify introspect function pointer table
3847         https://bugs.webkit.org/show_bug.cgi?id=156936
3848
3849         Reviewed by Michael Saboff.
3850
3851         * bmalloc/Zone.cpp:
3852         (bmalloc::Zone::Zone): Declaring this function pointer table const puts
3853         it in the read-only section of the binary, providing a little hardening
3854         against overwriting the function pointers at runtime. (We have to
3855         const_cast when assigning because the API declares a pointer to non-const,
3856         but we happen to know it will never try to write through that pointer.
3857         This is not my favorite API.)
3858
3859 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3860
3861         bmalloc: fix up overflow checks
3862         https://bugs.webkit.org/show_bug.cgi?id=156780
3863
3864         Reviewed by Mark Lam.
3865
3866         We used to try to avoid overflow in large object math by setting a very
3867         high limit on the largest large object. But that's a bit error-prone
3868         since the check is far away from the math that might overflow -- and
3869         we were missing some cases.
3870
3871         This patch removes the limit and instead checks at each math site.
3872
3873         * bmalloc/Allocator.cpp:
3874         (bmalloc::Allocator::tryAllocate):
3875         (bmalloc::Allocator::allocate):
3876         (bmalloc::Allocator::reallocate):
3877         (bmalloc::Allocator::allocateSlowCase): Remove the limit. tryAllocateLarge
3878         will check for overflow for us.
3879
3880         * bmalloc/Chunk.h: This ASSERT was just totally wrong.
3881
3882         * bmalloc/Heap.cpp:
3883         (bmalloc::Heap::tryAllocateLarge): Check for overflow when adding.
3884
3885         * bmalloc/Sizes.h:
3886
3887         * bmalloc/VMAllocate.h:
3888         (bmalloc::tryVMAllocate): Check for overflow when adding.
3889
3890         * bmalloc/VMHeap.cpp:
3891         (bmalloc::VMHeap::tryAllocateLargeChunk): Check for overflow when adding.
3892
3893 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3894
3895         Unreviewed, try to fix an ASSERT seen on the bots.
3896
3897         * bmalloc/Heap.cpp:
3898         (bmalloc::Heap::tryAllocateLarge): This ASSERT is supposed to be about
3899         alignment, not size. Oops.
3900
3901 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3902
3903         bmalloc: Merge the large and xlarge allocators
3904         https://bugs.webkit.org/show_bug.cgi?id=156734
3905
3906         Reviewed by Andreas Kling.
3907
3908         This give us better defense against worst case memory usage:
3909
3910                                               Baseline                Patch                    Δ
3911             Peak Memory:
3912                 nimlang                      198,132kB            181,468kB      ^ 1.09x smaller
3913
3914         It also eliminates inline metadata for large objects, fixing the
3915         regression introduced in r198675, and more:
3916
3917             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3918
3919                                                                   Baseline                          Patch                              Δ
3920             Memory at End:
3921                 big                                               10,880kB                        3,328kB                ^ 3.27x smaller
3922                 facebook                                           3,112kB                        2,868kB                ^ 1.09x smaller
3923                 fragment --parallel                                1,848kB                          760kB                ^ 2.43x smaller
3924                 fragment_iterate --parallel                        4,908kB                          776kB                ^ 6.32x smaller
3925                 big --parallel                                    48,076kB                       11,892kB                ^ 4.04x smaller
3926
3927         Overall memory use looks OK:
3928
3929             run-malloc-benchmarks --memory_warning Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3930
3931                                                         Baseline                               Patch                                   Δ
3932             Memory at End:
3933                 <arithmetic mean>                       13,992kB                            13,987kB                      ^ 1.0x smaller
3934
3935         Overall throughput looks OK:
3936
3937             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3938
3939                                                                   Baseline                          Patch                              Δ
3940             Execution Time:
3941                 <arithmetic mean>                                    103ms                          104ms                 ! 1.01x slower
3942
3943         We're a bit slower on the "all-out large allocations on all cores"
3944         benchmark, but I think that's an OK price to pay:
3945
3946                                                                   Baseline                          Patch                              Δ
3947             Execution Time:
3948                 big --parallel                                       125ms                          136ms                 ! 1.09x slower
3949
3950         This patch net removes 1.5k lines of code. It turns out that large
3951         allocations are rare, and free memory fragments are also rare, so the
3952         combination is super rare, and a simple O(n) algorithm that ensures good
3953         memory behavior is the best option.
3954
3955         Fun fact: In practice, the odds that the old code would save memory
3956         were *worse* than the odds that it would contain a bug that wasted
3957         memory. :)
3958
3959         * bmalloc.xcodeproj/project.pbxproj:
3960
3961         * bmalloc/Allocator.cpp:
3962         (bmalloc::Allocator::tryAllocate): largeMax is the new xLargeMax since
3963         xLargeMax is gone now.
3964
3965         (bmalloc::Allocator::allocate): I moved the rounding code into allocateLarge,
3966         so we don't have to do it here.
3967
3968         (bmalloc::Allocator::reallocate):
3969         (bmalloc::Allocator::allocateSlowCase):
3970         (bmalloc::Allocator::allocateXLarge): Deleted. No more XLarge case.
3971
3972         * bmalloc/Allocator.h:
3973
3974         * bmalloc/BeginTag.h: Removed.
3975         * bmalloc/BoundaryTag.h: Removed.
3976
3977         * bmalloc/Chunk.h:
3978         (bmalloc::ChunkHash::hash): Added a hash function. The best hash function
3979         is a unique and monotonically increasing integer, and that's exactly what
3980         we typically get from the high bits of a Chunk, since the OS allocates
3981         Chunks at unique and increasing addresses.
3982         (bmalloc::Chunk::boundaryTags): Deleted.
3983         (bmalloc::Chunk::objectType): Deleted.
3984         (bmalloc::Chunk::beginTag): Deleted.
3985         (bmalloc::Chunk::endTag): Deleted.
3986
3987         * bmalloc/Deallocator.cpp:
3988         (bmalloc::Deallocator::deallocateSlowCase): We no longer know for sure,
3989         by looking at its bit pattern, whether a pointer is small or large.
3990         Instead, any pointer with large alignment *might* be large, and when
3991         we occasionally encounter such an object, we have to consult a hash
3992         table in the Heap to find out for sure. This turns out to be just as
3993         cheap in practice.
3994
3995         We don't deallocate large objects on the fast path anymore. We can't,
3996         because large objects have out-of-line metadata now.
3997
3998         (bmalloc::Deallocator::deallocateXLarge): Deleted.
3999
4000         * bmalloc/Deallocator.h:
4001         (bmalloc::Deallocator::deallocateFastCase): See deallocateSlowCase.
4002
4003         * bmalloc/EndTag.h: Removed.
4004         * bmalloc/FreeList.cpp: Removed.
4005         * bmalloc/FreeList.h: Removed.
4006
4007         * bmalloc/Heap.cpp:
4008         (bmalloc::Heap::allocateSmallPage): Be sure to track each chunk in
4009         the object type map, so we can distinguish small vs large objects.
4010
4011         (bmalloc::Heap::deallocateSmallLine): No need to check object type
4012         because we know object type now by virtue of being on the small object
4013         path.
4014
4015         (bmalloc::Heap::splitAndAllocate): Be sure to track each chunk in
4016         the object type map, so we can distinguish small vs large objects. Large
4017         objects can split across chunks, so we need to add&