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