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