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