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