ad0ac34ac440dc2dc96b2194f4e4f156010da011
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2017-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [Linux] Port MallocBench
4         https://bugs.webkit.org/show_bug.cgi?id=177856
5
6         Reviewed by Filip Pizlo.
7
8         * CMakeLists.txt:
9
10 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
11
12         bmalloc mutex should be adaptive
13         https://bugs.webkit.org/show_bug.cgi?id=177839
14
15         Reviewed by Michael Saboff.
16         
17         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
18         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
19         anything other than malloc.
20
21         * bmalloc/Algorithm.h:
22         (bmalloc::compareExchangeWeak):
23         (bmalloc::compareExchangeStrong):
24         * bmalloc/PerThread.h:
25         * bmalloc/StaticMutex.cpp:
26         (bmalloc::StaticMutex::lockSlow):
27         (bmalloc::StaticMutex::unlockSlow):
28         (bmalloc::StaticMutex::lockSlowCase): Deleted.
29         * bmalloc/StaticMutex.h:
30         (bmalloc::StaticMutex::try_lock):
31         (bmalloc::StaticMutex::isLocked const):
32         (bmalloc::StaticMutex::init):
33         (bmalloc::StaticMutex::tryLock):
34         (bmalloc::StaticMutex::lock):
35         (bmalloc::StaticMutex::unlock):
36         (bmalloc::sleep): Deleted.
37         (bmalloc::waitUntilFalse): Deleted.
38
39 2017-10-02  Yusuke Suzuki  <utatane.tea@gmail.com>
40
41         [Linux] Enable Gigacage in x64 Linux environment
42         https://bugs.webkit.org/show_bug.cgi?id=177745
43
44         Reviewed by Carlos Garcia Campos.
45
46         This patch enables Gigacage in x64 Linux environment.
47         Gigacage enforces a caged pointer to reference to the
48         specific memory region. This reduces the effectiveness
49         of some types of attacks setting a pointer to ArrayBuffer
50         and modifying arbitrary memory region.
51
52         * bmalloc/Gigacage.h:
53
54 2017-09-29  Commit Queue  <commit-queue@webkit.org>
55
56         Unreviewed, rolling out r222625.
57         https://bugs.webkit.org/show_bug.cgi?id=177664
58
59         causes crashes on iOS (Requested by pizlo-mbp on #webkit).
60
61         Reverted changeset:
62
63         "Enable gigacage on iOS"
64         https://bugs.webkit.org/show_bug.cgi?id=177586
65         http://trac.webkit.org/changeset/222625
66
67 2017-09-28  Filip Pizlo  <fpizlo@apple.com>
68
69         Enable gigacage on iOS
70         https://bugs.webkit.org/show_bug.cgi?id=177586
71
72         Reviewed by Michael Saboff.
73         
74         This enables Gigacage on iOS using a much smaller cage size. It's not necessary for it to be so
75         small, but this is a good conservative starting point to start to exercise the code.
76
77         * bmalloc/Gigacage.h:
78
79 2017-09-26  Filip Pizlo  <fpizlo@apple.com>
80
81         Put g_gigacageBasePtr into its own page and make it read-only
82         https://bugs.webkit.org/show_bug.cgi?id=174972
83
84         Reviewed by Michael Saboff.
85         
86         This puts the gigacage base pointers into their own page and makes that page read-only.
87
88         * bmalloc/Gigacage.cpp:
89         (Gigacage::ensureGigacage):
90         (Gigacage::disablePrimitiveGigacage):
91         (Gigacage::addPrimitiveDisableCallback):
92         * bmalloc/Gigacage.h:
93         (Gigacage::basePtr):
94         (Gigacage::basePtrs):
95
96 2017-09-04  Adrian Perez de Castro  <aperez@igalia.com>
97
98         Unreviewed build fix for Clang with libc++
99
100         Fixes a build failure when building with Clang, -stdlib=libc++, and gigacage
101         support enabled, which resulted in "stderr" being undefined.
102
103         * bmalloc/Gigacage.cpp: Add missing <ctsdio> include to pull the definition.
104
105 2017-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>
106
107         Large virtual memory region allocation requires MMAP_NORESERVE in Linux
108         https://bugs.webkit.org/show_bug.cgi?id=176211
109
110         Reviewed by Geoffrey Garen.
111
112         In Linux, we cannot allocate very large memory region without MMAP_NORESERVE.
113         Linux kernel needs to reserve swap area for allocated memory region. If the
114         swap area is exhausted, kernel fails to allocate the memory region with ENOMEM.
115
116         This patch adds MMAP_NORESERVE to mmap flags in Linux. By adding this flag,
117         mmap does not need to reserve swap area for the reserved memory region.
118         This allows us to reserve very large memory region that is necessary for Gigacage.
119
120         * bmalloc/BPlatform.h:
121         * bmalloc/VMAllocate.h:
122         (bmalloc::tryVMAllocate):
123
124 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
125
126         Strings need to be in some kind of gigacage
127         https://bugs.webkit.org/show_bug.cgi?id=174924
128
129         Reviewed by Oliver Hunt.
130         
131         This adds a StringGigacage.
132
133         * bmalloc/Gigacage.cpp:
134         * bmalloc/Gigacage.h:
135         (Gigacage::name):
136         (Gigacage::basePtr):
137         (Gigacage::forEachKind):
138         * bmalloc/HeapKind.h:
139         (bmalloc::isGigacage):
140         (bmalloc::gigacageKind):
141         (bmalloc::heapKind):
142
143 2017-08-30  Matt Lewis  <jlewis3@apple.com>
144
145         Unreviewed, rolling out r221384.
146
147         This patch caused multiple 32-bit JSC test failures.
148
149         Reverted changeset:
150
151         "Strings need to be in some kind of gigacage"
152         https://bugs.webkit.org/show_bug.cgi?id=174924
153         http://trac.webkit.org/changeset/221384
154
155 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
156
157         Strings need to be in some kind of gigacage
158         https://bugs.webkit.org/show_bug.cgi?id=174924
159
160         Reviewed by Oliver Hunt.
161         
162         This adds a StringGigacage.
163
164         * bmalloc/Gigacage.cpp:
165         * bmalloc/Gigacage.h:
166         (Gigacage::name):
167         (Gigacage::basePtr):
168         (Gigacage::forEachKind):
169         * bmalloc/HeapKind.h:
170         (bmalloc::isGigacage):
171         (bmalloc::gigacageKind):
172         (bmalloc::heapKind):
173
174 2017-08-25  Daniel Bates  <dabates@apple.com>
175
176         Demarcate code added due to lack of NSDMI for aggregates
177         https://bugs.webkit.org/show_bug.cgi?id=175990
178
179         Reviewed by Andy Estes.
180
181         * bmalloc/BPlatform.h:
182         * bmalloc/List.h: Be explicit when initializing m_node to improve readability.
183         (bmalloc::ListNode::ListNode):
184
185 2017-08-23  Filip Pizlo  <fpizlo@apple.com>
186
187         Reduce Gigacage sizes
188         https://bugs.webkit.org/show_bug.cgi?id=175920
189
190         Reviewed by Mark Lam.
191
192         This introduces the ability to have different gigacage sizes for different gigacages, and uses it to reduce the size of both
193         gigacages, but to different extents: Primitive gets 32GB with a 16GB runway and JSValue gets 16GB.
194
195         This is a ~10% membuster progression on my Mac Pro.
196
197         * bmalloc/Gigacage.cpp:
198         (Gigacage::ensureGigacage):
199         * bmalloc/Gigacage.h:
200         (Gigacage::size):
201         (Gigacage::alignment):
202         (Gigacage::mask):
203         (Gigacage::runway):
204         (Gigacage::totalSize):
205         (Gigacage::caged):
206         * bmalloc/Heap.cpp:
207         (bmalloc::Heap::Heap):
208         (bmalloc::Heap::gigacageSize):
209         * bmalloc/Heap.h:
210
211 2017-08-08  Filip Pizlo  <fpizlo@apple.com>
212
213         Baseline JIT should do caging
214         https://bugs.webkit.org/show_bug.cgi?id=175037
215
216         Reviewed by Mark Lam.
217         
218         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
219         and WebProcess.
220         
221         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
222         checks on each typed array access.
223
224         * bmalloc/Gigacage.cpp:
225         (Gigacage::primitiveGigacageDisabled):
226         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
227         (Gigacage::isDisablingPrimitiveGigacageDisabled):
228         * bmalloc/Gigacage.h:
229         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
230         (Gigacage::canPrimitiveGigacageBeDisabled):
231
232 2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>
233
234         Unreviewed, rolling out r220368.
235
236         This change caused WK1 tests to exit early with crashes.
237
238         Reverted changeset:
239
240         "Baseline JIT should do caging"
241         https://bugs.webkit.org/show_bug.cgi?id=175037
242         http://trac.webkit.org/changeset/220368
243
244 2017-08-07  Filip Pizlo  <fpizlo@apple.com>
245
246         Baseline JIT should do caging
247         https://bugs.webkit.org/show_bug.cgi?id=175037
248
249         Reviewed by Mark Lam.
250         
251         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
252         and WebProcess.
253         
254         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
255         checks on each typed array access.
256
257         * bmalloc/Gigacage.cpp:
258         (Gigacage::primitiveGigacageDisabled):
259         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
260         (Gigacage::isDisablingPrimitiveGigacageDisabled):
261         * bmalloc/Gigacage.h:
262         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
263         (Gigacage::canPrimitiveGigacageBeDisabled):
264
265 2017-08-06  Filip Pizlo  <fpizlo@apple.com>
266
267         Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
268         https://bugs.webkit.org/show_bug.cgi?id=174919
269
270         Reviewed by Keith Miller.
271         
272         This introduces two kinds of Gigacage, Primitive and JSValue. This translates to two kinds of
273         HeapKind, PrimitiveGigacage and JSValueGigacage.
274         
275         The new support functionality required turning Inline.h into BInline.h, and INLINE into BINLINE, and
276         NO_INLINE into BNO_INLINE.
277
278         * bmalloc.xcodeproj/project.pbxproj:
279         * bmalloc/Allocator.cpp:
280         (bmalloc::Allocator::refillAllocatorSlowCase):
281         (bmalloc::Allocator::refillAllocator):
282         (bmalloc::Allocator::allocateLarge):
283         (bmalloc::Allocator::allocateLogSizeClass):
284         * bmalloc/AsyncTask.h:
285         * bmalloc/BInline.h: Copied from Source/bmalloc/bmalloc/Inline.h.
286         * bmalloc/Cache.cpp:
287         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
288         (bmalloc::Cache::allocateSlowCaseNullCache):
289         (bmalloc::Cache::deallocateSlowCaseNullCache):
290         (bmalloc::Cache::reallocateSlowCaseNullCache):
291         * bmalloc/Deallocator.cpp:
292         * bmalloc/Gigacage.cpp:
293         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
294         (Gigacage::ensureGigacage):
295         (Gigacage::disablePrimitiveGigacage):
296         (Gigacage::addPrimitiveDisableCallback):
297         (Gigacage::removePrimitiveDisableCallback):
298         (Gigacage::Callbacks::Callbacks): Deleted.
299         (Gigacage::disableGigacage): Deleted.
300         (Gigacage::addDisableCallback): Deleted.
301         (Gigacage::removeDisableCallback): Deleted.
302         * bmalloc/Gigacage.h:
303         (Gigacage::name):
304         (Gigacage::basePtr):
305         (Gigacage::forEachKind):
306         (Gigacage::caged):
307         (Gigacage::isCaged):
308         * bmalloc/Heap.cpp:
309         (bmalloc::Heap::Heap):
310         (bmalloc::Heap::usingGigacage):
311         (bmalloc::Heap::gigacageBasePtr):
312         * bmalloc/Heap.h:
313         * bmalloc/HeapKind.h:
314         (bmalloc::isGigacage):
315         (bmalloc::gigacageKind):
316         (bmalloc::heapKind):
317         * bmalloc/Inline.h: Removed.
318         * bmalloc/Map.h:
319         * bmalloc/PerProcess.h:
320         (bmalloc::PerProcess<T>::getFastCase):
321         (bmalloc::PerProcess<T>::get):
322         (bmalloc::PerProcess<T>::getSlowCase):
323         * bmalloc/PerThread.h:
324         (bmalloc::PerThread<T>::getFastCase):
325         * bmalloc/Vector.h:
326         (bmalloc::Vector<T>::push):
327         (bmalloc::Vector<T>::shrinkCapacity):
328         (bmalloc::Vector<T>::growCapacity):
329
330 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
331
332         If Gigacage is disabled, bmalloc should service large aligned memory allocation requests through vmAllocate
333         https://bugs.webkit.org/show_bug.cgi?id=175085
334
335         Reviewed by Saam Barati.
336         
337         This fixes a problem where if we used gmalloc, WebAssembly memory allocations would still use
338         bmalloc's large allocator.
339         
340         We want to use the page allocator for those "large" allocations when the Gigacage is disabled.
341
342         * bmalloc/DebugHeap.cpp:
343         (bmalloc::DebugHeap::DebugHeap):
344         (bmalloc::DebugHeap::memalignLarge):
345         (bmalloc::DebugHeap::freeLarge):
346         * bmalloc/DebugHeap.h:
347         * bmalloc/Heap.cpp:
348         (bmalloc::Heap::tryAllocateLarge):
349         (bmalloc::Heap::deallocateLarge):
350
351 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
352
353         We should be OK with the gigacage being disabled on gmalloc
354         https://bugs.webkit.org/show_bug.cgi?id=175082
355
356         Reviewed by Michael Saboff.
357         
358         This adds Gigacage::shouldBeEnabled(), which returns false when we're using gmalloc or other things
359         that enable DebugHeap.
360
361         * bmalloc/Environment.cpp:
362         (bmalloc::Environment::Environment):
363         * bmalloc/Environment.h:
364         * bmalloc/Gigacage.cpp:
365         (Gigacage::ensureGigacage):
366         (Gigacage::shouldBeEnabled):
367         * bmalloc/Gigacage.h:
368         * bmalloc/Heap.cpp:
369         (bmalloc::Heap::Heap):
370         * bmalloc/Heap.h:
371
372 2017-08-01  Filip Pizlo  <fpizlo@apple.com>
373
374         Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
375         https://bugs.webkit.org/show_bug.cgi?id=174727
376
377         Reviewed by Mark Lam.
378         
379         This adds a mechanism for managing multiple isolated heaps in bmalloc. For now, these isoheaps
380         (isolated heaps) have a very simple relationship with each other and with the rest of bmalloc:
381         
382         - You have to choose how many isoheaps you will have statically. See numHeaps in HeapKind.h.
383         
384         - Because numHeaps is static, each isoheap gets fast thread-local allocation. Basically, we have a
385           Cache for each heap kind.
386         
387         - Each isoheap gets its own Heap.
388         
389         - Each Heap gets a scavenger thread.
390         
391         - Some things, like Zone/VMHeap/Scavenger, are per-process.
392         
393         Most of the per-HeapKind functionality is handled by PerHeapKind<>.
394         
395         This approach is ideal for supporting special per-HeapKind behaviors. For now we have two heaps:
396         the Primary heap for normal malloc and the Gigacage. The gigacage is a 64GB-aligned 64GB virtual
397         region that we now use for variable-length random-access allocations. No Primary allocations will
398         go into the Gigacage.
399
400         * CMakeLists.txt:
401         * bmalloc.xcodeproj/project.pbxproj:
402         * bmalloc/AllocationKind.h: Added.
403         * bmalloc/Allocator.cpp:
404         (bmalloc::Allocator::Allocator):
405         (bmalloc::Allocator::tryAllocate):
406         (bmalloc::Allocator::allocateImpl):
407         (bmalloc::Allocator::reallocate):
408         (bmalloc::Allocator::refillAllocatorSlowCase):
409         (bmalloc::Allocator::allocateLarge):
410         * bmalloc/Allocator.h:
411         * bmalloc/BExport.h: Added.
412         * bmalloc/Cache.cpp:
413         (bmalloc::Cache::scavenge):
414         (bmalloc::Cache::Cache):
415         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
416         (bmalloc::Cache::allocateSlowCaseNullCache):
417         (bmalloc::Cache::deallocateSlowCaseNullCache):
418         (bmalloc::Cache::reallocateSlowCaseNullCache):
419         (bmalloc::Cache::operator new): Deleted.
420         (bmalloc::Cache::operator delete): Deleted.
421         * bmalloc/Cache.h:
422         (bmalloc::Cache::tryAllocate):
423         (bmalloc::Cache::allocate):
424         (bmalloc::Cache::deallocate):
425         (bmalloc::Cache::reallocate):
426         * bmalloc/Deallocator.cpp:
427         (bmalloc::Deallocator::Deallocator):
428         (bmalloc::Deallocator::scavenge):
429         (bmalloc::Deallocator::processObjectLog):
430         (bmalloc::Deallocator::deallocateSlowCase):
431         * bmalloc/Deallocator.h:
432         * bmalloc/Gigacage.cpp: Added.
433         (Gigacage::Callback::Callback):
434         (Gigacage::Callback::function):
435         (Gigacage::Callbacks::Callbacks):
436         (Gigacage::ensureGigacage):
437         (Gigacage::disableGigacage):
438         (Gigacage::addDisableCallback):
439         (Gigacage::removeDisableCallback):
440         * bmalloc/Gigacage.h: Added.
441         (Gigacage::caged):
442         (Gigacage::isCaged):
443         * bmalloc/Heap.cpp:
444         (bmalloc::Heap::Heap):
445         (bmalloc::Heap::usingGigacage):
446         (bmalloc::Heap::concurrentScavenge):
447         (bmalloc::Heap::splitAndAllocate):
448         (bmalloc::Heap::tryAllocateLarge):
449         (bmalloc::Heap::allocateLarge):
450         (bmalloc::Heap::shrinkLarge):
451         (bmalloc::Heap::deallocateLarge):
452         * bmalloc/Heap.h:
453         (bmalloc::Heap::mutex):
454         (bmalloc::Heap::kind const):
455         (bmalloc::Heap::setScavengerThreadQOSClass): Deleted.
456         * bmalloc/HeapKind.h: Added.
457         * bmalloc/ObjectType.cpp:
458         (bmalloc::objectType):
459         * bmalloc/ObjectType.h:
460         * bmalloc/PerHeapKind.h: Added.
461         (bmalloc::PerHeapKindBase::PerHeapKindBase):
462         (bmalloc::PerHeapKindBase::size):
463         (bmalloc::PerHeapKindBase::at):
464         (bmalloc::PerHeapKindBase::at const):
465         (bmalloc::PerHeapKindBase::operator[]):
466         (bmalloc::PerHeapKindBase::operator[] const):
467         (bmalloc::StaticPerHeapKind::StaticPerHeapKind):
468         (bmalloc::PerHeapKind::PerHeapKind):
469         (bmalloc::PerHeapKind::~PerHeapKind):
470         * bmalloc/PerThread.h:
471         (bmalloc::PerThread<T>::destructor):
472         (bmalloc::PerThread<T>::getSlowCase):
473         (bmalloc::PerThreadStorage<Cache>::get): Deleted.
474         (bmalloc::PerThreadStorage<Cache>::init): Deleted.
475         * bmalloc/Scavenger.cpp: Added.
476         (bmalloc::Scavenger::Scavenger):
477         (bmalloc::Scavenger::scavenge):
478         * bmalloc/Scavenger.h: Added.
479         (bmalloc::Scavenger::setScavengerThreadQOSClass):
480         (bmalloc::Scavenger::requestedScavengerThreadQOSClass const):
481         * bmalloc/VMHeap.cpp:
482         (bmalloc::VMHeap::VMHeap):
483         (bmalloc::VMHeap::tryAllocateLargeChunk):
484         * bmalloc/VMHeap.h:
485         * bmalloc/Zone.cpp:
486         (bmalloc::Zone::Zone):
487         * bmalloc/Zone.h:
488         * bmalloc/bmalloc.h:
489         (bmalloc::api::tryMalloc):
490         (bmalloc::api::malloc):
491         (bmalloc::api::tryMemalign):
492         (bmalloc::api::memalign):
493         (bmalloc::api::realloc):
494         (bmalloc::api::tryLargeMemalignVirtual):
495         (bmalloc::api::free):
496         (bmalloc::api::freeLargeVirtual):
497         (bmalloc::api::scavengeThisThread):
498         (bmalloc::api::scavenge):
499         (bmalloc::api::isEnabled):
500         (bmalloc::api::setScavengerThreadQOSClass):
501         * bmalloc/mbmalloc.cpp:
502
503 2017-08-01  Daewoong Jang  <daewoong.jang@navercorp.com>
504
505         Implement __builtin_clzl for MSVC
506         https://bugs.webkit.org/show_bug.cgi?id=174232
507
508         Reviewed by Geoffrey Garen.
509
510         * bmalloc/Algorithm.h:
511         (bmalloc::clzl):
512         (bmalloc::clzl<1>):
513         (bmalloc::__builtin_clzl):
514         * bmalloc/BPlatform.h:
515
516 2017-07-31  Mark Lam  <mark.lam@apple.com>
517
518         Fixed some comment typos.
519
520         Not reviewed.
521
522         * bmalloc/PerProcess.h:
523
524 2017-07-14  Filip Pizlo  <fpizlo@apple.com>
525
526         It should be easy to decide how WebKit yields
527         https://bugs.webkit.org/show_bug.cgi?id=174298
528
529         Reviewed by Saam Barati.
530         
531         Use sched_yield() explicitly.
532
533         * bmalloc/StaticMutex.cpp:
534         (bmalloc::StaticMutex::lockSlowCase):
535
536 2017-07-20  Chris Dumez  <cdumez@apple.com>
537
538         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
539         https://bugs.webkit.org/show_bug.cgi?id=174660
540
541         Reviewed by Geoffrey Garen.
542
543         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
544         This essentially replaces a branch to figure out if the new size is less or greater than the
545         current size by an assertion.
546
547         * bmalloc/Map.h:
548         (bmalloc::Hash>::rehash):
549
550 2017-07-18  Andy Estes  <aestes@apple.com>
551
552         [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
553         https://bugs.webkit.org/show_bug.cgi?id=174631
554
555         Reviewed by Tim Horton.
556
557         * Configurations/Base.xcconfig:
558
559 2017-07-18  Andy Estes  <aestes@apple.com>
560
561         [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
562         https://bugs.webkit.org/show_bug.cgi?id=174631
563
564         Reviewed by Sam Weinig.
565
566         * Configurations/Base.xcconfig:
567
568 2017-07-18  Andy Estes  <aestes@apple.com>
569
570         [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
571         https://bugs.webkit.org/show_bug.cgi?id=174631
572
573         Reviewed by Dan Bernstein.
574
575         * Configurations/Base.xcconfig:
576
577 2017-07-18  Andy Estes  <aestes@apple.com>
578
579         [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
580         https://bugs.webkit.org/show_bug.cgi?id=174631
581
582         Reviewed by Darin Adler.
583
584         * Configurations/Base.xcconfig:
585
586 2017-07-12  Adrian Perez de Castro  <aperez@igalia.com>
587
588         bmalloc: Failure to build when the compiler specifically targets ARMv8-A / defines __ARM_ARCH_8A__
589         https://bugs.webkit.org/show_bug.cgi?id=174424
590
591         Reviewed by Michael Catanzaro.
592
593         * bmalloc/BPlatform.h: Also check for __ARCH_ARM_8A__ to detect ARMv8.
594
595 2017-07-05  Daewoong Jang  <daewoong.jang@navercorp.com>
596
597         reinterpret_cast does not evaluate to constexpr
598         https://bugs.webkit.org/show_bug.cgi?id=173622
599
600         Reviewed by Yusuke Suzuki.
601
602         * bmalloc/Algorithm.h:
603         (bmalloc::mask):
604         (bmalloc::roundUpToMultipleOf):
605
606 2017-07-03  Andy Estes  <aestes@apple.com>
607
608         [Xcode] Add an experimental setting to build with ccache
609         https://bugs.webkit.org/show_bug.cgi?id=173875
610
611         Reviewed by Tim Horton.
612
613         * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.
614
615 2017-07-01  Dan Bernstein  <mitz@apple.com>
616
617         [iOS] Remove code only needed when building for iOS 9.x
618         https://bugs.webkit.org/show_bug.cgi?id=174068
619
620         Reviewed by Tim Horton.
621
622         * bmalloc/BPlatform.h:
623         * bmalloc/VMAllocate.h:
624         (bmalloc::vmPageSizePhysical):
625
626 2017-07-01  Dan Bernstein  <mitz@apple.com>
627
628         [macOS] Remove code only needed when building for OS X Yosemite
629         https://bugs.webkit.org/show_bug.cgi?id=174067
630
631         Reviewed by Tim Horton.
632
633         * Configurations/Base.xcconfig:
634         * Configurations/DebugRelease.xcconfig:
635
636 2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>
637
638         Ran sort-Xcode-project-file.
639
640         * bmalloc.xcodeproj/project.pbxproj:
641
642 2017-06-19  Geoffrey Garen  <ggaren@apple.com>
643
644         bmalloc: Add a per-thread line cache
645         https://bugs.webkit.org/show_bug.cgi?id=173552
646
647         Reviewed by Darin Adler.
648
649         Previously, any thread could allocate out of any page with free lines.
650         Now, the first thread to free a line in a page owns that page's free
651         lines until the whole page becomes free.
652
653         This patch is a big speedup on multi-threaded benchmarks.
654         tree_churn --parallel gets 14% faster on a 2-core (4-hyper-core) MacBook
655         Air and 2.85X faster on 12-core (24-hyper-core) Mac Pro. Other parallel
656         benchmarks show significant but smaller speedups.
657
658         Thread affinity is a great predictor of object lifetime. The per-thread
659         line cache avoids the pathology of shuffling pages between threads,
660         turning predictable lifetimes into unpredictable lifetimes, increasing
661         fragmentation. On tree_churn --parallel, the per-thread line cache
662         increases free memory found per page scanned by 2.85X.
663
664         Free line scanning in fragmented pages is pretty expensive relative to
665         other allocate / initialize / free operations. According to Instruments,
666         on tree_churn --parallel, scanning is about 10X more expensive than
667         freeing. This explains why a 2.85X improvement in scanning efficiency
668         translates into a 2.85X overall speedup on tree_churn --parallel.
669
670         * bmalloc/Allocator.cpp:
671         (bmalloc::Allocator::refillAllocatorSlowCase): Pass through our line
672         cache so the Heap can fill it.
673
674         * bmalloc/Deallocator.cpp:
675         (bmalloc::Deallocator::scavenge): Scavenge our line cache.
676
677         (bmalloc::Deallocator::processObjectLog): Deleted.
678
679         * bmalloc/Deallocator.h:
680         (bmalloc::Deallocator::lineCache): Added a line cache.
681
682         * bmalloc/Heap.cpp:
683         (bmalloc::Heap::deallocateLineCache): Deallocation function for thread
684         destruction.
685
686         (bmalloc::Heap::allocateSmallPage):
687         (bmalloc::Heap::deallocateSmallLine):
688         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
689         (bmalloc::Heap::allocateSmallBumpRangesByObject): Consult the new per-thread line
690         cache for allocation and deallocation.
691
692         * bmalloc/Heap.h:
693         (bmalloc::Heap::allocateSmallBumpRanges):
694         (bmalloc::Heap::derefSmallLine):
695
696         * bmalloc/List.h:
697         (bmalloc::List::remove): Remove has always been a logically static
698         operation. Declare it static now so that the Heap can remove a page from
699         a thread's line cache without holding a direct pointer to the cache.
700
701         * bmalloc/SmallPage.h:
702
703 2017-06-10  Dan Bernstein  <mitz@apple.com>
704
705         Reverted r218056 because it made the IDE reindex constantly.
706
707         * Configurations/DebugRelease.xcconfig:
708
709 2017-06-10  Dan Bernstein  <mitz@apple.com>
710
711         [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
712         https://bugs.webkit.org/show_bug.cgi?id=173223
713
714         Reviewed by Sam Weinig.
715
716         The rebuilds were happening due to a difference in the compiler options that the IDE and
717         xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
718         xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
719         specify an appropriate path in CLANG_INDEX_STORE_PATH.
720
721         * Configurations/DebugRelease.xcconfig:
722
723 2017-06-07  Geoffrey Garen  <ggaren@apple.com>
724
725         bmalloc: memory APIs don't need to be heap members
726         https://bugs.webkit.org/show_bug.cgi?id=173076
727
728         Reviewed by Sam Weinig.
729
730         Asking the OS about memory use is unrelated to the state of bmalloc's
731         heap, so it's a better separation of concerns if related code is not 
732         part of the heap.
733
734         * bmalloc/AvailableMemory.cpp:
735         (bmalloc::memoryStatus):
736         * bmalloc/AvailableMemory.h:
737         (bmalloc::MemoryStatus::MemoryStatus):
738         (bmalloc::isUnderMemoryPressure):
739         (bmalloc::memoryFootprint):
740         (bmalloc::percentAvailableMemoryInUse):
741         * bmalloc/Heap.cpp:
742         (bmalloc::Heap::Heap):
743         (bmalloc::Heap::updateMemoryInUseParameters): Deleted.
744         * bmalloc/Heap.h:
745         (bmalloc::Heap::isUnderMemoryPressure): Deleted.
746         (bmalloc::Heap::memoryFootprint): Deleted.
747         (bmalloc::Heap::percentAvailableMemoryInUse): Deleted.
748
749 2017-06-06  Yusuke Suzuki  <utatane.tea@gmail.com>
750
751         struct does not accept initializer-form if member has initializers in GCC 4.9
752         https://bugs.webkit.org/show_bug.cgi?id=172974
753
754         Reviewed by Carlos Garcia Campos.
755
756         struct cannot accept initializer-form constructor (like, `ListNode<T> t { ... }`) if
757         the member of the struct has a default initializer.
758         Here is a simple snippet.
759
760         template<typename T>
761         struct Pair {
762             T* prev { nullptr };
763             T* next { nullptr };
764         };
765
766         Pair<int> pair { nullptr, nullptr };  // compile erorr in GCC 4.9.
767
768         Instead, we define a default constructor (to invoke default initializers) and a constructor
769         to accept the above initialization.
770
771         * bmalloc/List.h:
772         (bmalloc::ListNode::ListNode):
773         (bmalloc::List::iterator::iterator):
774
775 2017-06-06  Geoffrey Garen  <ggaren@apple.com>
776
777         Try to fix the GTK build.
778
779         Unreviewed.
780
781         * bmalloc/List.h:
782         (bmalloc::List::List):
783
784 2017-06-05  Geoffrey Garen  <ggaren@apple.com>
785
786         Try to fix the GTK build.
787
788         Unreviewed.
789
790         * bmalloc/List.h:
791
792 2017-06-02  Geoffrey Garen  <ggaren@apple.com>
793
794         bmalloc: Small and large objects should share memory
795         https://bugs.webkit.org/show_bug.cgi?id=172880
796         <rdar://problem/31494732>
797
798         Reviewed by Sam Weinig.
799
800         This reduces our high water mark memory usage on JetStream on macOS
801         by 10%-20%. It also has the nice side effect that we can free small
802         object metadata after returning from a high water mark.
803
804         No change in throughput.
805
806         Our old algorithm allocated small object chunks and large objects in
807         segregated virtual memory and never recycled addresses between them.
808         This provided a slight security benefit because we could apply guard
809         pages between the segregated ranges and we would never reuse the same
810         virtual address for object and metadata memory.
811
812         Our new algorithm allocates small object chunks from the large object
813         allocator. This naturally recycles memory between small chunks and large
814         objects, and between small chunks of different page classes. This allows
815         us to shift memory between allocation types as a program moves between
816         different phases of allocation, and to delete small object chunk metadata
817         when a program shrinks back from a high water mark.
818
819         Two intuitions I had about memory use turned out to be backwards in
820         this context:
821
822         (1) I thought that this optimization would work because it allowed you to
823         allocate and free a 4MB object and then reuse that large allocation to
824         service small allocations. In practice, the common benefit seems to be
825         the opposite: After you allocate and free many small objects, you can
826         stitch them together to allocate a large object without growing the heap.
827
828         (2) I thought that it would be more memory-efficient to allocate
829         fine-grained pages from the large object allocator. In practice, giving
830         the large object allocator too many arbitrarily-sized ranges to manage
831         leads to fragmentation. Meanwhile, segregated fit is a powerful memory
832         optimization. So, it's best to return small object memory to the large
833         allocator only when a whole small object chunk is free.
834
835         * bmalloc/Chunk.h:
836         (bmalloc::Chunk::ref):
837         (bmalloc::Chunk::deref):
838         (bmalloc::Chunk::refCount):
839         (bmalloc::Chunk::freePages): We keep a free list per chunk and refcount
840         each chunk so we can notice when a chunk becomes empty, and return it
841         to the large allocator.
842
843         (bmalloc::forEachPage): A new helper function for iterating the pages
844         in a Chunk.
845
846         (bmalloc::Chunk::Chunk): Use forEachPage instead of manual iteration.
847         Use { } initialization because we don't get zero-initialized by the OS
848         anymore.
849
850         * bmalloc/Heap.cpp:
851         (bmalloc::Heap::Heap):
852         (bmalloc::Heap::concurrentScavenge):
853         (bmalloc::Heap::scavenge): Don't bother unlocking while scavenging. I
854         wasn't able to show it to be a consistent speedup. A more promising
855         approach, if we find a motivating example, is for the scavenger to give
856         up and return early if any other client is waiting on the lock.
857
858         (bmalloc::Heap::allocateSmallChunk): New helper function for allocating
859         a small chunk. It allocates through the large allocator to facilitate
860         sharing. We still allocate a chunk at a time instead of a page at a time.
861         Surprisingly, more precise page-at-a-time allocation is worse for memory
862         use because of fragmentation. Segregated fit is a powerful optimization.
863
864         (bmalloc::Heap::deallocateSmallChunk): New helper function for deallocating
865         a small chunk.
866
867         (bmalloc::Heap::allocateSmallPage): Updated for new APIs.
868
869         (bmalloc::Heap::deallocateSmallLine):  Updated for new APIs. Note that
870         we cache one free chunk per page class. This avoids churn in the large
871         allocator when you free(malloc(X)).
872
873         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
874         (bmalloc::Heap::allocateSmallBumpRangesByObject):
875         (bmalloc::Heap::tryAllocateLarge):
876         (bmalloc::Heap::scavengeSmallPages): Deleted.
877         (bmalloc::Heap::scavengeLargeObjects): Deleted.
878         * bmalloc/Heap.h:
879
880         * bmalloc/LargeMap.h:
881         (bmalloc::LargeMap::begin):
882         (bmalloc::LargeMap::end): Added iteration helpers for scavenging.
883
884         * bmalloc/LargeRange.h:
885         (bmalloc::LargeRange::physicalSize): Added a comment about something
886         that I confused myself about in this patch.
887
888         * bmalloc/List.h:
889         (bmalloc::List::iterator::operator*):
890         (bmalloc::List::iterator::operator->):
891         (bmalloc::List::iterator::operator!=):
892         (bmalloc::List::iterator::operator++):
893         (bmalloc::List::begin):
894         (bmalloc::List::end):
895         (bmalloc::List::pushFront):
896         (bmalloc::List::remove):
897         (bmalloc::ListNode::ListNode): Deleted. Added iteration helpers for
898         scavenging. Changed the default state of a Node to null pointers instead
899         of self pointers to distinguish the null node from the empty node for
900         easier debugging.
901
902         * bmalloc/Sizes.h: Changed the chunk size to 1MB to increase the chances
903         of a chunk becoming free and recyclable.
904
905         * bmalloc/SmallPage.h:
906         (bmalloc::SmallPage::hasPhysicalPages):
907         (bmalloc::SmallPage::setHasPhysicalPages): Track physical state by page
908         instead of implicitly by which list a page is in. It's simpler not
909         to have to move chunks and pages between physical vs virtual lists.
910
911         (bmalloc::SmallPage::SmallPage): Deleted.
912
913         * bmalloc/VMHeap.cpp:
914         (bmalloc::VMHeap::tryAllocateLargeChunk):
915         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
916         * bmalloc/VMHeap.h:
917         (bmalloc::VMHeap::allocateSmallPage): Deleted.
918         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Small chunk allocation
919         just forwards to the large allocator now.
920
921         * bmalloc/bmalloc.h:
922         (bmalloc::api::scavenge):
923
924 2017-05-28  Dan Bernstein  <mitz@apple.com>
925
926         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
927         https://bugs.webkit.org/show_bug.cgi?id=172691
928
929         Reviewed by Tim Horton.
930
931         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
932
933 2017-05-25  Geoffrey Garen  <ggaren@apple.com> and Michael Saboff  <msaboff@apple.com>
934
935         bmalloc: scavenger runs too much on JetStream
936         https://bugs.webkit.org/show_bug.cgi?id=172373
937
938         Reviewed by Geoffrey Garen.
939
940         Instruments says that JetStream on macOS spends about 3% of its time in
941         madvise.
942
943         In <https://bugs.webkit.org/show_bug.cgi?id=160098>, Ben saw some
944         evidence that madvise was the reason that switching to bmalloc for
945         DFG::Node allocations was a slowdown the first time around.
946
947         In <https://bugs.webkit.org/show_bug.cgi?id=172124>, Michael saw that
948         scavening policy can affect JetStream.
949
950         Intuitively, it seems wrong for the heap to idle shrink during hardcore
951         benchmarking.
952
953         The strategy here is to back off in response to any heap growth event,
954         and to wait 2s instead of 0.5s for heap growth to take place -- but we
955         scavenge immediately in response to critical memory pressure, to avoid
956         jetsam.
957
958         One hole in this strategy is that a workload with a perfectly
959         unfragmented heap that allocates and deallocates ~16kB every 2s will
960         never shrink its heap. This doesn't seem to be a problem in practice.
961
962         This looks like a 2% - 4% speedup on JetStream on Mac Pro and MacBook Air.
963
964         * bmalloc/AsyncTask.h:
965         (bmalloc::AsyncTask::willRun):
966         (bmalloc::AsyncTask::willRunSoon):
967         (bmalloc::Function>::AsyncTask):
968         (bmalloc::Function>::run):
969         (bmalloc::Function>::runSoon):
970         (bmalloc::Function>::threadRunLoop):
971         (bmalloc::Function>::runSlowCase): Deleted. Added a "run soon" state
972         so that execution delay is modeled directly instead of implicitly
973         through sleep events. This enables the Heap to issue a "run now" event
974         at any moment in response ot memory pressure.
975
976         * bmalloc/Heap.cpp:
977         (bmalloc::Heap::Heap): Don't call into our own API -- that's a layering
978         violation.
979
980         (bmalloc::Heap::updateMemoryInUseParameters): No need for
981         m_scavengeSleepDuration anymore.
982
983         (bmalloc::Heap::concurrentScavenge): Added a back-off policy when the
984         heap is growing.
985         (bmalloc::Heap::scavenge):
986
987         (bmalloc::Heap::scavengeSmallPages):
988         (bmalloc::Heap::scavengeLargeObjects): Don't try to give up in the middle
989         of a scavenge event. Our new backoff policy supplants that design. Also,
990         it's easier to profile and understand scavenging behavior if it always
991         runs to completion once started.
992
993         (bmalloc::Heap::scheduleScavenger):
994         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Added a
995         synchronous amortized check for memory pressure. This check has the
996         benefit that it runs immediately during high rates of heap activity,
997         so we can detect memory pressure right away and wake the scavenger
998         instead of waiting for the scavenger to wake up.
999
1000         (bmalloc::Heap::allocateSmallPage):
1001         (bmalloc::Heap::deallocateSmallLine):
1002         (bmalloc::Heap::splitAndAllocate):
1003         (bmalloc::Heap::tryAllocateLarge):
1004         (bmalloc::Heap::shrinkLarge):
1005         (bmalloc::Heap::deallocateLarge):
1006         * bmalloc/Heap.h:
1007         (bmalloc::Heap::isUnderMemoryPressure):
1008         * bmalloc/Sizes.h:
1009         * bmalloc/VMHeap.h:
1010         (bmalloc::VMHeap::deallocateSmallPage):
1011         * bmalloc/bmalloc.h:
1012         (bmalloc::api::scavenge): Updated for API changes above.
1013
1014 2017-05-17  Michael Saboff  <msaboff@apple.com>
1015
1016         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info (172186)
1017         https://bugs.webkit.org/show_bug.cgi?id=172186
1018
1019         Reviewed by Geoffrey Garen.
1020
1021         The calls memoryFootprint() and percentAvailableMemoryInUse() now make a system call to get
1022         the current memory footprint value.
1023
1024         * bmalloc/Heap.h:
1025         (bmalloc::Heap::memoryFootprint):
1026         (bmalloc::Heap::percentAvailableMemoryInUse):
1027
1028 2017-05-16  Michael Saboff  <msaboff@apple.com>
1029
1030         REGRESSION(r216763): JetStream is 1% slower on Mac
1031         https://bugs.webkit.org/show_bug.cgi?id=172124
1032
1033         Reviewed by Filip Pizlo.
1034
1035         It appears that changing maxScavengeSleepDuration from 512 to 250ms in r216763 is
1036         responsible for the regression.
1037
1038         * bmalloc/Sizes.h:
1039
1040 2017-05-15  Geoffrey Garen  <ggaren@apple.com>
1041
1042         bmalloc: Bump the size of the deallocator log to 512
1043         https://bugs.webkit.org/show_bug.cgi?id=172143
1044
1045         Reviewed by Michael Saboff.
1046
1047         This is a speedup on parallel workloads for machines with lots of CPUs.
1048
1049         * bmalloc/Sizes.h:
1050
1051 2017-05-12  Michael Saboff  <msaboff@apple.com>
1052
1053         [iOS] Use memory footprint to dynamically adjust behavior of allocators
1054         https://bugs.webkit.org/show_bug.cgi?id=171944
1055
1056         Reviewed by Filip Pizlo.
1057
1058         This change is iOS only.
1059
1060         After the scavenger thread completes scavenging, it asks the OS for how much total memory the
1061         process is using.  This information is used to update the sleep delay for the scanvenger thread,
1062         as well as to provide memory in use data for other parts of the system.
1063
1064         The scavenger sleep time is calculated using the following quadradic equation.
1065
1066             scavengerSleep = 1.2*percentFreeMemory^2 - percentFreeMemory + 2
1067
1068         Where percentFreeMemory is between 0 and 100.  The result is constrained to the values 2 and 250.
1069
1070         This equation empirically works out to providing a 2ms sleep time when we have less than 10%
1071         memory available, 30ms when 20% is available and 250ms when 50% or more is available.  In testing,
1072         this exponentially agressive scavenging delay by itself reduced memory usage and made it much
1073         more deterministic when used without the corresponding change in the JSC Heap.
1074
1075         Changed the scavenger thread to use the User Initiated QOS priority to ensure it doesn't
1076         get starved.
1077
1078         Moved the non-Windows functionality of WTF::RAMSize() to new files AvailableMemory.{cpp,h}
1079         and implemented in the function availableMemory().  That functions limits the value returned
1080         on iOS to a maximum of 840MB as that is the jetsam soft memory limit.
1081         Added a new API availableMemory() so that WTF::RAMSize() will use this value.
1082
1083         * CMakeLists.txt:
1084         * bmalloc.xcodeproj/project.pbxproj:
1085         * bmalloc/BPlatform.h:
1086         * bmalloc/Heap.cpp:
1087         (bmalloc::Heap::Heap):
1088         (bmalloc::Heap::updateMemoryInUseParameters):
1089         (bmalloc::Heap::concurrentScavenge):
1090         (bmalloc::Heap::scavenge):
1091         * bmalloc/Heap.h:
1092         (bmalloc::Heap::memoryFootprint):
1093         (bmalloc::Heap::percentAvailableMemoryInUse):
1094         * bmalloc/Sizes.h:
1095         * bmalloc/bmalloc.h:
1096         (bmalloc::api::availableMemory):
1097         (bmalloc::api::memoryFootprint):
1098         (bmalloc::api::percentAvailableMemoryInUse):
1099         * bmalloc/AvailableMemory.cpp: Added.
1100         (bmalloc::computeAvailableMemory):
1101         (bmalloc::availableMemory):
1102         * bmalloc/AvailableMemory.h: Added.
1103
1104 2017-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1105
1106         Leaks always reports "WebKit Malloc Memory Pressure Handler" dispatch_queue/source as leaking
1107         https://bugs.webkit.org/show_bug.cgi?id=171532
1108
1109         Reviewed by Geoffrey Garen.
1110
1111         * bmalloc/Heap.cpp:
1112         (bmalloc::Heap::Heap):
1113         * bmalloc/Heap.h:
1114         Store the dispatch_source_t in a member to avoid a false positive leak.
1115
1116 2017-04-27  Michael Saboff  <msaboff@apple.com>
1117
1118         bmalloc scavenger should know what page classes are allocating
1119         https://bugs.webkit.org/show_bug.cgi?id=171384
1120
1121         Reviewed by Geoffrey Garen.
1122
1123         This change replaces m_isAllocatingPages with a per page class flag to track which page
1124         classes are currently allocating.  When scavenging, we skip page classes that are actively
1125         allocating and come back to them on a subsequent pass.  This reduces the amount of time it
1126         takes for scavenger to free up pages as well as the total time it takes to handle all
1127         page classes.
1128
1129         * bmalloc/Heap.cpp:
1130         (bmalloc::Heap::Heap):
1131         (bmalloc::Heap::concurrentScavenge):
1132         (bmalloc::Heap::scavenge):
1133         (bmalloc::Heap::scavengeSmallPages):
1134         (bmalloc::Heap::scavengeLargeObjects):
1135         (bmalloc::Heap::allocateSmallPage):
1136         (bmalloc::Heap::splitAndAllocate):
1137         (bmalloc::Heap::deallocateLarge):
1138         * bmalloc/Heap.h:
1139         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass): Deleted.
1140         * bmalloc/VMHeap.h:
1141         (bmalloc::VMHeap::deallocateSmallPage):
1142         * bmalloc/bmalloc.h:
1143         (bmalloc::api::scavenge):
1144
1145 2017-04-25  Michael Saboff  <msaboff@apple.com>
1146
1147         Call bmalloc scavenger first when handling a memory pressure event
1148         https://bugs.webkit.org/show_bug.cgi?id=171289
1149
1150         Reviewed by Geoffrey Garen.
1151
1152         Registered a critical memory pressure handler.  We add this handler in addition to the
1153         call to release bmalloc memory in the WebCore releaseMemory handler for the case of
1154         JSC API users that don't use WebCore.  When both handlers are in the process, it is
1155         basically a race.  One will win, but the loser won't do any more work, so it is harmless.
1156
1157         * bmalloc/Heap.cpp:
1158         (bmalloc::Heap::Heap):
1159
1160 2017-04-14  Mark Lam  <mark.lam@apple.com>
1161
1162         Update architectures in xcconfig files.
1163         https://bugs.webkit.org/show_bug.cgi?id=170867
1164         <rdar://problem/31628104>
1165
1166         Reviewed by Joseph Pecoraro.
1167
1168         * Configurations/Base.xcconfig:
1169
1170 2017-04-12  Dan Bernstein  <mitz@apple.com>
1171
1172         [Mac] Future-proof .xcconfig files
1173         https://bugs.webkit.org/show_bug.cgi?id=170802
1174
1175         Reviewed by Tim Horton.
1176
1177         * Configurations/Base.xcconfig:
1178         * Configurations/DebugRelease.xcconfig:
1179
1180 2017-02-03  Ting-Wei Lan  <lantw44@gmail.com>
1181
1182         Include cstdlib before using ::malloc and posix_memalign
1183         https://bugs.webkit.org/show_bug.cgi?id=167800
1184
1185         Reviewed by Geoffrey Garen.
1186
1187         * bmalloc/DebugHeap.cpp:
1188
1189 2017-02-01  Andreas Kling  <akling@apple.com>
1190
1191         Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
1192         <https://webkit.org/b/167387>
1193         <rdar://problem/29711409>
1194
1195         Reviewed by Antti Koivisto.
1196
1197         Support changing the QoS level of the scavenger thread asynchronously through
1198         a request variable. This is not the most elegant thing in the world, but since
1199         threads are only allowed to change their own QoS class, our options are limited.
1200
1201         * bmalloc/Heap.cpp:
1202         (bmalloc::Heap::concurrentScavenge):
1203         * bmalloc/Heap.h:
1204         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
1205         (bmalloc::Heap::setScavengerThreadQOSClass):
1206         * bmalloc/bmalloc.h:
1207         (bmalloc::api::setScavengerThreadQOSClass):
1208
1209 2017-01-13  Geoffrey Garen  <ggaren@apple.com>
1210
1211         bmalloc: Use a separate zone when using system malloc
1212         https://bugs.webkit.org/show_bug.cgi?id=167014
1213
1214         Reviewed by Filip Pizlo.
1215
1216         Harris asked for this so he could separate Safari and WebKit memory use
1217         when doing memory analysis.
1218
1219         This patch adds an explicit DebugHeap class that contains all our
1220         code for specialized allocation with debugging.
1221
1222         * bmalloc.xcodeproj/project.pbxproj:
1223
1224         * bmalloc/Allocator.cpp:
1225         (bmalloc::Allocator::Allocator):
1226         (bmalloc::Allocator::tryAllocate):
1227         (bmalloc::Allocator::allocateImpl):
1228         (bmalloc::Allocator::reallocate):
1229         (bmalloc::Allocator::allocateSlowCase):
1230         * bmalloc/Allocator.h: Forward to DebugHeap instead of inlining all the
1231         code. This is required for our new interface, and it is also a nice
1232         simplification that moves some not-very-important code out of the way.
1233
1234         * bmalloc/Deallocator.cpp:
1235         (bmalloc::Deallocator::Deallocator):
1236         (bmalloc::Deallocator::scavenge):
1237         (bmalloc::Deallocator::deallocateSlowCase):
1238         * bmalloc/Deallocator.h: Ditto.
1239
1240         * bmalloc/DebugHeap.cpp: Added.
1241         (bmalloc::DebugHeap::DebugHeap):
1242         (bmalloc::DebugHeap::malloc):
1243         (bmalloc::DebugHeap::memalign):
1244         (bmalloc::DebugHeap::realloc):
1245         (bmalloc::DebugHeap::free):
1246         * bmalloc/DebugHeap.h: Added. New class for overriding normal heap
1247         behavior. Right now, it just adds a malloc zone and then forwards to
1248         system malloc -- but we can add lots more kinds of debug heaps in the
1249         future if we find them useful.
1250
1251         * bmalloc/Environment.cpp:
1252         (bmalloc::Environment::Environment):
1253         (bmalloc::Environment::computeIsDebugHeapEnabled):
1254         (bmalloc::Environment::computeIsBmallocEnabled): Deleted.
1255         * bmalloc/Environment.h:
1256         (bmalloc::Environment::isDebugHeapEnabled):
1257         (bmalloc::Environment::isBmallocEnabled): Deleted. Renamed everything to
1258         reflect our new use of DebugHeap.
1259
1260         * bmalloc/Heap.cpp:
1261         (bmalloc::Heap::Heap):
1262         * bmalloc/Heap.h:
1263         (bmalloc::Heap::debugHeap): Updated to use DebugHeap.
1264         (bmalloc::Heap::environment): Deleted. 
1265
1266         * bmalloc/bmalloc.h:
1267         (bmalloc::api::isEnabled): Updated to use DebugHeap.
1268
1269 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
1270
1271         Sort Xcode project files
1272         https://bugs.webkit.org/show_bug.cgi?id=165937
1273
1274         Reviewed by Simon Fraser.
1275
1276         * bmalloc.xcodeproj/project.pbxproj:
1277
1278 2016-12-08  David Kilzer  <ddkilzer@apple.com>
1279
1280         Always check the return value of pthread_key_create()
1281         <https://webkit.org/b/165274>
1282
1283         Reviewed by Darin Adler.
1284
1285         * bmalloc/PerThread.h:
1286         (bmalloc::PerThreadStorage::init): Call BCRASH() if
1287         pthread_key_create() returns an error.  The error code will be
1288         stored in a register available in a crash log, so no need to log
1289         the value explicitly.
1290
1291 2016-12-06  Alexey Proskuryakov  <ap@apple.com>
1292
1293         Correct SDKROOT values in xcconfig files
1294         https://bugs.webkit.org/show_bug.cgi?id=165487
1295         rdar://problem/29539209
1296
1297         Reviewed by Dan Bernstein.
1298
1299         Fix suggested by Dan Bernstein.
1300
1301         * Configurations/DebugRelease.xcconfig:
1302
1303 2016-11-29  Andy Estes  <aestes@apple.com>
1304
1305         [Cocoa] Enable two clang warnings recommended by Xcode
1306         https://bugs.webkit.org/show_bug.cgi?id=164498
1307
1308         Reviewed by Mark Lam.
1309
1310         * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
1311
1312 2016-11-10  Geoffrey Garen  <ggaren@apple.com>
1313
1314         bmalloc threads should have a non-default QoS
1315         https://bugs.webkit.org/show_bug.cgi?id=164612
1316
1317         Reviewed by Filip Pizlo.
1318
1319         * bmalloc/AsyncTask.h:
1320         (bmalloc::Function>::threadEntryPoint): Request user-interactive quality
1321         of service because user-interactive tasks use malloc.
1322
1323 2016-10-20  Mark Lam  <mark.lam@apple.com>
1324
1325         bmalloc api should crash on failure to allocate when !isBmallocEnabled.
1326         https://bugs.webkit.org/show_bug.cgi?id=163766
1327
1328         Reviewed by Keith Miller and Filip Pizlo.
1329
1330         We want to crash in bmalloc on failure to allocate even when !isBmallocEnabled.
1331         This is so that failures to allocate memory will manifest as crashes with a
1332         unique signature (i.e. as a SIGTRAP on release builds, or as a write to illegal
1333         address 0xbbadbeef on debug builds) and the crash will manifest inside bmalloc.
1334         This distinguishes allocation failures from other crashing bugs that manifest as
1335         SIGSEGVs due to random pointer dereferences in the clients of bmalloc.
1336
1337         * bmalloc/Allocator.cpp:
1338         (bmalloc::Allocator::allocateImpl):
1339         (bmalloc::Allocator::reallocate):
1340         (bmalloc::Allocator::allocateSlowCase):
1341
1342 2016-09-26  Yoshiaki Jitsukawa  <Yoshiaki.Jitsukawa@sony.com>
1343
1344         Avoid implicit conversion from iterator to pointer
1345         https://bugs.webkit.org/show_bug.cgi?id=162482
1346
1347         Reviewed by Geoffrey Garen.
1348
1349         Not every STL supporting such conversion, we should get a pointer explicitly.
1350
1351         * bmalloc/Chunk.h:
1352         (bmalloc::Chunk::lines):
1353         (bmalloc::Chunk::pages):
1354         * bmalloc/FixedVector.h:
1355         (bmalloc::FixedVector::begin):
1356
1357 2016-08-31  Filip Pizlo  <fpizlo@apple.com>
1358
1359         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
1360         https://bugs.webkit.org/show_bug.cgi?id=160125
1361
1362         Reviewed by Geoffrey Garen and Keith Miller.
1363         
1364         I needed to tryMemalign, so I added such a thing.
1365
1366         * bmalloc/Allocator.cpp:
1367         (bmalloc::Allocator::allocate):
1368         (bmalloc::Allocator::tryAllocate):
1369         (bmalloc::Allocator::allocateImpl):
1370         * bmalloc/Allocator.h:
1371         * bmalloc/Cache.h:
1372         (bmalloc::Cache::tryAllocate):
1373         * bmalloc/bmalloc.h:
1374         (bmalloc::api::tryMemalign):
1375
1376 2016-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1377
1378         Unreviewed, build fix for GCC ports
1379
1380         std::forward is declared in <utility> header.
1381
1382         * bmalloc/ScopeExit.h:
1383
1384 2016-08-30  Geoffrey Garen  <ggaren@apple.com>
1385
1386         bmalloc: speed up the lock slow path
1387         https://bugs.webkit.org/show_bug.cgi?id=161058
1388
1389         Unreviewed roll-in - with regression fixed.
1390
1391         Revert to using yield() instead of swtch() because very low priority
1392         background tasks can cause priority inversion and deadlock. In the
1393         network process, that happened with com.apple.WebKit.Cache.Storage.serialBackground.
1394
1395         Still a big speedup on MallocBench.
1396
1397         * bmalloc.xcodeproj/project.pbxproj:
1398         * bmalloc/ScopeExit.h: Added.
1399         (bmalloc::ScopeExit::ScopeExit):
1400         (bmalloc::ScopeExit::~ScopeExit):
1401         (bmalloc::makeScopeExit):
1402         * bmalloc/StaticMutex.cpp:
1403         (bmalloc::StaticMutex::lockSlowCase):
1404         * bmalloc/StaticMutex.h:
1405         (bmalloc::StaticMutex::init):
1406
1407 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
1408
1409         Unreviewed build fix.
1410
1411         Fix the CMake build.
1412
1413         * CMakeLists.txt:
1414
1415 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
1416
1417         Renamed XLarge* => Large*
1418         https://bugs.webkit.org/show_bug.cgi?id=161261
1419
1420         Reviewed by Andreas Kling.
1421
1422         XLarge is not a thing anymore: We just have Small and Large.
1423
1424         * bmalloc.xcodeproj/project.pbxproj:
1425         * bmalloc/Heap.cpp:
1426         (bmalloc::Heap::splitAndAllocate):
1427         (bmalloc::Heap::tryAllocateLarge):
1428         (bmalloc::Heap::shrinkLarge):
1429         (bmalloc::Heap::deallocateLarge):
1430         * bmalloc/Heap.h:
1431         * bmalloc/LargeMap.cpp: Copied from Source/bmalloc/bmalloc/XLargeMap.cpp.
1432         (bmalloc::LargeMap::remove):
1433         (bmalloc::LargeMap::add):
1434         (bmalloc::XLargeMap::remove): Deleted.
1435         (bmalloc::XLargeMap::add): Deleted.
1436         * bmalloc/LargeMap.h: Copied from Source/bmalloc/bmalloc/XLargeMap.h.
1437         (bmalloc::LargeMap::ranges):
1438         (bmalloc::XLargeMap::ranges): Deleted.
1439         * bmalloc/LargeRange.h: Copied from Source/bmalloc/bmalloc/XLargeRange.h.
1440         (bmalloc::LargeRange::LargeRange):
1441         (bmalloc::LargeRange::operator<):
1442         (bmalloc::canMerge):
1443         (bmalloc::merge):
1444         (bmalloc::LargeRange::split):
1445         (bmalloc::XLargeRange::XLargeRange): Deleted.
1446         (bmalloc::XLargeRange::operator<): Deleted.
1447         (bmalloc::XLargeRange::split): Deleted.
1448         * bmalloc/VMHeap.cpp:
1449         (bmalloc::VMHeap::tryAllocateLargeChunk):
1450         * bmalloc/VMHeap.h:
1451         * bmalloc/XLargeMap.cpp: Removed.
1452         * bmalloc/XLargeMap.h: Removed.
1453         * bmalloc/XLargeRange.h: Removed.
1454
1455 2016-08-26  Gavin Barraclough  <barraclough@apple.com>
1456
1457         bmalloc: speed up the lock slow path
1458         https://bugs.webkit.org/show_bug.cgi?id=161058
1459
1460         Unreviewed rollout - this caused regressions <rdar://problem/28026089>.
1461
1462         * bmalloc.xcodeproj/project.pbxproj:
1463         * bmalloc/ScopeExit.h: Removed.
1464         * bmalloc/StaticMutex.cpp:
1465         (bmalloc::StaticMutex::lockSlowCase):
1466         * bmalloc/StaticMutex.h:
1467         (bmalloc::StaticMutex::init):
1468         * bmalloc/ThreadSwitch.h: Removed.
1469
1470 2016-08-24  Andreas Kling  <akling@apple.com>
1471
1472         Add bmalloc::api::isEnabled().
1473         <https://webkit.org/b/160534>
1474
1475         Reviewed by Joseph Pecoraro.
1476
1477         * bmalloc/bmalloc.h:
1478         (bmalloc::api::isEnabled):
1479
1480 2016-08-24  Filip Pizlo  <fpizlo@apple.com>
1481
1482         Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.
1483
1484         * bmalloc/Allocator.cpp:
1485         (bmalloc::Allocator::allocate):
1486         (bmalloc::Allocator::tryAllocate): Deleted.
1487         (bmalloc::Allocator::allocateImpl): Deleted.
1488         * bmalloc/Allocator.h:
1489         * bmalloc/Cache.h:
1490         (bmalloc::Cache::tryAllocate): Deleted.
1491         * bmalloc/bmalloc.h:
1492         (bmalloc::api::tryMemalign): Deleted.
1493
1494 2016-08-12  Filip Pizlo  <fpizlo@apple.com>
1495
1496         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
1497         https://bugs.webkit.org/show_bug.cgi?id=160125
1498
1499         Reviewed by Geoffrey Garen.
1500         
1501         I needed to tryMemalign, so I added such a thing.
1502
1503         * bmalloc/Allocator.cpp:
1504         (bmalloc::Allocator::allocate):
1505         (bmalloc::Allocator::tryAllocate):
1506         (bmalloc::Allocator::allocateImpl):
1507         (bmalloc::Allocator::reallocate):
1508         * bmalloc/Allocator.h:
1509         * bmalloc/Cache.h:
1510         (bmalloc::Cache::allocate):
1511         (bmalloc::Cache::tryAllocate):
1512         * bmalloc/bmalloc.h:
1513         (bmalloc::api::malloc):
1514         (bmalloc::api::tryMemalign):
1515         (bmalloc::api::memalign):
1516
1517 2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1518
1519         Unreviewed, build fix on GCC environment
1520         https://bugs.webkit.org/show_bug.cgi?id=161058
1521
1522         std::forward is declared in <utility> header.
1523
1524         * bmalloc/ScopeExit.h:
1525
1526 2016-08-22  Geoffrey Garen  <ggaren@apple.com>
1527
1528         bmalloc: speed up the lock slow path
1529         https://bugs.webkit.org/show_bug.cgi?id=161058
1530
1531         Reviewed by Filip Pizlo.
1532
1533         It is generally accepted practice that a lock should yield instead of
1534         spinning when a lock acquisition fails, to avoid wasting CPU and power.
1535
1536         There are two problems with this generally accepted practice:
1537
1538         (1) It's a fallacy that yielding is free. In reality, yielding itself
1539         consumes CPU and power -- by performing a syscall, running the OS
1540         scheduler, and possibly performing a context switch. (Instruments
1541         traces of MallocBench show the cost of yielding.) Therefore, spinning a
1542         little to avoid yielding can actually *save* CPU and power.
1543
1544         (2) std::this_thread_yield() on Darwin is way too aggressive: It not only
1545         yields but also depresses your priority to absolute zero for 10ms. A
1546         recent PLT trace showed a few spots where the main thread just gave up
1547         on loading and rendering a page for 10ms so an unimportant background
1548         task could run.
1549
1550         To correct these problems, this patch adds a little bit of spinning to
1551         the bmalloc lock slow path.
1552
1553         Below are performance results on various CPUs.
1554
1555         Mac Pro (12 hyperthreaded cores = 24 threads):
1556
1557                                                             Baseline                       Patch                           Δ
1558             Execution Time:
1559                 message_one                                    173ms                       173ms                            
1560                 message_many                                   953ms                       927ms              ^ 1.03x faster
1561                 churn --parallel                                60ms                        41ms              ^ 1.46x faster
1562                 list_allocate --parallel                       224ms                       143ms              ^ 1.57x faster
1563                 tree_allocate --parallel                     1,190ms                       758ms              ^ 1.57x faster
1564                 tree_churn --parallel                        1,517ms                       906ms              ^ 1.67x faster
1565                 facebook --parallel                          6,519ms                     4,580ms              ^ 1.42x faster
1566                 reddit --parallel                            5,097ms                     3,411ms              ^ 1.49x faster
1567                 flickr --parallel                            4,903ms                     3,501ms               ^ 1.4x faster
1568                 theverge --parallel                          6,641ms                     4,505ms              ^ 1.47x faster
1569
1570                 <geometric mean>                             1,158ms                       832ms              ^ 1.39x faster
1571                 <arithmetic mean>                            2,728ms                     1,895ms              ^ 1.44x faster
1572                 <harmonic mean>                                332ms                       240ms              ^ 1.38x faster
1573
1574         MacBook Air (2 hyperthreaded cores = 4 threads):
1575
1576                                                             Baseline                       Patch                           Δ
1577             Execution Time:
1578                 message_one                                    911ms                       907ms               ^ 1.0x faster
1579                 message_many                                   515ms                       513ms               ^ 1.0x faster
1580                 churn --parallel                               132ms                       134ms              ! 1.02x slower
1581                 list_allocate --parallel                       104ms                       102ms              ^ 1.02x faster
1582                 tree_allocate --parallel                       117ms                       111ms              ^ 1.05x faster
1583                 tree_churn --parallel                          154ms                       151ms              ^ 1.02x faster
1584                 facebook --parallel                            719ms                       687ms              ^ 1.05x faster
1585                 reddit --parallel                              382ms                       341ms              ^ 1.12x faster
1586                 flickr --parallel                              372ms                       345ms              ^ 1.08x faster
1587                 theverge --parallel                            489ms                       444ms               ^ 1.1x faster
1588
1589                 <geometric mean>                               299ms                       287ms              ^ 1.04x faster
1590                 <arithmetic mean>                              390ms                       374ms              ^ 1.04x faster
1591                 <harmonic mean>                                227ms                       220ms              ^ 1.03x faster
1592
1593         iPad (2 cores = 2 threads):
1594
1595             [ Doesn't run Ruby, so no pretty subtest output. ]
1596
1597                                                             Baseline                       Patch                           Δ
1598             Execution Time:                                 174.14ms                     171.5ms              ^ 1.02x faster
1599
1600         * bmalloc.xcodeproj/project.pbxproj:
1601
1602         * bmalloc/ScopeExit.h: Added. A barebones very wimpy version of
1603         WTF::ScopeExit.
1604         (bmalloc::ScopeExit::ScopeExit):
1605         (bmalloc::ScopeExit::~ScopeExit):
1606         (bmalloc::makeScopeExit):
1607
1608         * bmalloc/StaticMutex.cpp:
1609         (bmalloc::StaticMutex::lockSlowCase): Spin before yielding -- that's the
1610         speedup. Don't spin if another CPU is already spinning. In theory, more
1611         than one spinner accomplishes nothing, and I found that there's a cutoff
1612         around 8 or 16 spinners that becomes performance negative on Mac Pro.
1613
1614         (Note: Another way to accomplish a similar result, if you don't want to
1615         use a bit of state in the lock, is to spin for a random duration between
1616         0 and aLot. I tested a version of WTF::WeakRandom with unsynchronized
1617         static state and it worked great. But I ultimately opted for the explicit
1618         bit because I thought it was clearer.)
1619
1620         * bmalloc/StaticMutex.h:
1621         (bmalloc::StaticMutex::init): Initialize our new bit.
1622
1623         * bmalloc/ThreadSwitch.h: Added.
1624         (bmalloc::threadSwitch): Don't call yield() on Darwin because it's too
1625         aggressive. swtch() does what we want: Go run something else, without
1626         any other side-effects.
1627
1628 2016-08-03  Geoffrey Garen  <ggaren@apple.com>
1629
1630         [bmalloc] Merging of XLargeRanges can leak the upper range
1631         https://bugs.webkit.org/show_bug.cgi?id=160403
1632
1633         Reviewed by Michael Saboff.
1634
1635         * bmalloc/Heap.cpp:
1636         (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
1637         Recorded physical size is a performance optimization. It is not the
1638         truth. So it might be zero even if a range contains physical pages.
1639
1640         Instead, iterate each range in the map unconditionally.
1641
1642         The map can shrink when we release the lock, so we must clamp our
1643         iterator each time through the loop.
1644
1645         The map can grow when we release the lock, but we don't care because
1646         growth restarts the scavenger from the beginning.
1647
1648         * bmalloc/XLargeMap.cpp:
1649         (bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.
1650
1651         * bmalloc/XLargeMap.h:
1652         (bmalloc::XLargeMap::ranges): Added direct access for the sake of
1653         scavengeLargeObjects. (This violates our naming conventions -- I'll do
1654         a rename in a follow-up patch.)
1655
1656 2016-07-13  Enrica Casucci  <enrica@apple.com>
1657
1658         Update supported platforms in xcconfig files to match the sdk names.
1659         https://bugs.webkit.org/show_bug.cgi?id=159728
1660
1661         Reviewed by Tim Horton.
1662
1663         * Configurations/Base.xcconfig:
1664
1665 2016-07-11  Geoffrey Garen  <ggaren@apple.com>
1666
1667         Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
1668         https://bugs.webkit.org/show_bug.cgi?id=159655
1669
1670         Reviewed by Sam Weinig.
1671
1672         It's not entirely clear what was happening in these crashes, but our
1673         use of detach() was 100% forward-looking, so we can just remove it for
1674         now.
1675
1676         This patch removes the ability for the scavenger owner to die before
1677         the scavenger thread dies (which was unused) and also removes the
1678         ability for the scavenger thread to exit (which was used, but we
1679         messed up and did thread joining lazily, so we never got any benefit
1680         from thread exit.)
1681
1682         We can add these features back when we need them, and make them work then.
1683
1684         * bmalloc/AsyncTask.h:
1685         (bmalloc::Function>::AsyncTask): We start out in the running state now
1686         because we know that starting our thread will run it.
1687
1688         (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
1689
1690         (bmalloc::Function>::runSlowCase): I removed the Exited state.
1691
1692         (bmalloc::Function>::threadRunLoop): I removed the Exited and
1693         ExitRequested states.
1694
1695         * bmalloc/Heap.h:
1696
1697         * bmalloc/VMHeap.h:
1698
1699 2016-06-12  David Kilzer  <ddkilzer@apple.com>
1700
1701         Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
1702         <https://webkit.org/b/158660>
1703         <rdar://problem/25652686>
1704
1705         Reviewed by Darin Adler.
1706
1707         * bmalloc/Logging.cpp: Switch to use
1708         BSOFT_LINK_PRIVATE_FRAMEWORK() to link
1709         CrashReporterSupport.framework.
1710         * bmalloc/darwin/BSoftLinking.h:
1711         (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
1712         Switch to use /System/Library/PrivateFrameworks/.
1713
1714 2016-06-11  David Kilzer  <ddkilzer@apple.com>
1715
1716         Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
1717         <http://webkit.org/b/155992>
1718
1719         Reviewed by Geoff Garen.
1720
1721         * bmalloc/BAssert.h:
1722         (BLOG_ERROR): Add method to always log error messages.
1723         (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
1724         logging in Debug builds.
1725         * bmalloc/BPlatform.h:
1726         (BPLATFORM_MAC): Add.
1727         (BUSE): Add BUSE() macro.
1728         (BATTRIBUTE_PRINTF): Add.
1729         (BUSE_OS_LOG): Add.
1730         * bmalloc/Logging.cpp:
1731         (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
1732         stderr.
1733         * bmalloc/Logging.h:
1734         (bmalloc::reportAssertionFailureWithMessage): Add declaration.
1735
1736 2016-06-07  Pranjal Jumde  <pjumde@apple.com>
1737
1738         Prevents integer overflow in Vector.h
1739         https://bugs.webkit.org/show_bug.cgi?id=158455
1740         <rdar://problem/20235469>
1741
1742         Reviewed by Mark Lam.
1743
1744         * bmalloc/Vector.h:
1745         (bmalloc::Vector<T>::reallocateBuffer):
1746
1747 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
1748
1749         [cmake] Deduplicated bmalloc/Zone.cpp handling.
1750         https://bugs.webkit.org/show_bug.cgi?id=158154
1751
1752         Reviewed by Alex Christensen.
1753
1754         File bmalloc/Zone.cpp is required on Darwin irrespectively from what
1755         port is being built.
1756
1757         Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
1758         unlikely that bmalloc will ever need port-specific customizations (as
1759         opposed to OS-specific customizations which should be done in
1760         CMakeLists.txt).
1761
1762         * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
1763         * PlatformGTK.cmake: Removed.
1764         * PlatformMac.cmake: Removed.
1765
1766 2016-05-22  Brady Eidson  <beidson@apple.com>
1767
1768         Move to C++14.
1769         https://bugs.webkit.org/show_bug.cgi?id=157948
1770
1771         Reviewed by Michael Catanzaro.
1772
1773         * Configurations/Base.xcconfig:
1774
1775 2016-05-17  Geoffrey Garen  <ggaren@apple.com>
1776
1777         REGRESSION: JetStream crashes on some iPhones
1778         https://bugs.webkit.org/show_bug.cgi?id=157814
1779
1780         Reviewed by Michael Saboff.
1781
1782         * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
1783
1784         Previous justification for 64kB was:
1785
1786             * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
1787             reasonable, since sizes between 16kB and 32kB share page sizes. I went
1788             all the way up to 64kB because the GC uses 64kB blocks, and also just
1789             for extra padding to ensure that large allocations are indeed rare.
1790
1791         It turns out that the bump to 64kB substantially increases our memory
1792         high water mark on JetStream, leading to jetsam crashes. Also, there
1793         doesn't seem to be a practical performance problem to putting objects in
1794         the (32kB - 64kB) range in the large allocator.
1795
1796 2016-05-16  Geoffrey Garen  <ggaren@apple.com>
1797
1798         REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
1799         https://bugs.webkit.org/show_bug.cgi?id=157764
1800
1801         Reviewed by Gavin Barraclough.
1802
1803         We need to allow for guard pages and only report unguarded pages to the
1804         leaks tool -- otherwise, it will try to remote map our guarded pages,
1805         and crash.
1806
1807         * bmalloc/VMHeap.cpp:
1808         (bmalloc::VMHeap::tryAllocateLargeChunk):
1809         (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
1810         a range instead of a Chunk*, and report the unguarded range.
1811
1812         This also fixes a separate bug -- very large allocations would not
1813         fully participate in pointer scanning because they would only report 2MB
1814         (chunkSize) in size. This could cause false-positive leak reports.
1815
1816         * bmalloc/Zone.cpp:
1817         (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
1818         Chunk pointers.
1819
1820         * bmalloc/Zone.h:
1821         (bmalloc::Zone::ranges):
1822         (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
1823         pointers because our VM ranges have variable sizes -- both due to guard
1824         pages and due to large allocations.
1825
1826         (bmalloc::Zone::chunks): Deleted.
1827         (bmalloc::Zone::addChunk): Deleted.
1828
1829 2016-05-10  David Kilzer  <ddkilzer@apple.com>
1830
1831         bmalloc should automatically disable itself when ThreadSanitizer is used
1832         <https://webkit.org/b/157527>
1833
1834         Reviewed by Michael Catanzaro.
1835
1836         * bmalloc/Environment.cpp:
1837         (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
1838         (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
1839         support for detecting ThreadSanitizer.
1840         (bmalloc::Environment::computeIsBmallocEnabled): Switch from
1841         isASanEnabled to isSanitizerEnabled.
1842
1843 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
1844
1845         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
1846         https://bugs.webkit.org/show_bug.cgi?id=157047
1847
1848         Reviewed by Filip Pizlo.
1849
1850         Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
1851
1852         * bmalloc/Algorithm.h:
1853         (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
1854         (bmalloc::roundUpToMultipleOfSloppy): Deleted.
1855         * bmalloc/VMHeap.cpp:
1856         (bmalloc::VMHeap::allocateSmallChunk):
1857
1858 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
1859
1860         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
1861         https://bugs.webkit.org/show_bug.cgi?id=157047
1862
1863         Reviewed by Filip Pizlo.
1864
1865         The previous fix aligned the guard page sizes correctly but forgot to
1866         align the guard page start address correctly.
1867
1868         * bmalloc/Algorithm.h:
1869         (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
1870         up when not working with a power of two, instead of writing out the
1871         math by hand.
1872
1873         * bmalloc/VMHeap.cpp:
1874         (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
1875         page start address in addition to its size. Assert at the very end to
1876         try to catch more bugs.
1877
1878 2016-04-27  Geoffrey Garen  <ggaren@apple.com>
1879
1880         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
1881         https://bugs.webkit.org/show_bug.cgi?id=157047
1882
1883         Reviewed by Darin Adler.
1884
1885         * bmalloc/Chunk.h:
1886         (bmalloc::Chunk::Chunk):
1887         (bmalloc::Chunk::get):
1888         (bmalloc::Chunk::offset):
1889         (bmalloc::Chunk::address):
1890         (bmalloc::Object::Object):
1891         (bmalloc::Object::address):
1892         (bmalloc::Object::line):
1893         (bmalloc::Chunk::object): Deleted.
1894         (bmalloc::Object::begin): Deleted.
1895         * bmalloc/Heap.cpp:
1896         (bmalloc::Heap::allocateSmallBumpRangesByObject):
1897         * bmalloc/Object.h:
1898         (bmalloc::Object::chunk):
1899         (bmalloc::Object::offset): Renamed begin() to address() because this is
1900         not an iterator.
1901
1902         * bmalloc/VMHeap.cpp:
1903         (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
1904         multiple because pageSize might be smaller than vmPageSize, but we
1905         think the VM system requires vmPageSize-aligned values.
1906
1907 2016-04-25  Geoffrey Garen  <ggaren@apple.com>
1908
1909         bmalloc: vm allocations should plant guard pages
1910         https://bugs.webkit.org/show_bug.cgi?id=156937
1911
1912         Rolling back in r199936 with a fix for the memory regression.
1913
1914 2016-04-23  Gavin Barraclough  <barraclough@apple.com>
1915
1916         bmalloc: vm allocations should plant guard pages
1917         https://bugs.webkit.org/show_bug.cgi?id=156937
1918
1919         Rolling out - looks like this is memory regression.
1920
1921         * bmalloc/Object.h:
1922         (bmalloc::Object::operator+):
1923         (bmalloc::Object::operator<=):
1924         (bmalloc::Object::operator-): Deleted.
1925         * bmalloc/VMAllocate.h:
1926         (bmalloc::vmDeallocate):
1927         (bmalloc::vmRevokePermissions): Deleted.
1928         * bmalloc/VMHeap.cpp:
1929         (bmalloc::VMHeap::allocateSmallChunk):
1930
1931 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
1932
1933         bmalloc: vm allocations should plant guard pages
1934         https://bugs.webkit.org/show_bug.cgi?id=156937
1935
1936         Reviewed by Michael Saboff.
1937
1938         * bmalloc/Object.h:
1939         (bmalloc::Object::operator-): Added a - helper.
1940
1941         * bmalloc/VMAllocate.h:
1942         (bmalloc::vmRevokePermissions): Added a helper to revoke permissions on
1943         a VM region. We use this for guard pages.
1944
1945         * bmalloc/VMHeap.cpp:
1946         (bmalloc::VMHeap::allocateSmallChunk): Add guard pages to the start and
1947         end of the chunk.
1948
1949         Note that we don't guard large chunks becuase we need to be able to merge
1950         them. Otherwise, we will run out of virtual addresses.
1951
1952 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
1953
1954         bmalloc: Constify introspect function pointer table
1955         https://bugs.webkit.org/show_bug.cgi?id=156936
1956
1957         Reviewed by Michael Saboff.
1958
1959         * bmalloc/Zone.cpp:
1960         (bmalloc::Zone::Zone): Declaring this function pointer table const puts
1961         it in the read-only section of the binary, providing a little hardening
1962         against overwriting the function pointers at runtime. (We have to
1963         const_cast when assigning because the API declares a pointer to non-const,
1964         but we happen to know it will never try to write through that pointer.
1965         This is not my favorite API.)
1966
1967 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
1968
1969         bmalloc: fix up overflow checks
1970         https://bugs.webkit.org/show_bug.cgi?id=156780
1971
1972         Reviewed by Mark Lam.
1973
1974         We used to try to avoid overflow in large object math by setting a very
1975         high limit on the largest large object. But that's a bit error-prone
1976         since the check is far away from the math that might overflow -- and
1977         we were missing some cases.
1978
1979         This patch removes the limit and instead checks at each math site.
1980
1981         * bmalloc/Allocator.cpp:
1982         (bmalloc::Allocator::tryAllocate):
1983         (bmalloc::Allocator::allocate):
1984         (bmalloc::Allocator::reallocate):
1985         (bmalloc::Allocator::allocateSlowCase): Remove the limit. tryAllocateLarge
1986         will check for overflow for us.
1987
1988         * bmalloc/Chunk.h: This ASSERT was just totally wrong.
1989
1990         * bmalloc/Heap.cpp:
1991         (bmalloc::Heap::tryAllocateLarge): Check for overflow when adding.
1992
1993         * bmalloc/Sizes.h:
1994
1995         * bmalloc/VMAllocate.h:
1996         (bmalloc::tryVMAllocate): Check for overflow when adding.
1997
1998         * bmalloc/VMHeap.cpp:
1999         (bmalloc::VMHeap::tryAllocateLargeChunk): Check for overflow when adding.
2000
2001 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
2002
2003         Unreviewed, try to fix an ASSERT seen on the bots.
2004
2005         * bmalloc/Heap.cpp:
2006         (bmalloc::Heap::tryAllocateLarge): This ASSERT is supposed to be about
2007         alignment, not size. Oops.
2008
2009 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
2010
2011         bmalloc: Merge the large and xlarge allocators
2012         https://bugs.webkit.org/show_bug.cgi?id=156734
2013
2014         Reviewed by Andreas Kling.
2015
2016         This give us better defense against worst case memory usage:
2017
2018                                               Baseline                Patch                    Δ
2019             Peak Memory:
2020                 nimlang                      198,132kB            181,468kB      ^ 1.09x smaller
2021
2022         It also eliminates inline metadata for large objects, fixing the
2023         regression introduced in r198675, and more:
2024
2025             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
2026
2027                                                                   Baseline                          Patch                              Δ
2028             Memory at End:
2029                 big                                               10,880kB                        3,328kB                ^ 3.27x smaller
2030                 facebook                                           3,112kB                        2,868kB                ^ 1.09x smaller
2031                 fragment --parallel                                1,848kB                          760kB                ^ 2.43x smaller
2032                 fragment_iterate --parallel                        4,908kB                          776kB                ^ 6.32x smaller
2033                 big --parallel                                    48,076kB                       11,892kB                ^ 4.04x smaller
2034
2035         Overall memory use looks OK:
2036
2037             run-malloc-benchmarks --memory_warning Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
2038
2039                                                         Baseline                               Patch                                   Δ
2040             Memory at End:
2041                 <arithmetic mean>                       13,992kB                            13,987kB                      ^ 1.0x smaller
2042
2043         Overall throughput looks OK:
2044
2045             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
2046
2047                                                                   Baseline                          Patch                              Δ
2048             Execution Time:
2049                 <arithmetic mean>                                    103ms                          104ms                 ! 1.01x slower
2050
2051         We're a bit slower on the "all-out large allocations on all cores"
2052         benchmark, but I think that's an OK price to pay:
2053
2054                                                                   Baseline                          Patch                              Δ
2055             Execution Time:
2056                 big --parallel                                       125ms                          136ms                 ! 1.09x slower
2057
2058         This patch net removes 1.5k lines of code. It turns out that large
2059         allocations are rare, and free memory fragments are also rare, so the
2060         combination is super rare, and a simple O(n) algorithm that ensures good
2061         memory behavior is the best option.
2062
2063         Fun fact: In practice, the odds that the old code would save memory
2064         were *worse* than the odds that it would contain a bug that wasted
2065         memory. :)
2066
2067         * bmalloc.xcodeproj/project.pbxproj:
2068
2069         * bmalloc/Allocator.cpp:
2070         (bmalloc::Allocator::tryAllocate): largeMax is the new xLargeMax since
2071         xLargeMax is gone now.
2072
2073         (bmalloc::Allocator::allocate): I moved the rounding code into allocateLarge,
2074         so we don't have to do it here.
2075
2076         (bmalloc::Allocator::reallocate):
2077         (bmalloc::Allocator::allocateSlowCase):
2078         (bmalloc::Allocator::allocateXLarge): Deleted. No more XLarge case.
2079
2080         * bmalloc/Allocator.h:
2081
2082         * bmalloc/BeginTag.h: Removed.
2083         * bmalloc/BoundaryTag.h: Removed.
2084
2085         * bmalloc/Chunk.h:
2086         (bmalloc::ChunkHash::hash): Added a hash function. The best hash function
2087         is a unique and monotonically increasing integer, and that's exactly what
2088         we typically get from the high bits of a Chunk, since the OS allocates
2089         Chunks at unique and increasing addresses.
2090         (bmalloc::Chunk::boundaryTags): Deleted.
2091         (bmalloc::Chunk::objectType): Deleted.
2092         (bmalloc::Chunk::beginTag): Deleted.
2093         (bmalloc::Chunk::endTag): Deleted.
2094
2095         * bmalloc/Deallocator.cpp:
2096         (bmalloc::Deallocator::deallocateSlowCase): We no longer know for sure,
2097         by looking at its bit pattern, whether a pointer is small or large.
2098         Instead, any pointer with large alignment *might* be large, and when
2099         we occasionally encounter such an object, we have to consult a hash
2100         table in the Heap to find out for sure. This turns out to be just as
2101         cheap in practice.
2102
2103         We don't deallocate large objects on the fast path anymore. We can't,
2104         because large objects have out-of-line metadata now.
2105
2106         (bmalloc::Deallocator::deallocateXLarge): Deleted.
2107
2108         * bmalloc/Deallocator.h:
2109         (bmalloc::Deallocator::deallocateFastCase): See deallocateSlowCase.
2110
2111         * bmalloc/EndTag.h: Removed.
2112         * bmalloc/FreeList.cpp: Removed.
2113         * bmalloc/FreeList.h: Removed.
2114
2115         * bmalloc/Heap.cpp:
2116         (bmalloc::Heap::allocateSmallPage): Be sure to track each chunk in
2117         the object type map, so we can distinguish small vs large objects.
2118
2119         (bmalloc::Heap::deallocateSmallLine): No need to check object type
2120         because we know object type now by virtue of being on the small object
2121         path.
2122
2123         (bmalloc::Heap::splitAndAllocate): Be sure to track each chunk in
2124         the object type map, so we can distinguish small vs large objects. Large
2125         objects can split across chunks, so we need to add each large object's
2126         chunk as it is allocated.
2127
2128         (bmalloc::Heap::tryAllocateLarge):
2129         (bmalloc::Heap::allocateLarge):
2130         (bmalloc::Heap::isLarge):
2131         (bmalloc::Heap::largeSize):
2132         (bmalloc::Heap::shrinkLarge):
2133         (bmalloc::Heap::deallocateLarge): Merged in existing XLarge logic for
2134         large objects.
2135
2136         (bmalloc::Heap::scavengeXLargeObjects): Deleted.
2137         (bmalloc::Heap::allocateXLarge): Deleted.
2138         (bmalloc::Heap::tryAllocateXLarge): Deleted.
2139         (bmalloc::Heap::xLargeSize): Deleted.
2140         (bmalloc::Heap::shrinkXLarge): Deleted.
2141         (bmalloc::Heap::deallocateXLarge): Deleted.
2142
2143         * bmalloc/Heap.h:
2144         (bmalloc::Heap::LargeObjectHash::hash):
2145
2146         * bmalloc/LargeObject.h: Removed.
2147
2148         * bmalloc/Map.h: Added.
2149         (bmalloc::Map::size):
2150         (bmalloc::Map::capacity):
2151         (bmalloc::Map::get):
2152         (bmalloc::Map::set):
2153         (bmalloc::Map::remove):
2154         (bmalloc::Map::shouldGrow):
2155         (bmalloc::Map::shouldShrink):
2156         (bmalloc::Map::find):
2157         (bmalloc::Hash>::rehash): Simple hash table.
2158
2159         * bmalloc/Object.h:
2160
2161         * bmalloc/ObjectType.cpp:
2162         (bmalloc::objectType):
2163         * bmalloc/ObjectType.h:
2164         (bmalloc::mightBeLarge): See deallocateSlowCase.
2165         (bmalloc::isXLarge): Deleted.
2166
2167         * bmalloc/SegregatedFreeList.cpp: Removed.
2168         * bmalloc/SegregatedFreeList.h: Removed.
2169
2170         * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
2171         reasonable, since sizes between 16kB and 32kB share page sizes. I went
2172         all the way up to 64kB because the GC uses 64kB blocks, and also just
2173         for extra padding to ensure that large allocations are indeed rare.
2174
2175         * bmalloc/SortedVector.h: Removed.
2176
2177         * bmalloc/VMHeap.cpp:
2178         (bmalloc::VMHeap::tryAllocateLargeChunk):
2179         (bmalloc::VMHeap::allocateSmallChunk):
2180         (bmalloc::VMHeap::VMHeap): Deleted.
2181         (bmalloc::VMHeap::allocateChunk): Deleted.
2182         * bmalloc/VMHeap.h:
2183         (bmalloc::VMHeap::deallocateSmallPage):
2184         (bmalloc::VMHeap::allocateLargeObject): Deleted.
2185         (bmalloc::VMHeap::deallocateLargeObject): Deleted. Nixed all the boundary
2186         tag logic since metadata is out of line now.
2187
2188         * bmalloc/VMState.h: Removed. Instead of an abstract state, we track
2189         the precise amount of committed physical pages at the head of a VM
2190         range. This allows us to merge aggressively without triggering an madvise
2191         storm most of the time.
2192
2193         * bmalloc/Vector.h:
2194         (bmalloc::Vector<T>::Vector):
2195         (bmalloc::Vector<T>::insert):
2196         (bmalloc::Vector<T>::remove):
2197         (bmalloc::Vector<T>::resize): Filled out some missing helpers.
2198
2199         * bmalloc/XLargeMap.cpp:
2200         (bmalloc::XLargeMap::remove):
2201         (bmalloc::XLargeMap::add):
2202         (bmalloc::XLargeMap::removePhysical):
2203         (bmalloc::XLargeMap::takeFree): Deleted.
2204         (bmalloc::XLargeMap::addFree): Deleted.
2205         (bmalloc::XLargeMap::addAllocated): Deleted.
2206         (bmalloc::XLargeMap::getAllocated): Deleted.
2207         (bmalloc::XLargeMap::takeAllocated): Deleted.
2208         (bmalloc::XLargeMap::shrinkToFit): Deleted.
2209         (bmalloc::XLargeMap::takePhysical): Deleted.
2210         (bmalloc::XLargeMap::addVirtual): Deleted.
2211         * bmalloc/XLargeMap.h:
2212         (bmalloc::XLargeMap::Allocation::operator<): Deleted. We don't track
2213         object sizes anymore -- just free space. (The Heap tracks object sizes.)
2214         We use plain old linear search for free space. (See intro.)
2215
2216         * bmalloc/XLargeRange.h:
2217         (bmalloc::XLargeRange::physicalSize):
2218         (bmalloc::XLargeRange::setPhysicalSize):
2219         (bmalloc::merge):
2220         (bmalloc::XLargeRange::split):
2221         (bmalloc::XLargeRange::vmState): Deleted.
2222         (bmalloc::XLargeRange::setVMState): Deleted. See VMState.h.
2223
2224 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
2225
2226         [CMake] Make FOLDER property INHERITED
2227         https://bugs.webkit.org/show_bug.cgi?id=156460
2228
2229         Reviewed by Brent Fulgham.
2230
2231         * CMakeLists.txt:
2232         Set FOLDER property as a directory property not a target property
2233
2234 2016-04-08  Geoffrey Garen  <ggaren@apple.com>
2235
2236         bmalloc: stress_aligned test fails if you increase smallMax
2237         https://bugs.webkit.org/show_bug.cgi?id=156414
2238
2239         Reviewed by Oliver Hunt.
2240
2241         When size exceeds alignment and is a multiple of alignment and is not
2242         a power of two, such as 24kB with 8kB alignment, the small allocator
2243         did not always guarantee alignment. Let's fix that.
2244
2245         * bmalloc/Algorithm.h:
2246         (bmalloc::divideRoundingUp): Math is hard.
2247
2248         * bmalloc/Allocator.cpp:
2249         (bmalloc::Allocator::allocate): Align to the page size unconditionally.
2250         Even if the page size is not a power of two, it might be a multiple of
2251         a power of two, and we want alignment to that smaller power of two to
2252         be guaranteed.
2253
2254 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
2255
2256         bmalloc: handle aligned allocations on the fast path
2257         https://bugs.webkit.org/show_bug.cgi?id=156302
2258
2259         Reviewed by Michael Saboff.
2260
2261         This helps keep the JavaScriptCore GC on the fast path, and it also
2262         helps avoid fragmentation on our website stress test:
2263
2264             nimlang                      209,584kB            198,076kB      ^ 1.06x smaller
2265
2266         * bmalloc/Allocator.cpp:
2267         (bmalloc::Allocator::allocate): Because we arrange for power-of-two size
2268         classes to allocate at power-of-two alignments, we can allocate any
2269         small aligned request on the small path.
2270
2271         * bmalloc/Chunk.h:
2272         (bmalloc::Chunk::bytes):
2273         (bmalloc::Chunk::lines):
2274         (bmalloc::Chunk::pages):
2275         (bmalloc::Chunk::boundaryTags):
2276         (bmalloc::Chunk::objectType): Moved some code around to provide better
2277         API.
2278
2279         (bmalloc::Chunk::Chunk): Moved this code to VMHeap.
2280
2281         (bmalloc::Chunk::offset):
2282         (bmalloc::Chunk::object): Use our new bytes() helper function.
2283
2284         * bmalloc/VMHeap.cpp:
2285         (bmalloc::VMHeap::allocateChunk): Moved code here from Chunk.
2286
2287         (bmalloc::VMHeap::allocateSmallChunk): Ensure that power-of-two page
2288         sizes always begin allocation at the same alignment. Power-of-two object
2289         sizes always request power-of-two page sizes (since that's the least
2290         wasteful option), so if we also ensure that power-of-two page sizes get
2291         power-of-two alignment, then everything is aligned for all small objects.
2292
2293 2016-04-03  Geoffrey Garen  <ggaren@apple.com>
2294
2295         bmalloc: segregate small and large objects again, and allocate more objects on the small path
2296         https://bugs.webkit.org/show_bug.cgi?id=156152
2297
2298         Reviewed by Sam Weinig.
2299
2300         Microbenchmark data suggested that it was a good idea for small and large
2301         objects to share memory. But r198675 did not improve memory use in
2302         full browser benchmarks.
2303
2304         This patch reverts to segregating small and large objects -- but without
2305         going back to doubled VM usage -- in order to capture a few benefits:
2306
2307         (*) Small pages fragment the large heap. Separating them out saves a lot
2308         of memory in our worst case fragmentation recording:
2309
2310             nimlang                                          276,076kB                      209,636kB                ^ 1.32x smaller
2311
2312         (*) Small objects are common enough that even their slow paths benefit 
2313         from simpler code:
2314
2315         Execution Time:
2316             ...
2317             facebook                                             234ms                          216ms                 ^ 1.08x faster
2318             reddit                                               114ms                          108ms                 ^ 1.06x faster
2319             flickr                                               118ms                          111ms                 ^ 1.06x faster
2320             theverge                                             146ms                          140ms                 ^ 1.04x faster
2321             ...
2322             <arithmetic mean>                                    107ms                          102ms                 ^ 1.04x faster
2323
2324         (*) We can use less metadata:
2325
2326         Memory at End:
2327             ...
2328             list_allocate                                        460kB                          384kB                 ^ 1.2x smaller
2329             tree_allocate                                        492kB                          424kB                ^ 1.16x smaller
2330             tree_churn                                           480kB                          404kB                ^ 1.19x smaller
2331             fragment                                             532kB                          452kB                ^ 1.18x smaller
2332             fragment_iterate                                     712kB                          588kB                ^ 1.21x smaller
2333             medium                                            15,152kB                       11,796kB                ^ 1.28x smaller
2334             big                                               15,044kB                       10,976kB                ^ 1.37x smaller
2335             ...
2336             <arithmetic mean>                                  7,724kB                        7,190kB                ^ 1.07x smaller
2337
2338         This patch also takes advantage of our support for varying the page size
2339         at runtime by allocating more objects on the small object path:
2340
2341             medium                                               178ms                          150ms                 ^ 1.19x faster
2342
2343         Some microbenchmarks report memory use increases from this change -- like
2344         they reported memory use decreases from r198675 -- but I'm ignoring them
2345         for now because I expect our full browser memory benchmarks to confirm
2346         that this patch is fine.
2347
2348         * bmalloc/BumpAllocator.h:
2349         (bmalloc::BumpAllocator::BumpAllocator): Use a full unsigned because we
2350         can allocate objects larger than 16kB - 1, and a full unsigned does not
2351         make BumpAllocator any larger on 64bit systems.
2352
2353         * bmalloc/Chunk.h:
2354         (bmalloc::Chunk::begin):
2355         (bmalloc::Chunk::end):
2356         (bmalloc::Chunk::size):
2357         (bmalloc::Chunk::objectType): Store ObjectType in the Chunk, since it only
2358         varies by Chunk now, and not from page to page within a Chunk. Also,
2359         union together small and large object metadata, since we will only use
2360         one or the other. This saves memory.
2361
2362         (bmalloc::Chunk::Chunk): Conditionalize initialization based on object
2363         type, since only one kind of metadata or the other can be used at runtime.
2364
2365         (bmalloc::Object::Object):
2366         (bmalloc::Object::begin):
2367         (bmalloc::SmallPage::end): Deleted.
2368
2369         * bmalloc/Heap.cpp:
2370         (bmalloc::Heap::Heap):
2371         (bmalloc::Heap::initializeLineMetadata): Save a little space, since we
2372         know that lines are only 256 bytes long.
2373
2374         (bmalloc::Heap::initializePageMetadata): Store a dynamic page size for
2375         each size class. We used to use only one page size (the system page size)
2376         but that limited our ability to allocate objects larger than 1kB on the
2377         small object path. Now we can handle any object size we want by storing
2378         objects of that size in a custom page size.
2379
2380         (bmalloc::Heap::concurrentScavenge):
2381         (bmalloc::Heap::scavenge):
2382         (bmalloc::Heap::scavengeSmallPages): Revert to our old linked list
2383         strategy for storing small pages.
2384
2385         (bmalloc::Heap::splitAndAllocate): Object type is per Chunk now.
2386
2387         (bmalloc::Heap::allocateLarge): Don't nuke the small page list when
2388         allocating a large object because the two don't share memory anymore.
2389
2390         (bmalloc::Heap::allocateSmallPage): Revert to our old linked list
2391         strategy for storing small pages.
2392
2393         (bmalloc::Heap::deallocateSmallLine): Don't return early in the case
2394         where this is the first free object in the page. In the case of large-ish
2395         objects, the first free object might also be the last free object,
2396         since there's one object per page.
2397
2398         (bmalloc::Heap::allocateSmallBumpRangesByMetadata): Split out some helper
2399         lambdas to make this code clearer.
2400
2401         (bmalloc::Heap::allocateSmallBumpRangesByObject): Added a fast scan
2402         for objects larger than the line size. When multiple objects fit in
2403         a single line, it's an optimization to scan a line at a time. But when
2404         it's one object per line, or one object per 64 lines, it's better just
2405         to scan an object at a time.
2406
2407         * bmalloc/Heap.h:
2408         (bmalloc::Heap::allocateSmallBumpRanges):
2409         (bmalloc::Heap::derefSmallLine): Match the changes above.
2410
2411         * bmalloc/LineMetadata.h: We weren't using all those bits.
2412
2413         * bmalloc/List.h:
2414         (bmalloc::List::remove): Put a removed Node fully back into the default
2415         (empty) state it was in before it entered the list. This change is not
2416         observable, but it makes things clearer when you're debugging.
2417
2418         * bmalloc/Object.h:
2419         (bmalloc::Object::Object):
2420         (bmalloc::Object::chunk):
2421         (bmalloc::Object::offset):
2422         (bmalloc::Object::operator+):
2423         (bmalloc::Object::operator<=): Added some helpers for iterating by object.
2424
2425         * bmalloc/ObjectType.cpp:
2426         (bmalloc::objectType): Updated for API change.
2427
2428         * bmalloc/Sizes.h:
2429         (bmalloc::Sizes::maskObjectSize):
2430         (bmalloc::Sizes::objectSize):
2431         (bmalloc::Sizes::pageSize): Support more page sizes.
2432
2433         * bmalloc/SmallPage.h:
2434         (bmalloc::SmallPage::SmallPage):
2435         (bmalloc::SmallPage::objectType): Deleted.
2436         (bmalloc::SmallPage::setObjectType): Deleted.
2437         (bmalloc::SmallPage::smallPageCount): Deleted.
2438         (bmalloc::SmallPage::setSmallPageCount): Deleted. Object type is per
2439         Chunk now, and we can infer page count from size class.
2440
2441         * bmalloc/VMHeap.cpp:
2442         (bmalloc::VMHeap::allocateChunk):
2443         (bmalloc::VMHeap::allocateSmallChunk):
2444         * bmalloc/VMHeap.h:
2445         (bmalloc::VMHeap::allocateSmallPage):
2446         (bmalloc::VMHeap::deallocateSmallPage):
2447         (bmalloc::VMHeap::allocateLargeObject): Support our old behavior of
2448         storing free pages in linked lists.
2449
2450 2016-03-29  Geoffrey Garen  <ggaren@apple.com>
2451
2452         bmalloc: support physical page sizes that don't match the virtual page size (take 2)
2453         https://bugs.webkit.org/show_bug.cgi?id=156003
2454
2455         Reviewed by Andreas Kling.
2456
2457         This is a memory savings on iOS devices where the virtual page size
2458         is 16kB but the physical page size is 4kB.
2459
2460         Take 1 was a memory regression on 16kB virtual / 16kB physical systems
2461         because it used a 4kB page size within a 16kB page size, allowing up to
2462         4 different object types to mix within a physical page. Because objects
2463         of the same type tend to deallocate at the same time, mixing objects of
2464         different types made pages less likely to become completely empty.
2465
2466         (Take 1 also had a bug where it used a platform #ifdef that didn't exist.
2467         Oops.)
2468
2469         Take 2 allocates units of SmallPages equal to the physical page size.
2470
2471         * bmalloc/Heap.cpp:
2472         (bmalloc::Heap::Heap):
2473         (bmalloc::Heap::initializeLineMetadata):
2474         (bmalloc::Heap::allocateSmallBumpRanges):
2475         (bmalloc::Heap::allocateSmallPage):
2476         (bmalloc::Heap::allocateLarge):
2477         (bmalloc::Heap::splitAndAllocate):
2478         (bmalloc::Heap::tryAllocateXLarge):
2479         (bmalloc::Heap::shrinkXLarge):
2480         * bmalloc/Heap.h: Use the physical page size for our VM operations because
2481         we're only concerned with returning physical pages to the OS.
2482
2483         * bmalloc/VMAllocate.h:
2484         (bmalloc::vmPageSize):
2485         (bmalloc::vmPageShift):
2486         (bmalloc::vmSize):
2487         (bmalloc::vmValidate):
2488         (bmalloc::vmPageSizePhysical):
2489         (bmalloc::vmValidatePhysical):
2490         (bmalloc::tryVMAllocate):
2491         (bmalloc::vmDeallocatePhysicalPages):
2492         (bmalloc::vmAllocatePhysicalPages):
2493         (bmalloc::vmDeallocatePhysicalPagesSloppy):
2494         (bmalloc::vmAllocatePhysicalPagesSloppy): Use the physical page size.
2495
2496 2016-03-29  Geoffrey Garen  <ggaren@apple.com>
2497
2498         bmalloc: page size should be configurable at runtime
2499         https://bugs.webkit.org/show_bug.cgi?id=155993
2500
2501         Reviewed by Andreas Kling.
2502
2503         This is a memory win on 32bit iOS devices, since their page sizes are
2504         4kB and not 16kB.
2505
2506         It's also a step toward supporting 64bit iOS devices that have a
2507         16kB/4kB virtual/physical page size split.
2508
2509         * bmalloc/Chunk.h: Align to largeAlignment since 2 * smallMax isn't
2510         required by the boundary tag allocator.
2511
2512         (bmalloc::Chunk::page): Account for the slide when accessing a page.
2513         Each SmallPage hashes 4kB of memory. When we want to allocate a region
2514         of memory larger than 4kB, we store our metadata in the first SmallPage
2515         in the region and we assign a slide to the remaining SmallPages, so
2516         they forward to that first SmallPage when accessed.
2517
2518         NOTE: We could use a less flexible technique that just hashed by
2519         vmPageSize() instead of 4kB at runtime, with no slide, but I think we'll
2520         be able to use this slide technique to make even more page sizes
2521         dynamically at runtime, which should save some memory and simplify
2522         the allocator.
2523
2524         (bmalloc::SmallPage::begin): It's invalid to access a SmallPage with
2525         a slide, since such SmallPages do not contain meaningful data.
2526
2527         (bmalloc::SmallPage::end): Account for smallPageCount when computing
2528         the size of a page.
2529
2530         (bmalloc::Chunk::pageBegin): Deleted.
2531         (bmalloc::Chunk::pageEnd): Deleted.
2532         (bmalloc::Object::pageBegin): Deleted.
2533
2534         * bmalloc/Heap.cpp:
2535         (bmalloc::Heap::Heap): Cache vmPageSize because computing it might require
2536         a syscall.
2537
2538         (bmalloc::Heap::initializeLineMetadata): Line metadata is a vector instead
2539         of a 2D array because we don't know how much metadata we'll need until
2540         we know the page size.
2541
2542         (bmalloc::Heap::scavengeSmallPage): Be sure to revert the slide when
2543         deallocating a page. Otherwise, the next attempt to allocate the page
2544         will slide when initializing it, sliding to nowhere.
2545
2546         (bmalloc::Heap::allocateSmallBumpRanges): Account for vector change to
2547         line metadata.
2548
2549         (bmalloc::Heap::allocateSmallPage): Initialize slide and smallPageCount
2550         since they aren't constant anymore.
2551
2552         (bmalloc::Heap::allocateLarge):
2553         (bmalloc::Heap::splitAndAllocate):
2554         (bmalloc::Heap::tryAllocateXLarge):
2555         (bmalloc::Heap::shrinkXLarge): Adopt dynamic page size.
2556
2557         * bmalloc/Heap.h:
2558
2559         * bmalloc/Sizes.h: smallPageSize is no longer equal to the VM page
2560         size -- it's just the smallest VM page size we're interested in supporting.
2561
2562         * bmalloc/SmallPage.h:
2563         (bmalloc::SmallPage::slide):
2564         (bmalloc::SmallPage::setSlide):
2565         (bmalloc::SmallPage::smallPageCount):
2566         (bmalloc::SmallPage::setSmallPageCount):
2567         (bmalloc::SmallPage::ref):
2568         (bmalloc::SmallPage::deref): Support slide and small page count as
2569         dynamic values. This doesn't increase metadata size since sizeof(SmallPage)
2570         rounds up to alignment anyway.
2571
2572         * bmalloc/VMAllocate.h:
2573         (bmalloc::vmPageSize):
2574         (bmalloc::vmPageShift):
2575         (bmalloc::vmSize):
2576         (bmalloc::vmValidate):
2577         (bmalloc::tryVMAllocate):
2578         (bmalloc::vmDeallocatePhysicalPagesSloppy):
2579         (bmalloc::vmAllocatePhysicalPagesSloppy): Treat page size as a variable.
2580
2581         * bmalloc/Vector.h:
2582         (bmalloc::Vector::initialCapacity):
2583         (bmalloc::Vector<T>::insert):
2584         (bmalloc::Vector<T>::grow):
2585         (bmalloc::Vector<T>::shrink):
2586         (bmalloc::Vector<T>::shrinkCapacity):
2587         (bmalloc::Vector<T>::growCapacity): Treat page size as a variable.
2588
2589 2016-03-29  David Kilzer  <ddkilzer@apple.com>
2590
2591         bmalloc: add logging for mmap() failures
2592         <http://webkit.org/b/155409>
2593         <rdar://problem/24568515>
2594
2595         Reviewed by Saam Barati.
2596
2597         This patch causes additional logging to be generated on internal
2598         iOS builds when mmap() fails.  We are trying to track down an
2599         issue where the WebContent process runs out of VM address space
2600         before it is killed by jetsam.
2601
2602         * CMakeLists.txt: Add Logging.cpp.
2603         * bmalloc.xcodeproj/project.pbxproj: Add new files.
2604
2605         * bmalloc/BAssert.h:
2606         (RELEASE_BASSERT_WITH_MESSAGE): Add macro.
2607         * bmalloc/Logging.cpp: Added.
2608         (bmalloc::logVMFailure): Implementation.
2609         * bmalloc/Logging.h: Added.
2610         (bmalloc::logVMFailure): Declaration.
2611         * bmalloc/VMAllocate.h:
2612         (bmalloc::tryVMAllocate): Call logVMFailure() on mmap() failure.
2613         * bmalloc/darwin/BSoftLinking.h: Copied from Source/WebCore/platform/mac/SoftLinking.h.
2614
2615 2016-03-26  Geoffrey Garen  <ggaren@apple.com>
2616
2617         Unreviewed, rolling out r198702, r198704.
2618
2619         Caused a memory regression on PLUM.
2620
2621         Reverted changeset:
2622
2623         bmalloc: fix an ASSERT on iOS
2624         https://bugs.webkit.org/show_bug.cgi?id=155911
2625         http://trac.webkit.org/changeset/198704
2626
2627         bmalloc: support physical page sizes that don't match the virtual page size
2628         https://bugs.webkit.org/show_bug.cgi?id=155898
2629         http://trac.webkit.org/changeset/198702
2630
2631 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2632
2633         bmalloc: fix an ASSERT on iOS
2634         https://bugs.webkit.org/show_bug.cgi?id=155911
2635
2636         Reviewed by Gavin Barraclough.
2637
2638         * bmalloc/VMAllocate.h:
2639         (bmalloc::vmValidatePhysical): Call through to vmValidatePhysical because
2640         the vmValidate function validates virtual sizes rather than physical
2641         sizes.
2642
2643 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2644
2645         bmalloc: support physical page sizes that don't match the virtual page size
2646         https://bugs.webkit.org/show_bug.cgi?id=155898
2647
2648         Reviewed by Gavin Barraclough.
2649
2650         This is a memory savings on iOS devices where the virtual page size
2651         is 16kB but the physical page size is 4kB.
2652
2653         * bmalloc/Chunk.h:
2654         (bmalloc::Chunk::Chunk): smallPageSize is now unrelated to the OS's
2655         page size -- it just reflects the optimal unit of memory to recycle
2656         between small objects.
2657
2658         We only need to round up to largeAlignment because small objects allocate
2659         as subsets of large objects now.
2660
2661         (bmalloc::Chunk::page):
2662         (bmalloc::Object::pageBegin):
2663         (bmalloc::Object::line): Adopt smallPageSize.
2664
2665         * bmalloc/Heap.cpp:
2666         (bmalloc::Heap::initializeLineMetadata):
2667         (bmalloc::Heap::allocateSmallPage):
2668         (bmalloc::Heap::allocateLarge): Adopt smallPageSize.
2669
2670         (bmalloc::Heap::splitAndAllocate):
2671         (bmalloc::Heap::tryAllocateXLarge):
2672         (bmalloc::Heap::shrinkXLarge): Adopt vmPageSizePhysical(). We want the
2673         physical page size because that's the unit at which the hardware MMU
2674         will recycle memory.
2675
2676         * bmalloc/Sizes.h: Adopt smallPageSize.
2677
2678         * bmalloc/VMAllocate.h:
2679         (bmalloc::vmPageSizePhysical):
2680         (bmalloc::vmPageSize): Distinguish between page size, which is the virtual
2681         memory page size advertised by the OS, and physical page size, which the
2682         true hardware page size.
2683
2684         (bmalloc::vmSize):
2685         (bmalloc::vmValidate):
2686         (bmalloc::vmValidatePhysical):
2687         (bmalloc::tryVMAllocate):
2688         (bmalloc::vmDeallocatePhysicalPages):
2689         (bmalloc::vmAllocatePhysicalPages):
2690         (bmalloc::vmDeallocatePhysicalPagesSloppy):
2691         (bmalloc::vmAllocatePhysicalPagesSloppy): Adopt vmPageSize() and
2692         vmPageSizePhyiscal().
2693
2694         * bmalloc/Vector.h:
2695         (bmalloc::Vector::initialCapacity):
2696         (bmalloc::Vector<T>::shrink):
2697         (bmalloc::Vector<T>::shrinkCapacity):
2698         (bmalloc::Vector<T>::growCapacity): Adopt vmPageSize(). We'd prefer to
2699         use vmPageSizePhysical() but mmap() doesn't support it.
2700
2701         * bmalloc/XLargeMap.cpp: #include.
2702
2703 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2704
2705         Unreviewed, rolling in r198679.
2706
2707         r198679 was just a rename. The regression was caused by r198675 and then
2708         fixed in r198693.
2709
2710         Restored changeset:
2711
2712         "bmalloc: Renamed LargeChunk => Chunk"
2713         https://bugs.webkit.org/show_bug.cgi?id=155894
2714         http://trac.webkit.org/changeset/198679
2715
2716 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2717
2718         Unreviewed, try to fix a crash seen on the bots.
2719
2720         * bmalloc/Allocator.cpp:
2721         (bmalloc::Allocator::reallocate): We have to take the lock even if we're
2722         only reading our own data becuse LargeObject contains validation code
2723         that will read our neighbors' data as well.
2724
2725 2016-03-25  Ryan Haddad  <ryanhaddad@apple.com>
2726
2727         Unreviewed, rolling out r198679.
2728
2729         This change caused flaky LayoutTest crashes
2730
2731         Reverted changeset:
2732
2733         "bmalloc: Renamed LargeChunk => Chunk"
2734         https://bugs.webkit.org/show_bug.cgi?id=155894
2735         http://trac.webkit.org/changeset/198679
2736
2737 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2738
2739         bmalloc: stress_aligned fails when allocating a zero-sized object with XLarge alignment
2740         https://bugs.webkit.org/show_bug.cgi?id=155896
2741
2742         Reviewed by Andreas Kling.
2743
2744         We normally filter zero-sized allocations into small allocations, but
2745         a zero-sized allocation can sneak through if it requires sufficiently
2746         large alignment.
2747
2748         * bmalloc/Heap.cpp:
2749         (bmalloc::Heap::tryAllocateXLarge): Set a floor on allocation size to
2750         catch zero-sized allocations.
2751
2752 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
2753
2754         bmalloc: Renamed LargeChunk => Chunk
2755         https://bugs.webkit.org/show_bug.cgi?id=155894
2756
2757         Reviewed by Michael Saboff.
2758
2759         A Chunk can contain both small and large objects now.
2760
2761         * bmalloc.xcodeproj/project.pbxproj:
2762         * bmalloc/Allocator.cpp:
2763         (bmalloc::Allocator::allocate):
2764         * bmalloc/BoundaryTag.h:
2765         (bmalloc::BoundaryTag::isFree):
2766         * bmalloc/Chunk.h: Copied from Source/bmalloc/bmalloc/LargeChunk.h.
2767         (bmalloc::Chunk::pages):
2768         (bmalloc::Chunk::begin):
2769         (bmalloc::Chunk::end):
2770         (bmalloc::Chunk::Chunk):
2771         (bmalloc::Chunk::get):
2772         (bmalloc::Chunk::beginTag):
2773         (bmalloc::Chunk::endTag):
2774         (bmalloc::Chunk::offset):
2775         (bmalloc::Chunk::object):
2776         (bmalloc::Chunk::page):
2777         (bmalloc::Chunk::line):
2778         (bmalloc::SmallLine::begin):
2779         (bmalloc::SmallPage::begin):
2780         (bmalloc::SmallPage::end):
2781         (bmalloc::Object::Object):
2782         (bmalloc::Object::begin):
2783         (bmalloc::LargeChunk::pages): Deleted.
2784         (bmalloc::LargeChunk::begin): Deleted.
2785         (bmalloc::LargeChunk::end): Deleted.
2786         (bmalloc::LargeChunk::LargeChunk): Deleted.
2787         (bmalloc::LargeChunk::get): Deleted.
2788         (bmalloc::LargeChunk::beginTag): Deleted.
2789         (bmalloc::LargeChunk::endTag): Deleted.
2790         (bmalloc::LargeChunk::offset): Deleted.
2791         (bmalloc::LargeChunk::object): Deleted.
2792         (bmalloc::LargeChunk::page): Deleted.
2793         (bmalloc::LargeChunk::line): Deleted.
2794         * bmalloc/Deallocator.cpp:
2795         * bmalloc/FreeList.cpp:
2796         * bmalloc/Heap.cpp:
2797         (bmalloc::Heap::allocateLarge):
2798         * bmalloc/LargeChunk.h: Removed.
2799         * bmalloc/LargeObject.h:
2800         (bmalloc::LargeObject::LargeObject):
2801         (bmalloc::LargeObject::merge):
2802         (bmalloc::LargeObject::split):
2803         * bmalloc/Object.h:
2804         (bmalloc::Object::chunk):
2805         * bmalloc/ObjectType.cpp:
2806         * bmalloc/Sizes.h:
2807         * bmalloc/SmallAllocator.h: Removed.
2808         * bmalloc/VMHeap.cpp:
2809         (bmalloc::VMHeap::VMHeap):
2810         (bmalloc::VMHeap::allocateChunk):
2811         (bmalloc::VMHeap::allocateLargeChunk): Deleted.
2812         * bmalloc/VMHeap.h:
2813         (bmalloc::VMHeap::allocateLargeObject):
2814         (bmalloc::VMHeap::deallocateLargeObject):
2815         * bmalloc/Zone.cpp:
2816         (bmalloc::enumerator):
2817         * bmalloc/Zone.h:
2818         (bmalloc::Zone::chunks):
2819         (bmalloc::Zone::addChunk):
2820         (bmalloc::Zone::largeChunks): Deleted.
2821         (bmalloc::Zone::addLargeChunk): Deleted.
2822
2823 2016-03-24  Geoffrey Garen  <ggaren@apple.com>
2824
2825         bmalloc: small and large objects should share memory
2826         https://bugs.webkit.org/show_bug.cgi?id=155866
2827
2828         Reviewed by Andreas Kling.
2829
2830         This patch cuts our VM footprint in half. (VM footprint usually doesn't
2831         matter, but on iOS there's an artificial VM limit around 700MB, and if
2832         you hit it you jetsam / crash.)
2833
2834         It's also a step toward honoring the hardware page size at runtime,
2835         which will reduce memory usage on iOS.
2836
2837         This patch is a small improvement in peak memory usage because it allows
2838         small and large objects to recycle each other's memory. The tradeoff is
2839         that we require more metadata, which causes more memory usage after
2840         shrinking down from peak memory usage. In the end, we have some memory
2841         wins and some losses, and a small win in the mean on our standard memory
2842         benchmarks.
2843
2844         * bmalloc.xcodeproj/project.pbxproj: Removed SuperChunk.
2845
2846         * bmalloc/Allocator.cpp:
2847         (bmalloc::Allocator::reallocate): Adopt a new Heap API for shrinking
2848         large objects because it's a little more complicated than it used to be.
2849
2850         Don't check for equality in the XLarge case because we don't do it in
2851         other cases, and it's unlikely that we'll be called for no reason.
2852
2853         * bmalloc/BumpAllocator.h:
2854         (bmalloc::BumpAllocator::allocate): Don't ASSERT isSmall because that's
2855         an old concept from when small and large objects were in distinct memory
2856         regions.
2857
2858         * bmalloc/Deallocator.cpp:
2859         (bmalloc::Deallocator::deallocateSlowCase): Large objects are not
2860         segregated anymore.
2861
2862         (bmalloc::Deallocator::deallocateLarge): Deleted.
2863
2864         * bmalloc/Deallocator.h:
2865         (bmalloc::Deallocator::deallocateFastCase): Don't ASSERT isSmall(). See
2866         above.
2867
2868         * bmalloc/Heap.cpp:
2869         (bmalloc::Heap::scavenge):
2870         (bmalloc::Heap::scavengeSmallPage):
2871         (bmalloc::Heap::scavengeSmallPages): New helpers for returning cached
2872         small pages to the large object heap.
2873
2874         (bmalloc::Heap::allocateSmallPage): Allocate small pages from the large
2875         object heap. This is how we accomplish sharing.
2876
2877         (bmalloc::Heap::deallocateSmallLine): Handle large objects since we can
2878         encounter them on this code path now.
2879
2880         (bmalloc::Heap::splitAndAllocate): Fixed a bug where we would sometimes
2881         not split even though we could.
2882
2883         Allocating a large object also requires ref'ing its small line so that
2884         we can alias memory between small and large objects.
2885
2886         (bmalloc::Heap::allocateLarge): Return cached small pages before
2887         allocating a large object that would fit in a cached small page. This
2888         allows some large allocations to reuse small object memory.
2889
2890         (bmalloc::Heap::shrinkLarge): New helper.
2891
2892         (bmalloc::Heap::deallocateLarge): Deleted.
2893
2894         * bmalloc/Heap.h:
2895
2896         * bmalloc/LargeChunk.h:
2897         (bmalloc::LargeChunk::pageBegin):
2898         (bmalloc::LargeChunk::pageEnd):
2899         (bmalloc::LargeChunk::lines):
2900         (bmalloc::LargeChunk::pages):
2901         (bmalloc::LargeChunk::begin):
2902         (bmalloc::LargeChunk::end):
2903         (bmalloc::LargeChunk::LargeChunk):
2904         (bmalloc::LargeChunk::get):
2905         (bmalloc::LargeChunk::endTag):
2906         (bmalloc::LargeChunk::offset):
2907         (bmalloc::LargeChunk::object):
2908         (bmalloc::LargeChunk::page):
2909         (bmalloc::LargeChunk::line):
2910         (bmalloc::SmallLine::begin):
2911         (bmalloc::SmallLine::end):
2912         (bmalloc::SmallPage::begin):
2913         (bmalloc::SmallPage::end):
2914         (bmalloc::Object::Object):
2915         (bmalloc::Object::begin):
2916         (bmalloc::Object::pageBegin):
2917         (bmalloc::Object::line):
2918         (bmalloc::Object::page): I merged all the SmallChunk metadata and code
2919         into LargeChunk. Now we use a single class to track both small and large
2920         metadata, so we can share memory between small and large objects.
2921
2922         I'm going to rename this class to Chunk in a follow-up patch.
2923
2924         * bmalloc/Object.h:
2925         (bmalloc::Object::chunk): Updated for LargeChunk transition.
2926
2927         * bmalloc/ObjectType.cpp:
2928         (bmalloc::objectType):
2929         * bmalloc/ObjectType.h:
2930         (bmalloc::isXLarge):
2931         (bmalloc::isSmall): Deleted. The difference between small and large
2932         objects is now stored in metadata and is not a property of their
2933         virtual address range.
2934
2935         * bmalloc/SegregatedFreeList.h: One more entry because we cover all of
2936         what used to be the super chunk in a large chunk now.
2937
2938         * bmalloc/Sizes.h: Removed bit masking helpers because we don't use
2939         address masks to distinguish small vs large object type anymore.
2940
2941         * bmalloc/SmallChunk.h: Removed.
2942
2943         * bmalloc/SmallPage.h:
2944         (bmalloc::SmallPage::SmallPage): Store object type per page because any
2945         given page can be used for large objects or small objects.
2946
2947         * bmalloc/SuperChunk.h: Removed.
2948
2949         * bmalloc/VMHeap.cpp:
2950         (bmalloc::VMHeap::VMHeap):
2951         (bmalloc::VMHeap::allocateLargeChunk):
2952         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
2953         (bmalloc::VMHeap::allocateSuperChunk): Deleted.
2954         * bmalloc/VMHeap.h:
2955         (bmalloc::VMHeap::allocateLargeObject):
2956         (bmalloc::VMHeap::deallocateLargeObject):
2957         (bmalloc::VMHeap::allocateSmallPage): Deleted.
2958         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Removed super chunk and
2959         small chunk support.
2960
2961         * bmalloc/Zone.cpp:
2962         (bmalloc::enumerator):
2963         * bmalloc/Zone.h:
2964         (bmalloc::Zone::largeChunks):
2965         (bmalloc::Zone::addLargeChunk):
2966         (bmalloc::Zone::superChunks): Deleted.
2967         (bmalloc::Zone::addSuperChunk): Deleted. Removed super chunk and
2968         small chunk support.
2969
2970 2016-03-23  Geoffrey Garen  <ggaren@apple.com>
2971
2972         bmalloc: Added an Object helper class
2973         https://bugs.webkit.org/show_bug.cgi?id=155818
2974
2975         Reviewed by Gavin Barraclough.
2976
2977         Object is an abstraction that breaks out a void* into its component
2978         metadata pointers.
2979
2980         This is slightly faster than recomputing them, and it enables a future
2981         patch in which Object will tell us whether it is small or large.
2982
2983         * bmalloc.xcodeproj/project.pbxproj: Added to the project.
2984
2985         * bmalloc/Allocator.cpp:
2986         (bmalloc::Allocator::reallocate): Use Object to compute size.
2987
2988         * bmalloc/Deallocator.cpp:
2989         (bmalloc::Deallocator::processObjectLog):
2990         * bmalloc/Heap.cpp:
2991         (bmalloc::Heap::allocateSmallPage):
2992         (bmalloc::Heap::deallocateSmallLine):
2993         * bmalloc/Heap.h:
2994         (bmalloc::Heap::derefSmallLine): Use Object to deallocate.
2995
2996         * bmalloc/Object.h: Added.
2997         (bmalloc::Object::Object):
2998         (bmalloc::Object::chunk):
2999         (bmalloc::Object::line):
3000         (bmalloc::Object::page): Helper class to break out a void* into its
3001         component metadata pointers.
3002
3003         * bmalloc/SmallChunk.h:
3004         (bmalloc::SmallChunk::SmallChunk): SmallPage::get doesn't exist anymore
3005         so we use our new helper functions instead.
3006
3007         (bmalloc::SmallChunk::offset):
3008         (bmalloc::SmallChunk::object):
3009         (bmalloc::SmallChunk::page):
3010         (bmalloc::SmallChunk::line):
3011         (bmalloc::SmallLine::begin):
3012         (bmalloc::SmallLine::end):
3013         (bmalloc::SmallPage::begin): New helpers that operate on the data
3014         stored in Object.
3015
3016         (bmalloc::SmallLine::get): Deleted.
3017         (bmalloc::SmallPage::get): Deleted.
3018
3019         * bmalloc/SmallLine.h:
3020         (bmalloc::SmallLine::refCount): Added a default ref value for convenience.
3021
3022         * bmalloc/SmallPage.h:
3023         (bmalloc::SmallPage::SmallPage):
3024
3025 2016-03-23  Geoffrey Garen  <ggaren@apple.com>
3026
3027         bmalloc: process the object log before asking for new memory
3028         https://bugs.webkit.org/show_bug.cgi?id=155801
3029
3030         Reviewed by Gavin Barraclough.
3031
3032         This is a step toward merging large and small objects: In future, if we
3033         have large objects in the log, we need to process them right away to
3034         avoid pushing up peak memory use.
3035
3036         But it also appears to be a speedup and memory use improvement now.
3037
3038         * bmalloc/Allocator.cpp:
3039         (bmalloc::Allocator::allocate):
3040         (bmalloc::Allocator::refillAllocatorSlowCase):
3041         (bmalloc::Allocator::allocateLarge): Process the log before asking for
3042         more memory.
3043
3044         * bmalloc/Deallocator.cpp:
3045         (bmalloc::Deallocator::processObjectLog):
3046         (bmalloc::Deallocator::deallocateSlowCase):
3047         * bmalloc/Deallocator.h: Provide a public API for processing the object log.
3048
3049         * bmalloc/Heap.cpp:
3050         (bmalloc::Heap::allocateSmallPage): Pop fragmented pages from the front
3051         instead of from the back. This resolves a regression on tree_churn
3052         --parallel. Popping from the front gives us the oldest pages. The oldest
3053         pages have had the most time to accumulate free lines. They are therefore
3054         the least fragmented on average.
3055
3056         * bmalloc/List.h:
3057         (bmalloc::List::popFront):
3058         (bmalloc::List::insertAfter): New API to pop from front.
3059
3060 2016-03-22  Geoffrey Garen  <ggaren@apple.com>
3061
3062         bmalloc: use a log scale for large-ish size classes
3063         https://bugs.webkit.org/show_bug.cgi?id=155770
3064
3065         Reviewed by Michael Saboff.
3066
3067         At larger sizes, precise allocation sizes don't save much memory -- and
3068         they can cost memory when objects of distinct size classes can't
3069         allocate together.
3070
3071         This is a small savings up to our current allocation limits, and it may
3072         enable changing those limits in the long term.
3073
3074         * bmalloc/Algorithm.h:
3075         (bmalloc::log2): We use this to compute large-ish size classes.
3076
3077         * bmalloc/Allocator.cpp:
3078         (bmalloc::Allocator::Allocator): Iterate by size class instead of by
3079         object size so we can change object size limits without breaking stuff.
3080
3081         (bmalloc::Allocator::scavenge): Ditto.
3082
3083         (bmalloc::Allocator::allocateLogSizeClass): New helper function for
3084         allocating based on log size classes.
3085
3086         (bmalloc::Allocator::allocateSlowCase): Account for extra size class
3087         possibilities.
3088
3089         * bmalloc/Allocator.h:
3090         (bmalloc::Allocator::allocateFastCase): We only handle up to 512b on
3091         the fastest fast path now.
3092
3093         * bmalloc/BumpAllocator.h:
3094         (bmalloc::BumpAllocator::validate): Deleted. I noticed that this function
3095         had been refactored not to do anything anymore.
3096
3097         * bmalloc/Heap.cpp:
3098         (bmalloc::Heap::initializeLineMetadata): Iterate by size class. (See
3099         Allocator::Allocator.)
3100
3101         * bmalloc/Heap.h: Use the sizeClassCount constant instead of hard coding
3102         things.
3103
3104         * bmalloc/Sizes.h:
3105         (bmalloc::Sizes::maskSizeClass):
3106         (bmalloc::Sizes::maskObjectSize):
3107         (bmalloc::Sizes::logSizeClass):
3108         (bmalloc::Sizes::logObjectSize):
3109         (bmalloc::Sizes::sizeClass):
3110         (bmalloc::Sizes::objectSize): Separate size class calculation between
3111         simple size classes that can be computed with a mask and are 8-byte-precise
3112         and complex size classes that require more math and are less precise.
3113
3114         * bmalloc/SmallLine.h:
3115         (bmalloc::SmallLine::ref):
3116         * bmalloc/SmallPage.h:
3117         (bmalloc::SmallPage::SmallPage):
3118         (bmalloc::SmallPage::ref):
3119         (bmalloc::SmallPage::deref): Cleaned up some ASSERTs that triggered
3120         while working on this patch.
3121
3122         * bmalloc/Zone.cpp:
3123         (bmalloc::statistics):
3124         (bmalloc::zoneSize):
3125         (bmalloc::Zone::Zone):
3126         (bmalloc::size): Deleted. Renamed these symbols to work around an lldb
3127         bug that makes it impossible to print out variables named 'size' -- which
3128         can be a problem when working on malloc.
3129
3130 2016-03-22  Geoffrey Garen  <ggaren@apple.com>
3131
3132         bmalloc: shrink largeMax
3133         https://bugs.webkit.org/show_bug.cgi?id=155759
3134
3135         Reviewed by Michael Saboff.
3136
3137         If a largeChunk contains N bytes and we allocate objects of size
3138         N / 2 + 8 bytes, then we waste 50% of physical memory at peak.
3139
3140         This patch sets largeMax to N / 2, reducing maximum waste to 25%.
3141
3142         * bmalloc/BoundaryTag.h:
3143         * bmalloc/LargeChunk.h:
3144         (bmalloc::LargeChunk::LargeChunk):
3145         * bmalloc/SegregatedFreeList.cpp:
3146         (bmalloc::SegregatedFreeList::SegregatedFreeList):
3147         (bmalloc::SegregatedFreeList::insert): Honor largeMax vs largeObjectMax.
3148
3149         * bmalloc/Sizes.h: Distinguish between the largest thing we can store
3150         in a free list (largeObjectMax) and the largest thing we're willing to
3151         allocate (largeMax).
3152
3153 2016-03-20  Dan Bernstein  <mitz@apple.com>
3154
3155         [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
3156         https://bugs.webkit.org/show_bug.cgi?id=155707
3157         <rdar://problem/24980691>
3158
3159         Reviewed by Darin Adler.
3160
3161         * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
3162           component of MACOSX_DEPLOYMENT_TARGET.
3163         * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
3164           TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.
3165
3166 2016-03-20  Dan Bernstein  <mitz@apple.com>
3167
3168         Update build settings
3169
3170         Rubber-stamped by Andy Estes.
3171
3172         * Configurations/DebugRelease.xcconfig:
3173
3174 2016-03-14  Geoffrey Garen  <ggaren@apple.com>
3175
3176         Unreviewed, rolling out r197955.
3177
3178         I decided to go in another direction
3179
3180         Reverted changeset:
3181
3182         "bmalloc: Rename SmallPage to SmallRun"
3183         https://bugs.webkit.org/show_bug.cgi?id=155320
3184         http://trac.webkit.org/changeset/197955
3185
3186 2016-03-10  Geoffrey Garen  <ggaren@apple.com>
3187
3188         bmalloc: Rename SmallPage to SmallRun
3189         https://bugs.webkit.org/show_bug.cgi?id=155320
3190
3191         Reviewed by Alex Christensen.
3192
3193         A page is a fixed-size set of lines.
3194
3195         A run is an variable-sized set of lines.
3196
3197         We want to start using runs because:
3198
3199             (a) we want to support varying the hardware page size by OS;
3200
3201             (b) we want to support allocations larger than our current page size.
3202
3203         * bmalloc.xcodeproj/project.pbxproj:
3204         * bmalloc/Allocator.cpp:
3205         (bmalloc::Allocator::reallocate):
3206         * bmalloc/Heap.cpp:
3207         (bmalloc::Heap::Heap):
3208         (bmalloc::Heap::initializeSmallRunMetadata):
3209         (bmalloc::Heap::scavenge):
3210         (bmalloc::Heap::scavengeSmallRuns):
3211         (bmalloc::Heap::allocateSmallBumpRanges):
3212         (bmalloc::Heap::allocateSmallRun):
3213         (bmalloc::Heap::deallocateSmallLine):
3214         (bmalloc::Heap::initializeLineMetadata): Deleted.
3215         (bmalloc::Heap::scavengeSmallPages): Deleted.
3216         (bmalloc::Heap::allocateSmallPage): Deleted.
3217         * bmalloc/Heap.h:
3218         * bmalloc/LineMetadata.h:
3219         * bmalloc/SmallChunk.h:
3220         (bmalloc::SmallChunk::begin):
3221         (bmalloc::SmallChunk::end):
3222         (bmalloc::SmallChunk::lines):
3223         (bmalloc::SmallChunk::runs):
3224         (bmalloc::SmallChunk::SmallChunk):
3225         (bmalloc::SmallLine::end):
3226         (bmalloc::SmallRun::get):
3227         (bmalloc::SmallRun::begin):
3228         (bmalloc::SmallRun::end):
3229         (bmalloc::SmallChunk::pages): Deleted.
3230         (bmalloc::SmallPage::get): Deleted.
3231         (bmalloc::SmallPage::begin): Deleted.
3232         (bmalloc::SmallPage::end): Deleted.
3233         * bmalloc/SmallPage.h: Removed.
3234         * bmalloc/SmallRun.h: Copied from Source/bmalloc/bmalloc/SmallPage.h.
3235         (bmalloc::SmallRun::SmallRun):
3236         (bmalloc::SmallRun::ref):
3237         (bmalloc::SmallRun::deref):
3238         (bmalloc::SmallPage::SmallPage): Deleted.
3239         (bmalloc::SmallPage::ref): Deleted.
3240         (bmalloc::SmallPage::deref): Deleted.
3241         * bmalloc/VMHeap.cpp:
3242         (bmalloc::VMHeap::allocateSmallChunk):
3243         (bmalloc::VMHeap::allocateLargeChunk):
3244         * bmalloc/VMHeap.h:
3245         (bmalloc::VMHeap::allocateSmallRun):
3246         (bmalloc::VMHeap::allocateLargeObject):
3247         (bmalloc::VMHeap::deallocateSmallRun):
3248         (bmalloc::VMHeap::deallocateLargeObject):
3249         (bmalloc::VMHeap::allocateSmallPage): Deleted.
3250         (bmalloc::VMHeap::deallocateSmallPage): Deleted.
3251
3252 2016-03-08  Geoffrey Garen  <ggaren@apple.com>
3253
3254         Unreviewed, rolling in r197722.
3255         https://bugs.webkit.org/show_bug.cgi?id=155171
3256
3257         The right calculation for our static_assert is actually:
3258
3259             sizeof(SmallChunk) % vmPageSize + 2 * smallMax <= vmPageSize
3260
3261         instead of:
3262
3263             sizeof(SmallChunk) % vmPageSize + smallMax <= vmPageSize
3264
3265         smallMax is not enough because line metadata might require us to begin
3266         allocation at an offset as large as smallMax, so we need 2 * smallMax.
3267
3268         Once correct, this static_assert fires, and we fix it by increasing
3269         the alignment of SmallChunk.
3270
3271         Restored changeset:
3272
3273         "bmalloc: Use List<T> instead of Vector<T> in some places"
3274         https://bugs.webkit.org/show_bug.cgi?id=155150
3275         http://trac.webkit.org/changeset/197722
3276
3277 2016-03-08  Commit Queue  <commit-queue@webkit.org>
3278
3279         Unreviewed, rolling out r197722.
3280         https://bugs.webkit.org/show_bug.cgi?id=155171
3281
3282         This change caused 800+ JSC test failures (Requested by
3283         ryanhaddad on #webkit).
3284
3285         Reverted changeset:
3286
3287         "bmalloc: Use List<T> instead of Vector<T> in some places"
3288         https://bugs.webkit.org/show_bug.cgi?id=155150
3289         http://trac.webkit.org/changeset/197722
3290
3291 2016-03-07  Geoffrey Garen  <ggaren@apple.com>
3292
3293         bmalloc: Use List<T> instead of Vector<T> in some places
3294         https://bugs.webkit.org/show_bug.cgi?id=155150
3295
3296         Reviewed by Andreas Kling.
3297
3298         Vector<T> is expensive when you want a lot of them because our minimum
3299         allocation size is the system page size.
3300
3301         * bmalloc.xcodeproj/project.pbxproj: Added a List<T> class.
3302
3303         * bmalloc/Heap.cpp:
3304         (bmalloc::Heap::scavengeSmallPages):
3305         (bmalloc::Heap::allocateSmallPage): Use the List<T> API. No need to check
3306         for stale entries anymore because List<T> supports O(1) eager removal
3307         and we remove eagerly now.
3308
3309         (bmalloc::Heap::deallocateSmallLine): Remove eagerly. This simplifies
3310         the allocation code and it is also required for correctness since we
3311         only have enough metadata to be in one list at a time.
3312
3313         * bmalloc/Heap.h: List!
3314
3315         * bmalloc/SmallChunk.h: Made this assert a little more precise since this
3316         patch triggered the old version in a benign way.
3317
3318         (bmalloc::SmallChunk::SmallChunk): This code moved to the SmallPage
3319         constructor.
3320
3321         * bmalloc/SmallPage.h:
3322         (bmalloc::SmallPage::SmallPage): Accomodate the List<T> data structure.
3323         This is a net memory savings on Mac for heaps smaller than ~128MB and on
3324         iOS for heaps smaller than ~512MB. The maximum memory saved is 512kB on
3325         Mac and 2MB on iOS. For larger heaps, there's a memory cost of 0.4% on
3326         Mac and 0.1% on iOS.
3327
3328         * bmalloc/VMHeap.h:
3329         (bmalloc::VMHeap::allocateSmallPage): Use List<T> API.
3330
3331 2016-03-03  Geoffrey Garen  <ggaren@apple.com>
3332
3333         Unreviewed, rolling in r197174.
3334         https://bugs.webkit.org/show_bug.cgi?id=154762
3335
3336         The right calculation for alignment is actually:
3337
3338             vmAlignment - getpagesize() + vmSize
3339
3340         instead of:
3341
3342             vmAlignment - vmPageSize + vmSize
3343
3344         The vmPageSize might be larger than getpagesize().
3345
3346         Restored changeset:
3347
3348         "bmalloc: Added a fast XLarge allocator"
3349         https://bugs.webkit.org/show_bug.cgi?id=154720
3350         http://trac.webkit.org/changeset/197174
3351
3352 2016-02-26  Commit Queue  <commit-queue@webkit.org>
3353
3354         Unreviewed, rolling out r197174.
3355         https://bugs.webkit.org/show_bug.cgi?id=154762
3356
3357         This change caused LayoutTests to crash on iOS simulator
3358         (Requested by ryanhaddad on #webkit).
3359
3360         Reverted changeset:
3361
3362         "bmalloc: Added a fast XLarge allocator"
3363         https://bugs.webkit.org/show_bug.cgi?id=154720
3364         http://trac.webkit.org/changeset/197174
3365
3366 2016-02-25  Geoffrey Garen  <ggaren@apple.com>
3367
3368         bmalloc: Added a fast XLarge allocator
3369         https://bugs.webkit.org/show_bug.cgi?id=154720
3370
3371         Reviewed by Andreas Kling.
3372
3373         This is a big speedup for XLarge allocations because it avoids mmap
3374         and page fault churn. It also enables future design changes to handle
3375         a smaller size range on the fast path.
3376
3377         * bmalloc.xcodeproj/project.pbxproj:
3378
3379         * bmalloc/Algorithm.h:
3380         (bmalloc::roundUpToMultipleOf):
3381         (bmalloc::roundDownToMultipleOf): Added a non-constant round down.
3382
3383         * bmalloc/Allocator.cpp:
3384         (bmalloc::Allocator::tryAllocate): XLarge no longer requires the caller
3385         to align things.
3386
3387         (bmalloc::Allocator::allocate): Tweaked the alignment calculation for
3388         clarity. When alignment and largeAlignment are equal, no adjustment
3389         is necessary since all allocations guarantee largeAlignment.
3390
3391         (bmalloc::Allocator::reallocate): Updated for interface change.
3392
3393         Note that the new interface fixes some concurrency bugs. The old code
3394         kept an iterator into the XLarge allocator across lock drop and acquisition,
3395         which is not cool.
3396
3397         (bmalloc::Allocator::allocateXLarge): XLarge no longer requires the caller
3398         to align things.
3399
3400         * bmalloc/Heap.cpp:
3401         (bmalloc::Heap::scavengeXLargeObjects): Added scavenging for XLarge.
3402
3403         (bmalloc::Heap::allocateXLarge):
3404
3405         (bmalloc::Heap::splitAndAllocate): Split XLarge objects to xLargeAlignment.
3406
3407         (bmalloc::Heap::tryAllocateXLarge):
3408         (bmalloc::Heap::xLargeSize):
3409         (bmalloc::Heap::shrinkXLarge):
3410         (bmalloc::Heap::deallocateXLarge): Allocate from our map before going
3411         to the OS.
3412
3413         (bmalloc::Heap::findXLarge): Deleted.
3414
3415         * bmalloc/Heap.h:
3416
3417         * bmalloc/LargeObject.h:
3418         (bmalloc::LargeObject::split):
3419
3420         * bmalloc/ObjectType.h:
3421         (bmalloc::isXLarge): Give XLarge objects an explicit alignment for clarity.
3422
3423         * bmalloc/Range.h:
3424         (bmalloc::Range::size):
3425         (bmalloc::Range::operator!):
3426         (bmalloc::Range::operator bool):
3427         (bmalloc::Range::operator<):
3428         (bmalloc::canMerge):
3429         (bmalloc::merge): Some helpers that were useful in writing this patch.
3430
3431         * bmalloc/Sizes.h:
3432