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