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