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