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