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