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