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