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