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