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