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