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