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