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