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