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