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