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