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