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