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