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