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