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