[Cocoa] Turn on ARC for the single Objective-C++ source file in bmalloc
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2018-06-07  Darin Adler  <darin@apple.com>
2
3         [Cocoa] Turn on ARC for the single Objective-C++ source file in bmalloc
4         https://bugs.webkit.org/show_bug.cgi?id=186398
5
6         Reviewed by Saam Barati.
7
8         * Configurations/Base.xcconfig: Turn on ARC.
9         * bmalloc/ProcessCheck.mm:
10         (bmalloc::gigacageEnabledForProcess): Removed the globals from this function,
11         since it's only called once. If it was called more than once, we could optimize
12         that with a single boolean global rather than two strings and two booleans.
13
14 2018-06-07  David Kilzer  <ddkilzer@apple.com>
15
16         bmalloc: Fix 'noreturn' warnings when compiling with -std=gnu++17
17         <https://webkit.org/b/186400>
18
19         Reviewed by Saam Barati.
20
21         Fixes the following warnings when compiling with gnu++17:
22
23             Source/bmalloc/bmalloc/Scavenger.cpp:363:1: error: function 'threadRunLoop' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
24             {
25             ^
26             Source/bmalloc/bmalloc/Scavenger.cpp:358:1: error: function 'threadEntryPoint' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
27             {
28             ^
29
30         * bmalloc/BCompiler.h:
31         (BCOMPILER): Add support for the BCOMPILER() macro, then add
32         BCOMPILER(GCC_OR_CLANG).  Taken from Source/WTF/wtf/Compiler.h.
33         (BNO_RETURN): Implement 'norerturn' support using the new
34         BCOMPILER() macros.  Taken from Source/WTF/wtf/Compiler.h.
35         * bmalloc/Scavenger.cpp:
36         (bmalloc::Scavenger::threadRunLoop): Remove the workaround that
37         tricked older compilers into thinking the while() loop wasn't
38         infinite.
39         * bmalloc/Scavenger.h:
40         (bmalloc::Scavenger::threadEntryPoint): Add BNO_RETURN attribute.
41         (bmalloc::Scavenger::threadRunLoop): Ditto.
42
43 2018-05-29  Saam Barati  <sbarati@apple.com>
44
45         JSC should put bmalloc's scavenger into mini mode
46         https://bugs.webkit.org/show_bug.cgi?id=185988
47
48         Reviewed by Michael Saboff.
49
50         We expose an API for putting bmalloc into mini mode. All that means now
51         is that we'll run the scavenger more aggressively.
52
53         * bmalloc/Scavenger.cpp:
54         (bmalloc::Scavenger::enableMiniMode):
55         (bmalloc::Scavenger::threadRunLoop):
56         * bmalloc/Scavenger.h:
57         * bmalloc/Sizes.h:
58         * bmalloc/bmalloc.cpp:
59         (bmalloc::api::enableMiniMode):
60         * bmalloc/bmalloc.h:
61
62 2018-05-29  Geoffrey Garen  <ggaren@apple.com>
63
64         Fixed the bmalloc build
65         https://bugs.webkit.org/show_bug.cgi?id=186025
66
67         Reviewed by Sam Weinig.
68
69         * bmalloc.xcodeproj/project.pbxproj: Link Foundation because the 
70         gigacage check needs it.
71
72 2018-05-23  Antti Koivisto  <antti@apple.com>
73
74         Increase the simulated memory size on PLATFORM(IOS_SIMULATOR) from 512MB to 1024MB
75         https://bugs.webkit.org/show_bug.cgi?id=185908
76
77         Reviewed by Geoffrey Garen.
78
79         We don't support 512MB devices anymore. This will make the simulator behave more
80         like a real device.
81
82         * bmalloc/AvailableMemory.cpp:
83         (bmalloc::memorySizeAccordingToKernel):
84
85         Factor to a function.
86         Don't use availableMemoryGuess for the simulator value as it is not a guess.
87
88         (bmalloc::computeAvailableMemory):
89
90         Apply the same adjustments to the simulated value too.
91
92 2018-05-22  Ryan Haddad  <ryanhaddad@apple.com>
93
94         Unreviewed, rolling out r232052.
95
96         Breaks internal builds.
97
98         Reverted changeset:
99
100         "Use more C++17"
101         https://bugs.webkit.org/show_bug.cgi?id=185176
102         https://trac.webkit.org/changeset/232052
103
104 2018-05-22  Yusuke Suzuki  <utatane.tea@gmail.com>
105
106         Define GIGACAGE_ALLOCATION_CAN_FAIL on Linux
107         https://bugs.webkit.org/show_bug.cgi?id=183329
108
109         Reviewed by Michael Catanzaro.
110
111         We specify `GIGACAGE_ALLOCATION_CAN_FAIL 1` in Linux since
112         Linux can fail to `mmap` if `vm.overcommit_memory = 2`.
113         Users can enable Gigacage if users enable overcommit_memory.
114
115         * bmalloc/Gigacage.h:
116
117 2018-05-21  Yusuke Suzuki  <utatane.tea@gmail.com>
118
119         Use more C++17
120         https://bugs.webkit.org/show_bug.cgi?id=185176
121
122         Reviewed by JF Bastien.
123
124         Add BNO_RETURN.
125
126         * Configurations/Base.xcconfig:
127         * bmalloc/BCompiler.h:
128         * bmalloc/Scavenger.h:
129
130 2018-05-06  Yusuke Suzuki  <utatane.tea@gmail.com>
131
132         [JSC] Remove "using namespace std;" from JSC, bmalloc, WTF
133         https://bugs.webkit.org/show_bug.cgi?id=185362
134
135         Reviewed by Sam Weinig.
136
137         * bmalloc/Allocator.cpp:
138         * bmalloc/Deallocator.cpp:
139
140 2018-05-03  Filip Pizlo  <fpizlo@apple.com>
141
142         Strings should not be allocated in a gigacage
143         https://bugs.webkit.org/show_bug.cgi?id=185218
144
145         Reviewed by Saam Barati.
146         
147         This removes the string gigacage.
148         
149         Putting strings in a gigacage prevents read gadgets. The other things that get to be in gigacages
150         are there to prevent read-write gadgets.
151         
152         Also, putting strings in a gigacage seems to have been a bigger regression than putting other
153         things in gigacages.
154         
155         Therefore, to maximize the benefit/cost ratio of gigacages, we should evict strings from them. If
156         we want to throw away perf for security, there are more beneficial things to sacrifice.
157
158         * bmalloc/Gigacage.h:
159         (Gigacage::name):
160         (Gigacage::basePtr):
161         (Gigacage::size):
162         (Gigacage::forEachKind):
163         * bmalloc/HeapKind.h:
164         (bmalloc::isGigacage):
165         (bmalloc::gigacageKind):
166         (bmalloc::heapKind):
167         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
168         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
169
170 2018-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
171
172         Use WordLock instead of std::mutex for Threading
173         https://bugs.webkit.org/show_bug.cgi?id=185121
174
175         Reviewed by Geoffrey Garen.
176
177         Add constexpr to explicitly describe that bmalloc::Mutex constructor is constexpr.
178
179         * bmalloc/Mutex.h:
180
181 2018-04-23  Ting-Wei Lan  <lantw44@gmail.com>
182
183         Include stdio.h before using stderr
184         https://bugs.webkit.org/show_bug.cgi?id=184872
185
186         Reviewed by Yusuke Suzuki.
187
188         * bmalloc/PerProcess.cpp:
189         * bmalloc/Scavenger.cpp:
190
191 2018-04-21  Yusuke Suzuki  <utatane.tea@gmail.com>
192
193         Unreviewed, follow-up patch after r230474
194         https://bugs.webkit.org/show_bug.cgi?id=166684
195
196         Add "JavaScriptCore" to Darwin name. And use short name "BMScavenger"
197         for Linux since adding "JavaScriptCore" makes the name too long for Linux.
198
199         * bmalloc/Scavenger.cpp:
200         (bmalloc::Scavenger::threadRunLoop):
201
202 2018-04-18  Jer Noble  <jer.noble@apple.com>
203
204         Don't put build products into WK_ALTERNATE_WEBKIT_SDK_PATH for engineering builds
205         https://bugs.webkit.org/show_bug.cgi?id=184762
206
207         Reviewed by Dan Bernstein.
208
209         * Configurations/Base.xcconfig:
210
211 2018-04-20  Daniel Bates  <dabates@apple.com>
212
213         Remove code for compilers that did not support NSDMI for aggregates
214         https://bugs.webkit.org/show_bug.cgi?id=184599
215
216         Reviewed by Per Arne Vollan.
217
218         Remove workaround for earlier Visual Studio versions that did not support non-static data
219         member initializers (NSDMI) for aggregates. We have since updated all the build.webkit.org
220         and EWS bots to a newer version that supports this feature.
221
222         * bmalloc/BPlatform.h:
223         * bmalloc/List.h:
224         (bmalloc::ListNode::ListNode): Deleted.
225         (bmalloc::List::iterator::iterator): Deleted.
226
227 2018-04-19  David Kilzer  <ddkilzer@apple.com>
228
229         Enable Objective-C weak references
230         <https://webkit.org/b/184789>
231         <rdar://problem/39571716>
232
233         Reviewed by Dan Bernstein.
234
235         * Configurations/Base.xcconfig:
236         (CLANG_ENABLE_OBJC_WEAK): Enable.
237
238 2018-04-12  Saam Barati  <sbarati@apple.com>
239
240         Lessen partial scavenge interval on x86-64
241         https://bugs.webkit.org/show_bug.cgi?id=184577
242
243         Rubber-stamped by Filip Pizlo.
244
245         I initially made the scavenge interval longer because I had thought the
246         shorter interval caused a JetStream regression. I was mistaken though.
247         I was looking at the wrong commit range when analyzing perf data.
248         
249         This patch shortens the interval, but still keeps x86-64 50% longer than
250         other architectures. We know that scavenging frequently on Mac is less
251         important to overall system performance than it is on iOS.
252
253         * bmalloc/Scavenger.cpp:
254         (bmalloc::Scavenger::threadRunLoop):
255
256 2018-04-12  Saam Barati  <sbarati@apple.com>
257
258         Raise the partial scavenge interval even more on x86-64
259         https://bugs.webkit.org/show_bug.cgi?id=184551
260
261         Rubber-stamped by Filip Pizlo.
262
263         The JetStream regression didn't recover from my previous patch.
264         This is another attempt to get it to recover perf.
265
266         * bmalloc/Scavenger.cpp:
267         (bmalloc::Scavenger::threadRunLoop):
268
269 2018-04-11  Saam Barati  <sbarati@apple.com>
270
271         raise partial scavenge interval on x86-64
272         https://bugs.webkit.org/show_bug.cgi?id=184521
273
274         Rubber-stamped by Filip Pizlo.
275
276         This patch is an attempt to recover the 1-3% JetStream regression
277         my initial partial scavenging patch introduced on some Macs.
278
279         * bmalloc/Scavenger.cpp:
280         (bmalloc::Scavenger::threadRunLoop):
281
282 2018-04-10  Saam Barati  <sbarati@apple.com>
283
284         IsoHeapImpl::scavenge* needs to grab the lock
285         https://bugs.webkit.org/show_bug.cgi?id=184461
286
287         Reviewed by Filip Pizlo.
288
289         Another thread could be modifying the linked list that the scavenge* methods traverse.
290
291         * bmalloc/IsoHeapImplInlines.h:
292         (bmalloc::IsoHeapImpl<Config>::scavenge):
293         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
294
295 2018-04-10  Saam Barati  <sbarati@apple.com>
296
297         bmalloc should do partial scavenges more frequently
298         https://bugs.webkit.org/show_bug.cgi?id=184176
299
300         Reviewed by Filip Pizlo.
301
302         This patch adds the ability for bmalloc to do a partial scavenge.
303         bmalloc will now do a partial scavenge with some frequency even
304         when the heap is growing.
305         
306         For Heap, this means tracking the high water mark of where the Heap
307         has allocated since the last scavenge. Partial scavenging is just
308         decommitting entries in the LargeMap that are past this high water
309         mark. Because we allocate in first fit order out of LargeMap, tracking
310         the high water mark is a good heuristic of how much memory a partial
311         scavenge should decommit.
312         
313         For IsoHeaps, each IsoDirectory also keeps track of its high water mark
314         for the furthest page it allocates into. Similar to Heap, we scavenge pages
315         past that high water mark. IsoHeapImpl then tracks the high water mark
316         for the IsoDirectory it allocates into. We then scavenge all directories 
317         including and past the directory high water mark. This includes scavenging
318         the inline directory when its the only thing we allocate out of since
319         the last scavenge.
320         
321         This patch also adds some other capabilities to bmalloc:
322         
323         Heaps and IsoHeaps now track how much memory is freeable. Querying
324         this number is now cheap.
325         
326         Heaps no longer hold the global lock when decommitting large ranges.
327         Instead, that range is just marked as non eligible to be allocated.
328         Then, without the lock held, the scavenger will decommit those ranges.
329         Once this is done, the scavenger will then reacquire the lock and mark
330         these ranges as eligible. This lessens lock contention between the
331         scavenger and the allocation slow path since threads that are taking an
332         allocation slow path can now allocate concurrently to the scavenger's
333         decommits. The main consideration in adding this functionality is that
334         a large allocation may fail while the scavenger is in the process of
335         decommitting memory. When the Heap fails to allocate a large range when
336         the scavenger is in the middle of a decommit, Heap will wait for the
337         Scavenger to finish and then it will try to allocate a large range again.
338         
339         Decommitting from Heap now aggregates the ranges to decommit and tries to
340         merge them together to lower the number of calls to vmDeallocatePhysicalPages.
341         This is analogous to what IsoHeaps already do.
342
343         * bmalloc.xcodeproj/project.pbxproj:
344         * bmalloc/Allocator.cpp:
345         (bmalloc::Allocator::tryAllocate):
346         (bmalloc::Allocator::allocateImpl):
347         (bmalloc::Allocator::reallocate):
348         (bmalloc::Allocator::refillAllocatorSlowCase):
349         (bmalloc::Allocator::allocateLarge):
350         * bmalloc/BulkDecommit.h: Added.
351         (bmalloc::BulkDecommit::addEager):
352         (bmalloc::BulkDecommit::addLazy):
353         (bmalloc::BulkDecommit::processEager):
354         (bmalloc::BulkDecommit::processLazy):
355         (bmalloc::BulkDecommit::add):
356         (bmalloc::BulkDecommit::process):
357         * bmalloc/Deallocator.cpp:
358         (bmalloc::Deallocator::scavenge):
359         (bmalloc::Deallocator::processObjectLog):
360         (bmalloc::Deallocator::deallocateSlowCase):
361         * bmalloc/Deallocator.h:
362         (bmalloc::Deallocator::lineCache):
363         * bmalloc/Heap.cpp:
364         (bmalloc::Heap::freeableMemory):
365         (bmalloc::Heap::markAllLargeAsEligibile):
366         (bmalloc::Heap::decommitLargeRange):
367         (bmalloc::Heap::scavenge):
368         (bmalloc::Heap::scavengeToHighWatermark):
369         (bmalloc::Heap::deallocateLineCache):
370         (bmalloc::Heap::allocateSmallChunk):
371         (bmalloc::Heap::deallocateSmallChunk):
372         (bmalloc::Heap::allocateSmallPage):
373         (bmalloc::Heap::deallocateSmallLine):
374         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
375         (bmalloc::Heap::allocateSmallBumpRangesByObject):
376         (bmalloc::Heap::splitAndAllocate):
377         (bmalloc::Heap::tryAllocateLarge):
378         (bmalloc::Heap::allocateLarge):
379         (bmalloc::Heap::isLarge):
380         (bmalloc::Heap::largeSize):
381         (bmalloc::Heap::shrinkLarge):
382         (bmalloc::Heap::deallocateLarge):
383         (bmalloc::Heap::externalCommit):
384         (bmalloc::Heap::externalDecommit):
385         * bmalloc/Heap.h:
386         (bmalloc::Heap::allocateSmallBumpRanges):
387         (bmalloc::Heap::derefSmallLine):
388         * bmalloc/IsoDirectory.h:
389         * bmalloc/IsoDirectoryInlines.h:
390         (bmalloc::passedNumPages>::takeFirstEligible):
391         (bmalloc::passedNumPages>::didBecome):
392         (bmalloc::passedNumPages>::didDecommit):
393         (bmalloc::passedNumPages>::scavengePage):
394         (bmalloc::passedNumPages>::scavenge):
395         (bmalloc::passedNumPages>::scavengeToHighWatermark):
396         (bmalloc::passedNumPages>::freeableMemory): Deleted.
397         * bmalloc/IsoHeapImpl.h:
398         * bmalloc/IsoHeapImplInlines.h:
399         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
400         (bmalloc::IsoHeapImpl<Config>::scavenge):
401         (bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark):
402         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
403         (bmalloc::IsoHeapImpl<Config>::isNowFreeable):
404         (bmalloc::IsoHeapImpl<Config>::isNoLongerFreeable):
405         * bmalloc/LargeMap.cpp:
406         (bmalloc::LargeMap::remove):
407         (bmalloc::LargeMap::markAllAsEligibile):
408         * bmalloc/LargeMap.h:
409         (bmalloc::LargeMap::size):
410         (bmalloc::LargeMap::at):
411         * bmalloc/LargeRange.h:
412         (bmalloc::LargeRange::setEligible):
413         (bmalloc::LargeRange::isEligibile const):
414         (bmalloc::canMerge):
415         * bmalloc/ObjectType.cpp:
416         (bmalloc::objectType):
417         * bmalloc/Scavenger.cpp:
418         (bmalloc::PrintTime::PrintTime):
419         (bmalloc::PrintTime::~PrintTime):
420         (bmalloc::PrintTime::print):
421         (bmalloc::Scavenger::timeSinceLastFullScavenge):
422         (bmalloc::Scavenger::timeSinceLastPartialScavenge):
423         (bmalloc::Scavenger::scavenge):
424         (bmalloc::Scavenger::partialScavenge):
425         (bmalloc::Scavenger::freeableMemory):
426         (bmalloc::Scavenger::threadRunLoop):
427         * bmalloc/Scavenger.h:
428         * bmalloc/SmallLine.h:
429         (bmalloc::SmallLine::refCount):
430         (bmalloc::SmallLine::ref):
431         (bmalloc::SmallLine::deref):
432         * bmalloc/SmallPage.h:
433         (bmalloc::SmallPage::refCount):
434         (bmalloc::SmallPage::hasFreeLines const):
435         (bmalloc::SmallPage::setHasFreeLines):
436         (bmalloc::SmallPage::ref):
437         (bmalloc::SmallPage::deref):
438         * bmalloc/bmalloc.cpp:
439         (bmalloc::api::tryLargeZeroedMemalignVirtual):
440         (bmalloc::api::freeLargeVirtual):
441
442 2018-04-09  Yusuke Suzuki  <utatane.tea@gmail.com>
443
444         [bmalloc] Name Scavenger thread "bmalloc scavenger"
445         https://bugs.webkit.org/show_bug.cgi?id=166684
446
447         Reviewed by Saam Barati.
448
449         We name the thread for bmalloc Scavenger "bmalloc scavenger".
450         It is useful for debugging. In Linux environment, it will be
451         shown in GDB.
452
453         * bmalloc/Scavenger.cpp:
454         (bmalloc::Scavenger::threadRunLoop):
455         (bmalloc::Scavenger::setName):
456         * bmalloc/Scavenger.h:
457
458 2018-04-09  Michael Catanzaro  <mcatanzaro@igalia.com>
459
460         Rename UNUSED to BUNUSED
461         https://bugs.webkit.org/show_bug.cgi?id=184093
462
463         Reviewed by Yusuke Suzuki.
464
465         * bmalloc/BAssert.h:
466         * bmalloc/VMAllocate.h:
467         (bmalloc::vmValidate):
468         (bmalloc::vmValidatePhysical):
469
470 2018-04-08  Yusuke Suzuki  <utatane.tea@gmail.com>
471
472         Use alignas instead of compiler-specific attributes
473         https://bugs.webkit.org/show_bug.cgi?id=183508
474
475         Reviewed by Mark Lam.
476
477         Use alignas for g_gigacageBasePtr. We also add reinterpret_cast to fix
478         compile errors in ARMv7 and MIPS JSCOnly ports.
479
480         * bmalloc/Gigacage.cpp:
481         * bmalloc/Gigacage.h:
482         (Gigacage::basePtrs):
483
484 2018-04-06  Saam Barati  <sbarati@apple.com>
485
486         bmalloc virtual allocation API should not treat memory it vends as dirty with respect to how it drives the scavenger
487         https://bugs.webkit.org/show_bug.cgi?id=184342
488
489         Reviewed by Mark Lam.
490
491         Currently, the only user of this API is Wasm. Ideally, Wasm would tell
492         us exactly which page is dirtied. We should really do that at some point:
493         https://bugs.webkit.org/show_bug.cgi?id=184207
494         
495         However, until we do that, it's better to treat none of the virtual memory
496         we vend as dirty, versus what we do now, which is treat it all as dirty.
497         This dirty memory tracking helps drive the scavenger, so on iOS, having the
498         scavenger think its under memory pressure because of memory it can't free isn't
499         useful.
500
501         * bmalloc/bmalloc.cpp:
502         (bmalloc::api::tryLargeZeroedMemalignVirtual):
503         (bmalloc::api::freeLargeVirtual):
504         * bmalloc/bmalloc.h:
505
506 2018-04-05  Saam Barati  <sbarati@apple.com>
507
508         IsoHeapImpl not IsoHeapImplBase should add itself to AllIsoHeaps
509         https://bugs.webkit.org/show_bug.cgi?id=184174
510
511         Reviewed by Filip Pizlo.
512
513         Otherwise, another thread may see a non-fully formed IsoHeapImpl.
514
515         * bmalloc/IsoHeapImpl.cpp:
516         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
517         (bmalloc::IsoHeapImplBase::addToAllIsoHeaps):
518         * bmalloc/IsoHeapImpl.h:
519         * bmalloc/IsoHeapImplInlines.h:
520         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
521
522 2018-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
523
524         bmalloc StaticMutex's constructor should be constexpr
525         https://bugs.webkit.org/show_bug.cgi?id=180600
526
527         Reviewed by Mark Lam.
528
529         StaticMutex and Mutex can be unified. This patch changes std::atomic_flag in StaticMutex
530         to std::atomic<bool> to add constexpr constructor to StaticMutex. Then, StaticMutex can
531         be initialized in static storage without calling any static initializers.
532         And we also rename StaticMutex to Mutex simply.
533
534         * CMakeLists.txt:
535         * bmalloc.xcodeproj/project.pbxproj:
536         * bmalloc/AllIsoHeaps.cpp:
537         (bmalloc::AllIsoHeaps::AllIsoHeaps):
538         * bmalloc/AllIsoHeaps.h:
539         * bmalloc/Allocator.cpp:
540         (bmalloc::Allocator::tryAllocate):
541         (bmalloc::Allocator::allocateImpl):
542         (bmalloc::Allocator::reallocate):
543         (bmalloc::Allocator::refillAllocatorSlowCase):
544         (bmalloc::Allocator::allocateLarge):
545         * bmalloc/CryptoRandom.cpp:
546         (bmalloc::ARC4RandomNumberGenerator::ARC4RandomNumberGenerator):
547         * bmalloc/Deallocator.cpp:
548         (bmalloc::Deallocator::scavenge):
549         (bmalloc::Deallocator::processObjectLog):
550         (bmalloc::Deallocator::deallocateSlowCase):
551         * bmalloc/Deallocator.h:
552         (bmalloc::Deallocator::lineCache):
553         * bmalloc/DebugHeap.cpp:
554         (bmalloc::DebugHeap::DebugHeap):
555         * bmalloc/DebugHeap.h:
556         * bmalloc/Environment.cpp:
557         (bmalloc::Environment::Environment):
558         * bmalloc/Environment.h:
559         * bmalloc/Gigacage.cpp:
560         (Gigacage::disablePrimitiveGigacage):
561         (Gigacage::addPrimitiveDisableCallback):
562         (Gigacage::removePrimitiveDisableCallback):
563         * bmalloc/Heap.cpp:
564         (bmalloc::Heap::Heap):
565         (bmalloc::Heap::freeableMemory):
566         (bmalloc::Heap::scavenge):
567         (bmalloc::Heap::deallocateLineCache):
568         (bmalloc::Heap::allocateSmallChunk):
569         (bmalloc::Heap::allocateSmallPage):
570         (bmalloc::Heap::deallocateSmallLine):
571         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
572         (bmalloc::Heap::allocateSmallBumpRangesByObject):
573         (bmalloc::Heap::splitAndAllocate):
574         (bmalloc::Heap::tryAllocateLarge):
575         (bmalloc::Heap::allocateLarge):
576         (bmalloc::Heap::isLarge):
577         (bmalloc::Heap::largeSize):
578         (bmalloc::Heap::shrinkLarge):
579         (bmalloc::Heap::deallocateLarge):
580         (bmalloc::Heap::externalCommit):
581         (bmalloc::Heap::externalDecommit):
582         * bmalloc/Heap.h:
583         (bmalloc::Heap::mutex):
584         (bmalloc::Heap::allocateSmallBumpRanges):
585         (bmalloc::Heap::derefSmallLine):
586         * bmalloc/IsoDeallocator.h:
587         * bmalloc/IsoHeap.h:
588         * bmalloc/IsoTLSDeallocatorEntry.h:
589         * bmalloc/IsoTLSDeallocatorEntryInlines.h:
590         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
591         * bmalloc/IsoTLSInlines.h:
592         (bmalloc::IsoTLS::ensureHeap):
593         * bmalloc/IsoTLSLayout.cpp:
594         (bmalloc::IsoTLSLayout::IsoTLSLayout):
595         (bmalloc::IsoTLSLayout::add):
596         * bmalloc/IsoTLSLayout.h:
597         * bmalloc/Mutex.cpp: Renamed from Source/bmalloc/bmalloc/StaticMutex.cpp.
598         (bmalloc::Mutex::lockSlowCase):
599         * bmalloc/Mutex.h:
600         (bmalloc::sleep):
601         (bmalloc::waitUntilFalse):
602         (bmalloc::Mutex::try_lock):
603         (bmalloc::Mutex::lock):
604         (bmalloc::Mutex::unlock):
605         (bmalloc::Mutex::Mutex): Deleted.
606         * bmalloc/ObjectType.cpp:
607         (bmalloc::objectType):
608         * bmalloc/PerProcess.cpp:
609         (bmalloc::getPerProcessData):
610         * bmalloc/PerProcess.h:
611         (bmalloc::PerProcess::mutex):
612         (bmalloc::PerProcess::getSlowCase):
613         * bmalloc/Scavenger.cpp:
614         (bmalloc::Scavenger::Scavenger):
615         (bmalloc::Scavenger::scavenge):
616         (bmalloc::Scavenger::freeableMemory):
617         * bmalloc/Scavenger.h:
618         * bmalloc/SmallLine.h:
619         (bmalloc::SmallLine::refCount):
620         (bmalloc::SmallLine::ref):
621         (bmalloc::SmallLine::deref):
622         * bmalloc/SmallPage.h:
623         (bmalloc::SmallPage::refCount):
624         (bmalloc::SmallPage::hasFreeLines const):
625         (bmalloc::SmallPage::setHasFreeLines):
626         (bmalloc::SmallPage::ref):
627         (bmalloc::SmallPage::deref):
628         * bmalloc/StaticMutex.h: Removed.
629         * bmalloc/VMHeap.cpp:
630         (bmalloc::VMHeap::VMHeap):
631         * bmalloc/VMHeap.h:
632         * bmalloc/Zone.cpp:
633         (bmalloc::Zone::Zone):
634         * bmalloc/Zone.h:
635         * bmalloc/bmalloc.cpp:
636         (bmalloc::api::tryLargeZeroedMemalignVirtual):
637         (bmalloc::api::freeLargeVirtual):
638         (bmalloc::api::isEnabled):
639         (bmalloc::api::setScavengerThreadQOSClass):
640         * bmalloc/bmalloc.h:
641
642 2018-04-04  Konstantin Tokarev  <annulen@yandex.ru>
643
644         Enable Gigacage unconditionally when building JSCOnly on macOS (build fix)
645         https://bugs.webkit.org/show_bug.cgi?id=184301
646
647         Reviewed by Yusuke Suzuki.
648
649         bmalloc/ProcessCheck.mm implements specific behavior for Mac and iOS ports,
650         which is guarded with BPLATFORM(COCOA). if we don't enable BPLATFORM(MAC)
651         or BPLATFORM(IOS) in JSCOnly, then BPLATFORM(COCOA) won't be defined
652         as well, and code path from ProcessCheck.mm will not be taken.
653
654         * CMakeLists.txt: Exclude ProcessCheck.mm from port-independent file
655         list.
656         * PlatformMac.cmake: Build ProcessCheck.mm for Mac port.
657         * bmalloc/BPlatform.h: Don't enable BPLATFORM(MAC) or BPLATFORM(IOS)
658         when building JSCOnly port.
659
660 2018-04-03  Saam Barati  <sbarati@apple.com>
661
662         totalPhysicalSize calculation when splitting a range must account for double rounding effects
663         https://bugs.webkit.org/show_bug.cgi?id=184275
664
665         Reviewed by Mark Lam.
666
667         The rounding error could happen when we split a range where the
668         range's total physical size equals the range's total size. The
669         rounding may cause the left size to lose a byte, and the right
670         size to gain a byte. This caused the right side to be a byte
671         large than its size.
672
673         * bmalloc/LargeRange.h:
674         (bmalloc::LargeRange::LargeRange):
675         (bmalloc::LargeRange::split const):
676
677 2018-04-02  Saam Barati  <sbarati@apple.com>
678
679         bmalloc should compute its own estimate of its footprint
680         https://bugs.webkit.org/show_bug.cgi?id=184121
681
682         Reviewed by Filip Pizlo.
683
684         This patch makes it so that bmalloc keeps track of its own physical
685         footprint.
686         
687         Doing this for IsoHeaps is trivial. It allocates/deallocates fixed
688         page sizes at a time. IsoHeapImpl just updates a count every time
689         a page is committed/decommitted.
690         
691         Making Heap keep its footprint was a bit trickier because of how
692         LargeRange is constructed. Before this patch, LargeRange kept track
693         of the amount of physical memory at the start of its range. This
694         patch extends large range to also keep track of the total physical memory
695         in the range just for footprint bookkeeping. This was needed to make
696         Heap's footprint come close to resembling reality, because as we merge and split
697         large ranges, the start physical size often becomes wildly inaccurate.
698         The total physical size number stored in LargeRange is still just an
699         estimate. It's possible that as ranges are split, that the total physical
700         size split amongst the two ranges doesn't resemble reality. This can
701         happen when the total physical size is really all in one end of the split,
702         but we mark it as being proportionally split amongst the resulting two
703         ranges. In practice, I did not notice this being a problem. The footprint
704         estimate tracks reality very closely (in my testing, within less than 1MB for
705         heaps with sizes upwards of 1GB). The other nice thing about total physical
706         size is that even if it diverges from reality in terms of how memory is
707         using up physical RAM, it stays internally consistent inside bmalloc's
708         own data structures.
709         
710         The main oversight of this patch is how it deals with Wasm memory. All Wasm
711         memory will be viewed by bmalloc as taking up physical space even when it
712         may not be. Wasm memory starts off as taking up purely virtual pages. When a
713         page is first accessed, only then will the OS page it in and cause it to use
714         physical RAM. I opened a bug to come up with a solution to this problem:
715         https://bugs.webkit.org/show_bug.cgi?id=184207
716
717         * bmalloc.xcodeproj/project.pbxproj:
718         * bmalloc/AvailableMemory.cpp:
719         (bmalloc::memoryStatus):
720         * bmalloc/BPlatform.h:
721         * bmalloc/Heap.cpp:
722         (bmalloc::Heap::Heap):
723         (bmalloc::Heap::freeableMemory):
724         (bmalloc::Heap::footprint):
725         (bmalloc::Heap::scavenge):
726         (bmalloc::Heap::deallocateSmallChunk):
727         (bmalloc::Heap::allocateSmallPage):
728         (bmalloc::Heap::splitAndAllocate):
729         (bmalloc::Heap::tryAllocateLarge):
730         (bmalloc::Heap::shrinkLarge):
731         (bmalloc::Heap::deallocateLarge):
732         (bmalloc::Heap::externalCommit):
733         (bmalloc::Heap::externalDecommit):
734         * bmalloc/Heap.h:
735         * bmalloc/IsoDirectory.h:
736         * bmalloc/IsoDirectoryInlines.h:
737         (bmalloc::passedNumPages>::takeFirstEligible):
738         (bmalloc::passedNumPages>::didDecommit):
739         (bmalloc::passedNumPages>::freeableMemory):
740         * bmalloc/IsoHeapImpl.h:
741         * bmalloc/IsoHeapImplInlines.h:
742         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
743         (bmalloc::IsoHeapImpl<Config>::footprint):
744         (bmalloc::IsoHeapImpl<Config>::didCommit):
745         (bmalloc::IsoHeapImpl<Config>::didDecommit):
746         * bmalloc/LargeRange.h:
747         (bmalloc::LargeRange::LargeRange):
748         (bmalloc::LargeRange::startPhysicalSize const):
749         (bmalloc::LargeRange::setStartPhysicalSize):
750         (bmalloc::LargeRange::totalPhysicalSize const):
751         (bmalloc::LargeRange::setTotalPhysicalSize):
752         (bmalloc::merge):
753         (bmalloc::LargeRange::split const):
754         (bmalloc::LargeRange::physicalSize const): Deleted.
755         (bmalloc::LargeRange::setPhysicalSize): Deleted.
756         * bmalloc/PhysicalPageMap.h: Added.
757         This class is added for debugging purposes. It's useful when hacking
758         on the code that calculates the footprint to use this map as a sanity
759         check. It's just a simple implementation that has a set of all the committed pages.
760
761         (bmalloc::PhysicalPageMap::commit):
762         (bmalloc::PhysicalPageMap::decommit):
763         (bmalloc::PhysicalPageMap::footprint):
764         (bmalloc::PhysicalPageMap::forEachPhysicalPage):
765         * bmalloc/Scavenger.cpp:
766         (bmalloc::dumpStats):
767         (bmalloc::Scavenger::scavenge):
768         (bmalloc::Scavenger::freeableMemory):
769         This is here just for debugging for now. But we should implement an
770         efficient version of this to use when driving when to run the
771         scavenger.
772
773         (bmalloc::Scavenger::footprint):
774         (bmalloc::Scavenger::threadRunLoop):
775         * bmalloc/Scavenger.h:
776         * bmalloc/VMAllocate.h:
777         (bmalloc::physicalPageSizeSloppy):
778         * bmalloc/VMHeap.cpp:
779         (bmalloc::VMHeap::tryAllocateLargeChunk):
780         * bmalloc/bmalloc.cpp:
781         (bmalloc::api::commitAlignedPhysical):
782         (bmalloc::api::decommitAlignedPhysical):
783         * bmalloc/bmalloc.h:
784
785 2018-03-28  Commit Queue  <commit-queue@webkit.org>
786
787         Unreviewed, rolling out r230005.
788         https://bugs.webkit.org/show_bug.cgi?id=184115
789
790         "it caused a huge regression on iOS" (Requested by saamyjoon
791         on #webkit).
792
793         Reverted changeset:
794
795         "memoryStatus() is wrong in certain testing scenarios on iOS"
796         https://bugs.webkit.org/show_bug.cgi?id=184050
797         https://trac.webkit.org/changeset/230005
798
799 2018-03-27  Saam Barati  <sbarati@apple.com>
800
801         memoryStatus() is wrong in certain testing scenarios on iOS
802         https://bugs.webkit.org/show_bug.cgi?id=184050
803         <rdar://problem/37959258>
804
805         Rubber-stamped by Mark Lam.
806
807         This switches us from using "phys_footprint" to using "internal + compressed"
808         when computing the dirty memory in the current process. There are iOS testing
809         scenarios where phys_footprint doesn't give us a reliable answer. In my testing,
810         "internal + compressed" tracks phys_footprint closely (when phys_footprint is
811         working). They're usually within much less than 1% of each other. We're making
812         this change to ensure testing in our iOS infrastructure is valid.
813         
814         I opened a bug to move back to phys_footprint when it's feasible:
815         https://bugs.webkit.org/show_bug.cgi?id=184050
816
817         * bmalloc/AvailableMemory.cpp:
818         (bmalloc::memoryStatus):
819
820 2018-03-20  Tim Horton  <timothy_horton@apple.com>
821
822         Add and adopt WK_PLATFORM_NAME and adjust default feature defines
823         https://bugs.webkit.org/show_bug.cgi?id=183758
824         <rdar://problem/38017644>
825
826         Reviewed by Dan Bernstein.
827
828         * Configurations/Base.xcconfig:
829
830 2018-03-16  Filip Pizlo  <fpizlo@apple.com>
831
832         Put the DOM in IsoHeaps
833         https://bugs.webkit.org/show_bug.cgi?id=183546
834
835         Reviewed by Simon Fraser.
836         
837         Make it easy to runtime-disable IsoHeaps.
838
839         * bmalloc/Allocator.h:
840         * bmalloc/IsoTLS.cpp:
841         (bmalloc::IsoTLS::determineMallocFallbackState):
842         * bmalloc/IsoTLS.h:
843         * bmalloc/IsoTLSInlines.h:
844         (bmalloc::IsoTLS::allocateSlow):
845         (bmalloc::IsoTLS::deallocateSlow):
846
847 2018-03-16  Michael Catanzaro  <mcatanzaro@igalia.com>
848
849         Improve error message when Gigacage cannot allocate virtual memory
850         https://bugs.webkit.org/show_bug.cgi?id=183329
851
852         Reviewed by Filip Pizlo.
853
854         We've discovered that Deja Dup monitor sets a virtual memory limit, breaking Gigacage. Since
855         it runs in the background on a fresh out-of-the-box install of Ubuntu, this is not good.
856         That will have to be fixed by Deja Dup, but there is concern that other applications might
857         try this, or that users will set a virtual memory limit for the entire desktop session. Of
858         particular concern is the possibility that users might have copypasted a ulimit line into
859         a session startup script without understanding it. Let's try to make it slightly easier to
860         understand what's going wrong.
861
862         * bmalloc/Gigacage.cpp:
863         (Gigacage::ensureGigacage):
864
865 2018-03-13  Tim Horton  <timothy_horton@apple.com>
866
867         Add and adopt WK_ALTERNATE_FRAMEWORKS_DIR in WTF and bmalloc
868         https://bugs.webkit.org/show_bug.cgi?id=183576
869         <rdar://problem/38396766>
870
871         Reviewed by Dan Bernstein.
872
873         * Configurations/Base.xcconfig:
874         * Configurations/bmalloc.xcconfig:
875         * Configurations/mbmalloc.xcconfig:
876
877 2018-03-10  Filip Pizlo  <fpizlo@apple.com>
878
879         PerProcess<> should be safe by default
880         https://bugs.webkit.org/show_bug.cgi?id=183545
881
882         Reviewed by Yusuke Suzuki.
883         
884         This makes PerProcess<> safe by default, so we don't need SafePerProcess<>.
885         
886         The new PerProcess<> design relies on a hash-consing mechanism for PerProcess<> storage based
887         on the __PRETTY_FUNCTION__ from inside PerProcess<>, which captures the instantiated type in
888         the string. Therefore, this can be used to runtime-coalesce PerProcess<> instances based on
889         type.
890         
891         I expect this to be perf-neutral. It's an important prerequisite to more bmalloc work, since I
892         don't want to have more PerProcess<> vs SafePerProcess<> bugs, and SafePerProcess<> can't be
893         used for everything (I don't see how to use it for isoheaps).
894
895         * CMakeLists.txt:
896         * bmalloc.xcodeproj/project.pbxproj:
897         * bmalloc/Heap.cpp:
898         (bmalloc::Heap::Heap):
899         * bmalloc/IsoDirectoryInlines.h:
900         (bmalloc::passedNumPages>::takeFirstEligible):
901         (bmalloc::passedNumPages>::didBecome):
902         * bmalloc/PerProcess.cpp: Added.
903         (bmalloc::stringHash):
904         (bmalloc::allocate):
905         (bmalloc::getPerProcessData):
906         * bmalloc/PerProcess.h:
907         (bmalloc::PerProcess::mutex):
908         (bmalloc::PerProcess::coalesce):
909         (bmalloc::PerProcess::getSlowCase):
910         (): Deleted.
911         * bmalloc/Scavenger.cpp:
912         * bmalloc/Scavenger.h:
913         * bmalloc/bmalloc.cpp:
914         (bmalloc::api::scavenge):
915         (bmalloc::api::setScavengerThreadQOSClass):
916
917 2018-03-10  Commit Queue  <commit-queue@webkit.org>
918
919         Unreviewed, rolling out r229436.
920         https://bugs.webkit.org/show_bug.cgi?id=183542
921
922         seems to have regressed wasm compile times by 10% (Requested
923         by pizlo-mbp on #webkit).
924
925         Reverted changeset:
926
927         "bmalloc mutex should be adaptive"
928         https://bugs.webkit.org/show_bug.cgi?id=177839
929         https://trac.webkit.org/changeset/229436
930
931 2018-03-08  Filip Pizlo  <fpizlo@apple.com>
932
933         bmalloc mutex should be adaptive
934         https://bugs.webkit.org/show_bug.cgi?id=177839
935
936         Reviewed by Michael Saboff.
937         
938         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
939         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
940         anything other than malloc.
941
942         Reland after failing to reproduce the WasmBench crash that caused it to get rolled out. Maybe that fixed
943         itself somehow?
944
945         * bmalloc/Algorithm.h:
946         (bmalloc::compareExchangeWeak):
947         (bmalloc::compareExchangeStrong):
948         * bmalloc/PerThread.h:
949         * bmalloc/StaticMutex.cpp:
950         (bmalloc::StaticMutex::lockSlow):
951         (bmalloc::StaticMutex::unlockSlow):
952         (bmalloc::StaticMutex::lockSlowCase): Deleted.
953         * bmalloc/StaticMutex.h:
954         (bmalloc::StaticMutex::try_lock):
955         (bmalloc::StaticMutex::isLocked const):
956         (bmalloc::StaticMutex::init):
957         (bmalloc::StaticMutex::tryLock):
958         (bmalloc::StaticMutex::lock):
959         (bmalloc::StaticMutex::unlock):
960         (bmalloc::sleep): Deleted.
961         (bmalloc::waitUntilFalse): Deleted.
962
963 2018-02-16  Filip Pizlo  <fpizlo@apple.com>
964
965         Unreviewed, roll out r228306 (custom memcpy/memset) because the bots say that it was not a
966         progression.
967
968         * bmalloc/Algorithm.h:
969         (bmalloc::fastCopy): Deleted.
970         (bmalloc::fastZeroFill): Deleted.
971         * bmalloc/Allocator.cpp:
972         (bmalloc::Allocator::reallocate):
973         * bmalloc/Bits.h:
974         (bmalloc::BitsWordOwner::operator=):
975         (bmalloc::BitsWordOwner::clearAll):
976         (bmalloc::BitsWordOwner::set):
977         * bmalloc/IsoPageInlines.h:
978         (bmalloc::IsoPage<Config>::IsoPage):
979         * bmalloc/Vector.h:
980         (bmalloc::Vector<T>::reallocateBuffer):
981
982 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
983
984         Improve of string.h include after r228317.
985         https://bugs.webkit.org/show_bug.cgi?id=182642
986
987         Reviewed by Mark Lam.
988
989         * bmalloc/Algorithm.h: Avoid an architecture-specific #include.
990
991 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
992
993         Fix build for !BCPU(X86_64) after r228306
994         https://bugs.webkit.org/show_bug.cgi?id=182563
995
996         Unreviewed build fix.
997
998         * bmalloc/Algorithm.h:
999
1000 2018-02-08  Filip Pizlo  <fpizlo@apple.com>
1001
1002         Experiment with alternative implementation of memcpy/memset
1003         https://bugs.webkit.org/show_bug.cgi?id=182563
1004
1005         Reviewed by Michael Saboff and Mark Lam.
1006         
1007         Add a faster x86_64-specific implementation of memcpy and memset. Ideally, this would just be
1008         implemented in WTF, but we have to copy it into bmalloc since bmalloc sits below WTF on the
1009         stack.
1010
1011         * bmalloc/Algorithm.h:
1012         (bmalloc::fastCopy):
1013         (bmalloc::fastZeroFill):
1014         * bmalloc/Allocator.cpp:
1015         (bmalloc::Allocator::reallocate):
1016         * bmalloc/Bits.h:
1017         (bmalloc::BitsWordOwner::operator=):
1018         (bmalloc::BitsWordOwner::clearAll):
1019         (bmalloc::BitsWordOwner::set):
1020         * bmalloc/IsoPageInlines.h:
1021         (bmalloc::IsoPage<Config>::IsoPage):
1022         * bmalloc/Vector.h:
1023         (bmalloc::Vector<T>::reallocateBuffer):
1024
1025 2018-02-05  JF Bastien  <jfbastien@apple.com>
1026
1027         Gigacage: enable only for WebContent process and token executables
1028         https://bugs.webkit.org/show_bug.cgi?id=182457
1029         <rdar://problem/35875011>
1030
1031         Reviewed by Keith Miller.
1032
1033         Gigacage is a solid security improvement, but it's probably best
1034         to roll it out incrementally to the most valuable targets first
1035         and progressively try out more and more over time rather than
1036         outright enabling it everywhere. We've gotten some reports that it
1037         has some side-effects that weren't expected, so for now let's
1038         enable it for the WebContent process, JSC, and other executables
1039         we know, and then later we'll enable more gigacage uses.
1040
1041         For now I've chosen the following bundles:
1042
1043           - com.apple.WebKit.WebContent.Development
1044           - com.apple.WebKit.WebContent
1045           - com.apple.WebProcess
1046
1047         And the following processes:
1048
1049           - jsc
1050           - wasm
1051           - anything starting with "test", to match the JSC tests
1052
1053         I tried a different approach first, where I add a function to turn
1054         gigacage on or off and crash if gigacage is initialized without
1055         having been told what to do. Doing this in ChildProcess and a
1056         bunch of the process initialization methods isn't sufficient. I
1057         got MiniBrowser working, but some other builds use static globals
1058         which themselves use hash and string which are allocate with
1059         bmalloc and therefore which initialize gigacage before main is
1060         called and before the process gets a chance to opt in our out. It
1061         gets tricky with API calls too, because we have to do the right
1062         thing in any entry an API user could plausibly use, even the
1063         private ones, so I endend up having to initialize gigacage in e.g.
1064         WebPreferencesExperimentalFeatures.cpp.erb.
1065
1066         Another approach could be to create a free-for-all gigacage
1067         entitlement, and opt-in the processes we want..
1068
1069         As a follow-up we can also check that gigacage allocation always
1070         succeeds if it was allowed for that process. With my change I
1071         expect it to always succeed.
1072
1073         * CMakeLists.txt:
1074         * bmalloc.xcodeproj/project.pbxproj:
1075         * bmalloc/BPlatform.h:
1076         * bmalloc/Gigacage.cpp:
1077         (Gigacage::shouldBeEnabled):
1078         * bmalloc/ProcessCheck.h: Added.
1079         (bmalloc::gigacageEnabledForProcess):
1080         * bmalloc/ProcessCheck.mm: Added.
1081         (bmalloc::gigacageEnabledForProcess):
1082
1083 2018-02-05  Joseph Pecoraro  <pecoraro@apple.com>
1084
1085         Multiple bmalloc scavenger threads is unexpected
1086         https://bugs.webkit.org/show_bug.cgi?id=182474
1087         <rdar://problem/37175526>
1088
1089         Reviewed by Filip Pizlo.
1090
1091         * bmalloc/Heap.cpp:
1092         (bmalloc::Heap::Heap):
1093         * bmalloc/IsoDirectoryInlines.h:
1094         (bmalloc::passedNumPages>::takeFirstEligible):
1095         (bmalloc::passedNumPages>::didBecome):
1096         * bmalloc/bmalloc.cpp:
1097         (bmalloc::api::scavenge):
1098         (bmalloc::api::setScavengerThreadQOSClass):
1099         Switch to SafePerProcess for Scavenger to ensure one instance
1100         for the entire process.
1101
1102         * bmalloc/PerProcess.h:
1103         (bmalloc::PerProcess::get):
1104         (bmalloc::PerProcess::getFastCase):
1105         (bmalloc::PerProcess::getSlowCase):
1106         (bmalloc::SafePerProcess::get):
1107         (bmalloc::SafePerProcess::getFastCase):
1108         (bmalloc::SafePerProcess::getSlowCase):
1109         Duplicate the class with a version that can ensure
1110         single instances by requiring exporting symbols that
1111         can be created with macros.
1112
1113         * bmalloc/Scavenger.cpp:
1114         * bmalloc/Scavenger.h:
1115         Export symbols to ensure all images get the same instance.
1116
1117 2018-01-31  Saam Barati  <sbarati@apple.com>
1118
1119         Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
1120         https://bugs.webkit.org/show_bug.cgi?id=182064
1121         <rdar://problem/36840132>
1122
1123         Reviewed by Geoffrey Garen.
1124
1125         This patch replaces the tryLargeMemalignVirtual API with tryLargeZeroedMemalignVirtual.
1126         By doing that, we're able to remove the AllocationKind enum. To zero the memory,
1127         tryLargeZeroedMemalignVirtual uses mmap(... MAP_ANON ...) over previously mmapped
1128         memory. This both purges the any resident memory for the virtual range and ensures
1129         that the pages in the range are zeroed. Most OSs should implement this by taking a
1130         page fault and zero filling on first access. Therefore, this API is returning pages
1131         that will result in page faults on first access. Hence, the name 'virtual' in the API.
1132         This API differs from the old API in that users of it need not call madvise themselves.
1133         The memory is ready to go.
1134
1135         * bmalloc.xcodeproj/project.pbxproj:
1136         * bmalloc/AllocationKind.h: Removed.
1137         * bmalloc/DebugHeap.cpp:
1138         (bmalloc::DebugHeap::memalignLarge):
1139         (bmalloc::DebugHeap::freeLarge):
1140         * bmalloc/DebugHeap.h:
1141         * bmalloc/Heap.cpp:
1142         (bmalloc::Heap::splitAndAllocate):
1143         (bmalloc::Heap::tryAllocateLarge):
1144         (bmalloc::Heap::allocateLarge):
1145         (bmalloc::Heap::shrinkLarge):
1146         (bmalloc::Heap::deallocateLarge):
1147         * bmalloc/Heap.h:
1148         * bmalloc/IsoPage.cpp:
1149         (bmalloc::IsoPageBase::allocatePageMemory):
1150         * bmalloc/VMAllocate.h:
1151         (bmalloc::vmZeroAndPurge):
1152         * bmalloc/VMHeap.cpp:
1153         (bmalloc::VMHeap::tryAllocateLargeChunk):
1154         * bmalloc/VMHeap.h:
1155         * bmalloc/bmalloc.cpp:
1156         (bmalloc::api::tryLargeZeroedMemalignVirtual):
1157         (bmalloc::api::freeLargeVirtual):
1158         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
1159         * bmalloc/bmalloc.h:
1160
1161 2018-01-19  Keith Miller  <keith_miller@apple.com>
1162
1163         HaveInternalSDK includes should be "#include?"
1164         https://bugs.webkit.org/show_bug.cgi?id=179670
1165
1166         Reviewed by Dan Bernstein.
1167
1168         * Configurations/Base.xcconfig:
1169
1170 2018-01-18  Dan Bernstein  <mitz@apple.com>
1171
1172         [Xcode] Streamline and future-proof target-macOS-version-dependent build setting definitions
1173         https://bugs.webkit.org/show_bug.cgi?id=181803
1174
1175         Reviewed by Tim Horton.
1176
1177         * Configurations/Base.xcconfig: Updated.
1178         * Configurations/DebugRelease.xcconfig: Ditto.
1179
1180 2018-01-16  Michael Catanzaro  <mcatanzaro@igalia.com>
1181
1182         mbmalloc should only be built in developer mode
1183         https://bugs.webkit.org/show_bug.cgi?id=181654
1184
1185         Reviewed by Carlos Garcia Campos.
1186
1187         * CMakeLists.txt:
1188
1189 2018-01-15  Michael Catanzaro  <mcatanzaro@igalia.com>
1190
1191         Improve use of ExportMacros
1192         https://bugs.webkit.org/show_bug.cgi?id=181652
1193
1194         Reviewed by Konstantin Tokarev.
1195
1196         Disable BEXPORT on Linux ports.
1197
1198         * bmalloc/BExport.h: Check for BUSE(EXPORT_MACROS).
1199         * bmalloc/BPlatform.h: Add BUSE(EXPORT_MACROS) and define it on macOS and iOS.
1200
1201 2017-12-20  Ting-Wei Lan  <lantw44@gmail.com>
1202
1203         Include stdio.h before using stderr and _IONBF
1204         https://bugs.webkit.org/show_bug.cgi?id=181046
1205
1206         Reviewed by Alex Christensen.
1207
1208         * bmalloc/IsoTLS.cpp:
1209
1210 2017-12-14  David Kilzer  <ddkilzer@apple.com>
1211
1212         Enable -Wstrict-prototypes for WebKit
1213         <https://webkit.org/b/180757>
1214         <rdar://problem/36024132>
1215
1216         Rubber-stamped by Joseph Pecoraro.
1217
1218         * Configurations/Base.xcconfig:
1219         (CLANG_WARN_STRICT_PROTOTYPES): Add. Set to YES.
1220
1221 2017-12-14  Saam Barati  <sbarati@apple.com>
1222
1223         logVMFailure should not simulate crash on iOS
1224         https://bugs.webkit.org/show_bug.cgi?id=180790
1225
1226         Reviewed by JF Bastien.
1227
1228         The Gigacage allocation on iOS is expected to fail in certain circumstances. 
1229         Let's not simulate a crash on failure because since this is expected behavior.
1230
1231         * bmalloc/VMAllocate.h:
1232         (bmalloc::tryVMAllocate):
1233
1234 2017-12-11  Tim Horton  <timothy_horton@apple.com>
1235
1236         Stop using deprecated target conditional for simulator builds
1237         https://bugs.webkit.org/show_bug.cgi?id=180662
1238         <rdar://problem/35136156>
1239
1240         Reviewed by Simon Fraser.
1241
1242         * bmalloc/BPlatform.h:
1243
1244 2017-12-08  Saam Barati  <sbarati@apple.com>
1245
1246         Enable gigacage on iOS with a 32GB runway and ensure it doesn't break WasmBench
1247         https://bugs.webkit.org/show_bug.cgi?id=178557
1248
1249         Reviewed by Mark Lam.
1250
1251         * bmalloc/Algorithm.h:
1252         (bmalloc::isPowerOfTwo):
1253         * bmalloc/Gigacage.cpp:
1254         * bmalloc/Gigacage.h:
1255
1256 2017-12-05  Andy Estes  <aestes@apple.com>
1257
1258         [Darwin] Simplify use of TargetConditionals
1259         https://bugs.webkit.org/show_bug.cgi?id=180455
1260         <rdar://problem/35142971>
1261
1262         Reviewed by Tim Horton.
1263
1264         There's no need to check if TARGET_* macros are defined on Darwin platforms, since
1265         TargetConditionals.h always defines them. Also, we can simplify
1266         (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE || TARGET_IPHONE_SIMULATOR) to TARGET_OS_IPHONE.
1267
1268         * bmalloc/BPlatform.h:
1269
1270 2017-12-05  Filip Pizlo  <fpizlo@apple.com>
1271
1272         bmalloc IsoHeap needs to allow a thread to deallocate some size for the first time
1273         https://bugs.webkit.org/show_bug.cgi?id=180443
1274
1275         Reviewed by Saam Barati.
1276
1277         It's true that we can expect a heap to already be initialized if we try to deallocate in it.  But it
1278         may not have its deallocator initialized on this thread yet.
1279         
1280         This is easily fixed by adding a null check on the deallocate path. That's probably not going to
1281         change perf at all. But doing that allows me to get rid of a lot of weird stuff I previously did to
1282         avoid that null check, like creating a dummy TLS in the DebugHeap case.
1283
1284         * bmalloc/IsoTLS.cpp:
1285         (bmalloc::IsoTLS::debugFree):
1286         (bmalloc::IsoTLS::deallocateSlow): Deleted.
1287         * bmalloc/IsoTLS.h:
1288         * bmalloc/IsoTLSInlines.h:
1289         (bmalloc::IsoTLS::allocateImpl):
1290         (bmalloc::IsoTLS::allocateSlow):
1291         (bmalloc::IsoTLS::deallocateImpl):
1292         (bmalloc::IsoTLS::deallocateSlow):
1293         (bmalloc::IsoTLS::ensureHeapAndEntries):
1294
1295 2017-12-01  Michael Saboff  <msaboff@apple.com>
1296
1297         Gigacage should not be enabled for ARM64_32
1298         https://bugs.webkit.org/show_bug.cgi?id=180265
1299
1300         Reviewed by Saam Barati.
1301
1302         Disabled Gigacage for ARM64_32.
1303         In the process, restructured Gigacage::shouldBeEnabled() with GIGACAGE_ENABLED set
1304         to 0 to avoid a dead code compiler warning.
1305
1306         * bmalloc/Gigacage.cpp:
1307         (Gigacage::shouldBeEnabled):
1308         * bmalloc/Gigacage.h:
1309
1310 2017-11-29  JF Bastien  <jfbastien@apple.com>
1311
1312         WTF / bmalloc: don't write to 0xbbadbeef when ASAN is looking
1313         https://bugs.webkit.org/show_bug.cgi?id=180175
1314
1315         Reviewed by Mark Lam.
1316
1317         ASAN knows that 0xbbadbeef is a bbad aaddress, and tells us so
1318         when we write to it, say in an assert. That creates bbad error
1319         reports where ASAN thinks we write to an invalid address, instead
1320         of thinking that we hit an assertion. In some cases, tooling that
1321         use fuzzers aggregate similar issues, and think that we just have
1322         the one bug and not a bunch of different asserts.
1323
1324         At the same time, bmalloc's version of CRASH just writes to
1325         0xbbadbeef and assumes that's invalid and will crash, which isn't
1326         necessarily true on non-Mac platforms. WTF's version then makes
1327         sure there's a crash, so bmalloc should do the same.
1328
1329         * bmalloc.xcodeproj/project.pbxproj:
1330         * bmalloc/BAssert.h:
1331         * bmalloc/BCompiler.h: Added.
1332         * bmalloc/BPlatform.h:
1333
1334 2017-11-27  Filip Pizlo  <fpizlo@apple.com>
1335
1336         Don't crash in forEachEntry when DebugHeap is enabled.
1337
1338         Unreviewed, fixing crashes on leaks bots by removing an assertion.
1339
1340         * bmalloc/IsoTLS.cpp:
1341         (bmalloc::IsoTLS::forEachEntry):
1342         * test/testbmalloc.cpp: Make this test work with DebugHeap so I can catch this kind of problem in the future.
1343
1344 2017-11-16  Filip Pizlo  <fpizlo@apple.com>
1345
1346         Isolated Heaps caused an increase in reported leaks on the bots
1347         https://bugs.webkit.org/show_bug.cgi?id=179463
1348
1349         Reviewed by Darin Adler.
1350         
1351         This fixes the way isoheaps interact with system tools:
1352         
1353         - Opts into the VMHeap API so that the leaks tool can find isoheap memory.
1354         
1355         - Opts into the DebugHeap/Environment APIs so that we turn off isoheap allocation if memory
1356           debugging options are in use.
1357
1358         * bmalloc.xcodeproj/project.pbxproj:
1359         * bmalloc/DebugHeap.h:
1360         * bmalloc/IsoHeap.h:
1361         * bmalloc/IsoPage.cpp: Added.
1362         (bmalloc::IsoPageBase::allocatePageMemory):
1363         * bmalloc/IsoPage.h:
1364         * bmalloc/IsoPageInlines.h:
1365         (bmalloc::IsoPage<Config>::tryCreate):
1366         * bmalloc/IsoTLS.cpp:
1367         (bmalloc::IsoTLS::deallocateSlow):
1368         (bmalloc::IsoTLS::ensureEntries):
1369         (bmalloc::IsoTLS::isUsingDebugHeap):
1370         (bmalloc::IsoTLS::debugMalloc):
1371         * bmalloc/IsoTLS.h:
1372         * bmalloc/IsoTLSInlines.h:
1373         (bmalloc::IsoTLS::allocate):
1374         (bmalloc::IsoTLS::deallocate):
1375         (bmalloc::IsoTLS::allocateImpl):
1376         (bmalloc::IsoTLS::allocateFast):
1377         (bmalloc::IsoTLS::allocateSlow):
1378         (bmalloc::IsoTLS::deallocateImpl):
1379         (bmalloc::IsoTLS::deallocateFast):
1380         (bmalloc::IsoTLS::ensureHeapAndEntries):
1381         (bmalloc::IsoTLS::allocator): Deleted.
1382         (bmalloc::IsoTLS::deallocator): Deleted.
1383         * bmalloc/bmalloc.cpp:
1384         (bmalloc::api::tryLargeMemalignVirtual):
1385         (bmalloc::api::freeLargeVirtual):
1386         (bmalloc::api::scavenge):
1387         (bmalloc::api::isEnabled):
1388         (bmalloc::api::setScavengerThreadQOSClass):
1389         * bmalloc/bmalloc.h:
1390         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
1391         (bmalloc::api::freeLargeVirtual): Deleted.
1392         (bmalloc::api::scavenge): Deleted.
1393         (bmalloc::api::isEnabled): Deleted.
1394         (bmalloc::api::setScavengerThreadQOSClass): Deleted.
1395
1396 2017-11-14  Saam Barati  <sbarati@apple.com>
1397
1398         Make the gigacage runway 32GB
1399         https://bugs.webkit.org/show_bug.cgi?id=175062
1400
1401         Reviewed by Mark Lam.
1402
1403         Making the gigacage runway 32GB defends us against buffer overflows in the
1404         cage reaching memory outside the cage assuming indices are 32-bit unsigned
1405         integers and the type they're indexing into has size <= 8 bytes. This is
1406         exactly the case for many things in JSC. For example, butterfly access in
1407         JSC meet this criteria, as does typed array access.
1408         
1409         The 32GB comes from 8 * 2^32 = 32GB.
1410
1411         * bmalloc/Gigacage.cpp:
1412
1413 2017-11-08  Michael Catanzaro  <mcatanzaro@igalia.com>
1414
1415         Gigacage.cpp:44:46: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
1416         https://bugs.webkit.org/show_bug.cgi?id=179427
1417
1418         Reviewed by Saam Barati.
1419
1420         Tweak the conditional to suppress the warning.
1421
1422         * bmalloc/Gigacage.cpp:
1423         (Gigacage::ensureGigacage):
1424
1425 2017-11-07  Saam Barati  <sbarati@apple.com>
1426
1427         We should PROT_NONE the Gigacage runway so OOB accesses crash
1428         https://bugs.webkit.org/show_bug.cgi?id=179392
1429
1430         Reviewed by Mark Lam.
1431
1432         If we assume that an attacker will exploit JSC and cause OOB accesses,
1433         we should make OOB accesses in the Gigacage runway crash.
1434
1435         * bmalloc/Gigacage.cpp:
1436         (Gigacage::ensureGigacage):
1437
1438 2017-10-31  Filip Pizlo  <fpizlo@apple.com>
1439
1440         bmalloc should support strictly type-segregated isolated heaps
1441         https://bugs.webkit.org/show_bug.cgi?id=178108
1442
1443         Reviewed by Saam Barati, Simon Fraser, and Ryosuke Niwa.
1444         
1445         This introduces a new allocation API in bmalloc called IsoHeap. An IsoHeap is templatized by
1446         type and created in static storage. When unused, it takes only a few words. When you do use
1447         it, each IsoHeap gets a bag of virtual pages unique to it. This prevents use-after-free bugs
1448         in one IsoHeap from affecting any other memory. At worst, two pointers of the same type will
1449         point to the same object even though they should not have.
1450         
1451         IsoHeaps allocate using a first-fit discipline that combines ideas from bmalloc and Riptide
1452         (the JSC GC):
1453         
1454         Like Riptide, it uses a bump'n'pop allocator. What Riptide calls blocks, IsoHeaps calls
1455         pages. Pages are collected into directories. Directories track pages using bitvectors, so
1456         that it's easy to quickly find a completely free page or one that has at least one free
1457         object. I think that the bump'n'pop allocator is as fast as the bmalloc Immix-style (page and
1458         line) allocator, but is better at allocating in holes. It's guaranteed to follow a first-fit
1459         discipline. However, the real reason why I wrote it that was is that this is what I'm more
1460         familiar with. This is a part of the design I want to revisit (bug 179278).
1461         
1462         Like bmalloc, it uses a deallocation log. This means that the internal IsoHeap data
1463         structures can be locked with a coarse-grained lock, since the deallocator only grabs it when
1464         flushing the log. Similarly, the allocator only grabs it when refilling the bump'n'pop
1465         FreeList.
1466         
1467         This adds a unit test for IsoHeaps. In this change, IsoHeaps are adopted only by WebCore's
1468         RenderObject.
1469         
1470         Note that despite the use of GC concepts, it's not a goal to make this code directly sharable
1471         with GC. The GC will probably have to do isolated heaps its own way (likely a special
1472         Subspace or something like that).
1473
1474         * bmalloc.xcodeproj/project.pbxproj:
1475         * bmalloc/Algorithm.h:
1476         (bmalloc::findBitInWord):
1477         * bmalloc/AllIsoHeaps.cpp: Added.
1478         (bmalloc::AllIsoHeaps::AllIsoHeaps):
1479         (bmalloc::AllIsoHeaps::add):
1480         (bmalloc::AllIsoHeaps::head):
1481         * bmalloc/AllIsoHeaps.h: Added.
1482         * bmalloc/AllIsoHeapsInlines.h: Added.
1483         (bmalloc::AllIsoHeaps::forEach):
1484         * bmalloc/BMalloced.h: Added.
1485         * bmalloc/Bits.h: Added.
1486         (bmalloc::bitsArrayLength):
1487         (bmalloc::BitsWordView::BitsWordView):
1488         (bmalloc::BitsWordView::numBits const):
1489         (bmalloc::BitsWordView::word const):
1490         (bmalloc::BitsWordOwner::BitsWordOwner):
1491         (bmalloc::BitsWordOwner::view const):
1492         (bmalloc::BitsWordOwner::operator=):
1493         (bmalloc::BitsWordOwner::setAll):
1494         (bmalloc::BitsWordOwner::clearAll):
1495         (bmalloc::BitsWordOwner::set):
1496         (bmalloc::BitsWordOwner::numBits const):
1497         (bmalloc::BitsWordOwner::arrayLength const):
1498         (bmalloc::BitsWordOwner::word const):
1499         (bmalloc::BitsWordOwner::word):
1500         (bmalloc::BitsWordOwner::words const):
1501         (bmalloc::BitsWordOwner::words):
1502         (bmalloc::BitsAndWords::BitsAndWords):
1503         (bmalloc::BitsAndWords::view const):
1504         (bmalloc::BitsAndWords::numBits const):
1505         (bmalloc::BitsAndWords::word const):
1506         (bmalloc::BitsOrWords::BitsOrWords):
1507         (bmalloc::BitsOrWords::view const):
1508         (bmalloc::BitsOrWords::numBits const):
1509         (bmalloc::BitsOrWords::word const):
1510         (bmalloc::BitsNotWords::BitsNotWords):
1511         (bmalloc::BitsNotWords::view const):
1512         (bmalloc::BitsNotWords::numBits const):
1513         (bmalloc::BitsNotWords::word const):
1514         (bmalloc::BitsImpl::BitsImpl):
1515         (bmalloc::BitsImpl::numBits const):
1516         (bmalloc::BitsImpl::size const):
1517         (bmalloc::BitsImpl::arrayLength const):
1518         (bmalloc::BitsImpl::operator== const):
1519         (bmalloc::BitsImpl::operator!= const):
1520         (bmalloc::BitsImpl::at const):
1521         (bmalloc::BitsImpl::operator[] const):
1522         (bmalloc::BitsImpl::isEmpty const):
1523         (bmalloc::BitsImpl::operator& const):
1524         (bmalloc::BitsImpl::operator| const):
1525         (bmalloc::BitsImpl::operator~ const):
1526         (bmalloc::BitsImpl::forEachSetBit const):
1527         (bmalloc::BitsImpl::forEachClearBit const):
1528         (bmalloc::BitsImpl::forEachBit const):
1529         (bmalloc::BitsImpl::findBit const):
1530         (bmalloc::BitsImpl::findSetBit const):
1531         (bmalloc::BitsImpl::findClearBit const):
1532         (bmalloc::BitsImpl::wordView const):
1533         (bmalloc::BitsImpl::atImpl const):
1534         (bmalloc::Bits::Bits):
1535         (bmalloc::Bits::operator=):
1536         (bmalloc::Bits::resize):
1537         (bmalloc::Bits::setAll):
1538         (bmalloc::Bits::clearAll):
1539         (bmalloc::Bits::setAndCheck):
1540         (bmalloc::Bits::operator|=):
1541         (bmalloc::Bits::operator&=):
1542         (bmalloc::Bits::at const):
1543         (bmalloc::Bits::operator[] const):
1544         (bmalloc::Bits::BitReference::BitReference):
1545         (bmalloc::Bits::BitReference::operator bool const):
1546         (bmalloc::Bits::BitReference::operator=):
1547         (bmalloc::Bits::at):
1548         (bmalloc::Bits::operator[]):
1549         * bmalloc/CryptoRandom.cpp: Replaced with Source/bmalloc/bmalloc/CryptoRandom.cpp.
1550         (bmalloc::cryptoRandom):
1551         * bmalloc/CryptoRandom.h: Replaced with Source/bmalloc/bmalloc/CryptoRandom.h.
1552         * bmalloc/DeferredDecommit.h: Added.
1553         * bmalloc/DeferredDecommitInlines.h: Added.
1554         (bmalloc::DeferredDecommit::DeferredDecommit):
1555         * bmalloc/DeferredTrigger.h: Added.
1556         (bmalloc::DeferredTrigger::DeferredTrigger):
1557         * bmalloc/DeferredTriggerInlines.h: Added.
1558         (bmalloc::DeferredTrigger<trigger>::didBecome):
1559         (bmalloc::DeferredTrigger<trigger>::handleDeferral):
1560         * bmalloc/EligibilityResult.h: Added.
1561         (bmalloc::EligibilityResult::EligibilityResult):
1562         * bmalloc/EligibilityResultInlines.h: Added.
1563         (bmalloc::EligibilityResult<Config>::EligibilityResult):
1564         * bmalloc/FixedVector.h:
1565         * bmalloc/FreeList.cpp: Added.
1566         (bmalloc::FreeList::FreeList):
1567         (bmalloc::FreeList::~FreeList):
1568         (bmalloc::FreeList::clear):
1569         (bmalloc::FreeList::initializeList):
1570         (bmalloc::FreeList::initializeBump):
1571         (bmalloc::FreeList::contains const):
1572         * bmalloc/FreeList.h: Added.
1573         (bmalloc::FreeCell::scramble):
1574         (bmalloc::FreeCell::descramble):
1575         (bmalloc::FreeCell::setNext):
1576         (bmalloc::FreeCell::next const):
1577         (bmalloc::FreeList::allocationWillFail const):
1578         (bmalloc::FreeList::allocationWillSucceed const):
1579         (bmalloc::FreeList::originalSize const):
1580         (bmalloc::FreeList::head const):
1581         * bmalloc/FreeListInlines.h: Added.
1582         (bmalloc::FreeList::allocate):
1583         (bmalloc::FreeList::forEach const):
1584         * bmalloc/IsoAllocator.h: Added.
1585         * bmalloc/IsoAllocatorInlines.h: Added.
1586         (bmalloc::IsoAllocator<Config>::IsoAllocator):
1587         (bmalloc::IsoAllocator<Config>::~IsoAllocator):
1588         (bmalloc::IsoAllocator<Config>::allocate):
1589         (bmalloc::IsoAllocator<Config>::allocateSlow):
1590         (bmalloc::IsoAllocator<Config>::scavenge):
1591         * bmalloc/IsoConfig.h: Added.
1592         * bmalloc/IsoDeallocator.h: Added.
1593         * bmalloc/IsoDeallocatorInlines.h: Added.
1594         (bmalloc::IsoDeallocator<Config>::IsoDeallocator):
1595         (bmalloc::IsoDeallocator<Config>::~IsoDeallocator):
1596         (bmalloc::IsoDeallocator<Config>::deallocate):
1597         (bmalloc::IsoDeallocator<Config>::scavenge):
1598         * bmalloc/IsoDirectory.h: Added.
1599         (bmalloc::IsoDirectoryBaseBase::IsoDirectoryBaseBase):
1600         (bmalloc::IsoDirectoryBaseBase::~IsoDirectoryBaseBase):
1601         (bmalloc::IsoDirectoryBase::heap):
1602         * bmalloc/IsoDirectoryInlines.h: Added.
1603         (bmalloc::IsoDirectoryBase<Config>::IsoDirectoryBase):
1604         (bmalloc::passedNumPages>::IsoDirectory):
1605         (bmalloc::passedNumPages>::takeFirstEligible):
1606         (bmalloc::passedNumPages>::didBecome):
1607         (bmalloc::passedNumPages>::didDecommit):
1608         (bmalloc::passedNumPages>::scavenge):
1609         (bmalloc::passedNumPages>::forEachCommittedPage):
1610         * bmalloc/IsoDirectoryPage.h: Added.
1611         (bmalloc::IsoDirectoryPage::index const):
1612         * bmalloc/IsoDirectoryPageInlines.h: Added.
1613         (bmalloc::IsoDirectoryPage<Config>::IsoDirectoryPage):
1614         (bmalloc::IsoDirectoryPage<Config>::pageFor):
1615         * bmalloc/IsoHeap.h: Added.
1616         (bmalloc::api::IsoHeap::allocatorOffset):
1617         (bmalloc::api::IsoHeap::setAllocatorOffset):
1618         (bmalloc::api::IsoHeap::deallocatorOffset):
1619         (bmalloc::api::IsoHeap::setDeallocatorOffset):
1620         * bmalloc/IsoHeapImpl.cpp: Added.
1621         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
1622         (bmalloc::IsoHeapImplBase::~IsoHeapImplBase):
1623         (bmalloc::IsoHeapImplBase::scavengeNow):
1624         (bmalloc::IsoHeapImplBase::finishScavenging):
1625         * bmalloc/IsoHeapImpl.h: Added.
1626         * bmalloc/IsoHeapImplInlines.h: Added.
1627         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
1628         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
1629         (bmalloc::IsoHeapImpl<Config>::didBecomeEligible):
1630         (bmalloc::IsoHeapImpl<Config>::scavenge):
1631         (bmalloc::IsoHeapImpl<Config>::allocatorOffset):
1632         (bmalloc::IsoHeapImpl<Config>::deallocatorOffset):
1633         (bmalloc::IsoHeapImpl<Config>::numLiveObjects):
1634         (bmalloc::IsoHeapImpl<Config>::numCommittedPages):
1635         (bmalloc::IsoHeapImpl<Config>::forEachDirectory):
1636         (bmalloc::IsoHeapImpl<Config>::forEachCommittedPage):
1637         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
1638         * bmalloc/IsoHeapInlines.h: Added.
1639         (bmalloc::api::IsoHeap<Type>::allocate):
1640         (bmalloc::api::IsoHeap<Type>::tryAllocate):
1641         (bmalloc::api::IsoHeap<Type>::deallocate):
1642         (bmalloc::api::IsoHeap<Type>::scavenge):
1643         (bmalloc::api::IsoHeap<Type>::isInitialized):
1644         (bmalloc::api::IsoHeap<Type>::impl):
1645         * bmalloc/IsoPage.h: Added.
1646         (bmalloc::IsoPage::index const):
1647         (bmalloc::IsoPage::directory):
1648         (bmalloc::IsoPage::isInUseForAllocation const):
1649         (bmalloc::IsoPage::indexOfFirstObject):
1650         * bmalloc/IsoPageInlines.h: Added.
1651         (bmalloc::IsoPage<Config>::tryCreate):
1652         (bmalloc::IsoPage<Config>::IsoPage):
1653         (bmalloc::IsoPage<Config>::free):
1654         (bmalloc::IsoPage<Config>::startAllocating):
1655         (bmalloc::IsoPage<Config>::stopAllocating):
1656         (bmalloc::IsoPage<Config>::forEachLiveObject):
1657         * bmalloc/IsoPageTrigger.h: Added.
1658         * bmalloc/IsoTLS.cpp: Added.
1659         (bmalloc::IsoTLS::scavenge):
1660         (bmalloc::IsoTLS::IsoTLS):
1661         (bmalloc::IsoTLS::ensureEntries):
1662         (bmalloc::IsoTLS::destructor):
1663         (bmalloc::IsoTLS::sizeForCapacity):
1664         (bmalloc::IsoTLS::capacityForSize):
1665         (bmalloc::IsoTLS::size):
1666         (bmalloc::IsoTLS::forEachEntry):
1667         * bmalloc/IsoTLS.h: Added.
1668         * bmalloc/IsoTLSAllocatorEntry.h: Added.
1669         * bmalloc/IsoTLSAllocatorEntryInlines.h: Added.
1670         (bmalloc::IsoTLSAllocatorEntry<Config>::IsoTLSAllocatorEntry):
1671         (bmalloc::IsoTLSAllocatorEntry<Config>::~IsoTLSAllocatorEntry):
1672         (bmalloc::IsoTLSAllocatorEntry<Config>::construct):
1673         * bmalloc/IsoTLSDeallocatorEntry.h: Added.
1674         * bmalloc/IsoTLSDeallocatorEntryInlines.h: Added.
1675         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
1676         (bmalloc::IsoTLSDeallocatorEntry<Config>::~IsoTLSDeallocatorEntry):
1677         (bmalloc::IsoTLSDeallocatorEntry<Config>::construct):
1678         * bmalloc/IsoTLSEntry.cpp: Added.
1679         (bmalloc::IsoTLSEntry::IsoTLSEntry):
1680         (bmalloc::IsoTLSEntry::~IsoTLSEntry):
1681         * bmalloc/IsoTLSEntry.h: Added.
1682         (bmalloc::IsoTLSEntry::offset const):
1683         (bmalloc::IsoTLSEntry::alignment const):
1684         (bmalloc::IsoTLSEntry::size const):
1685         (bmalloc::IsoTLSEntry::extent const):
1686         * bmalloc/IsoTLSEntryInlines.h: Added.
1687         (bmalloc::IsoTLSEntry::walkUpToInclusive):
1688         (bmalloc::DefaultIsoTLSEntry<EntryType>::DefaultIsoTLSEntry):
1689         (bmalloc::DefaultIsoTLSEntry<EntryType>::~DefaultIsoTLSEntry):
1690         (bmalloc::DefaultIsoTLSEntry<EntryType>::move):
1691         (bmalloc::DefaultIsoTLSEntry<EntryType>::destruct):
1692         (bmalloc::DefaultIsoTLSEntry<EntryType>::scavenge):
1693         * bmalloc/IsoTLSInlines.h: Added.
1694         (bmalloc::IsoTLS::allocate):
1695         (bmalloc::IsoTLS::deallocate):
1696         (bmalloc::IsoTLS::scavenge):
1697         (bmalloc::IsoTLS::allocator):
1698         (bmalloc::IsoTLS::deallocator):
1699         (bmalloc::IsoTLS::get):
1700         (bmalloc::IsoTLS::set):
1701         (bmalloc::IsoTLS::ensureHeap):
1702         (bmalloc::IsoTLS::ensureHeapAndEntries):
1703         * bmalloc/IsoTLSLayout.cpp: Added.
1704         (bmalloc::IsoTLSLayout::IsoTLSLayout):
1705         (bmalloc::IsoTLSLayout::add):
1706         * bmalloc/IsoTLSLayout.h: Added.
1707         (bmalloc::IsoTLSLayout::head const):
1708         * bmalloc/PerHeapKind.h:
1709         * bmalloc/PerProcess.h:
1710         (bmalloc::PerProcess<T>::getFastCase):
1711         * bmalloc/Scavenger.cpp:
1712         (bmalloc::Scavenger::scavenge):
1713         * bmalloc/Scavenger.h:
1714         * bmalloc/bmalloc.h:
1715         (bmalloc::api::scavengeThisThread):
1716         * test: Added.
1717         * test/testbmalloc.cpp: Added.
1718         (hiddenTruthBecauseNoReturnIsStupid):
1719         (usage):
1720         (assertEmptyPointerSet):
1721         (assertHasObjects):
1722         (assertHasOnlyObjects):
1723         (assertClean):
1724         (testIsoSimple):
1725         (testIsoSimpleScavengeBeforeDealloc):
1726         (testIsoFlipFlopFragmentedPages):
1727         (testIsoFlipFlopFragmentedPagesScavengeInMiddle):
1728         (BisoMalloced::BisoMalloced):
1729         (testBisoMalloced):
1730         (BisoMallocedInline::BisoMallocedInline):
1731         (testBisoMallocedInline):
1732         (run):
1733         (main):
1734
1735 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
1736
1737         [ARM64][Linux] Re-enable Gigacage
1738         https://bugs.webkit.org/show_bug.cgi?id=178130
1739
1740         Reviewed by Michael Catanzaro.
1741
1742         * bmalloc/Gigacage.h: Re-enable Gigacage on ARM64 Linux.
1743
1744 2017-10-25  Commit Queue  <commit-queue@webkit.org>
1745
1746         Unreviewed, rolling out r222945.
1747         https://bugs.webkit.org/show_bug.cgi?id=178818
1748
1749         "It made WasmBench crash" (Requested by saamyjoon on #webkit).
1750
1751         Reverted changeset:
1752
1753         "bmalloc mutex should be adaptive"
1754         https://bugs.webkit.org/show_bug.cgi?id=177839
1755         https://trac.webkit.org/changeset/222945
1756
1757 2017-10-24  Zan Dobersek  <zdobersek@igalia.com>
1758
1759         [Linux] Enable Gigacage in x64 Linux environment
1760         https://bugs.webkit.org/show_bug.cgi?id=177745
1761         <rdar://problem/34773148>
1762
1763         Reviewed by Yusuke Suzuki.
1764
1765         Re-enable Gigacage on x86_64 Linux platforms after it was disabled in 223877.
1766
1767         The cause for the revert was problems with huge coredumps being generated
1768         while Gigacage was enabled. The feature virtually allocates about 80GB of
1769         memory at the beginning of the process lifetime. This is not a problem in
1770         itself since the memory range is marked as not needed through madvise(),
1771         but all this memory was still included upon core dump generation on Linux.
1772         Since there are reasonable limits enforced upon core dumps, these were
1773         being truncated every time, not yielding any useful information.
1774
1775         To avoid this, on Linux, invocations of madvise() with the MADV_NORMAL and
1776         MADV_DONTNEED advice parameters should be accompanied with respectively
1777         matching MADV_DODUMP and MADV_DONTDUMP madvise() calls. This correctly
1778         avoids core-dumping any memory that's not yet been physically allocated.
1779
1780         * bmalloc/Gigacage.h:
1781         * bmalloc/VMAllocate.h:
1782         (bmalloc::vmDeallocatePhysicalPages):
1783         (bmalloc::vmAllocatePhysicalPages):
1784
1785 2017-10-24  David Kilzer  <ddkilzer@apple.com>
1786
1787         Need to pass non-nil argument to SimulateCrash() in bmalloc::logVMFailure()
1788         <https://webkit.org/b/178740>
1789         <rdar://problem/35154943>
1790
1791         Reviewed by Saam Barati.
1792
1793         * bmalloc/BPlatform.h:
1794         (BUNUSED_PARAM): Define macro.
1795         * bmalloc/Logging.cpp:
1796         (SimulateCrash): Change third argument of SimulateCrash() to
1797         CFStringRef since it's an NSString * in Objective-C.
1798         (bmalloc::logVMFailure): Create a CFStringRef to use as a
1799         description string.  Use new vmSize parameter to log size.
1800         * bmalloc/Logging.h:
1801         (bmalloc::logVMFailure): Update function signature to take a
1802         size_t parameter representing vmSize.
1803         * bmalloc/VMAllocate.h:
1804         (bmalloc::tryVMAllocate): Pass vmSize into logVMFailure().
1805
1806 2017-10-23  Michael Catanzaro  <mcatanzaro@igalia.com>
1807
1808         Unreviewed, roll out r222731
1809         https://bugs.webkit.org/show_bug.cgi?id=177745
1810         <rdar://problem/34773148>
1811
1812         Unfortunately Gigacage has broken core dump generation.
1813
1814         * bmalloc/Gigacage.h:
1815
1816 2017-10-23  Zan Dobersek  <zdobersek@igalia.com>
1817
1818         bmalloc::api::tryLargeMemalignVirtual() shouldn't assert on a failed allocation
1819         https://bugs.webkit.org/show_bug.cgi?id=178654
1820
1821         Reviewed by Geoffrey Garen.
1822
1823         * bmalloc/bmalloc.h:
1824         (bmalloc::api::tryLargeMemalignVirtual): Call Heap::tryAllocateLarge()
1825         instead of Heap::allocateLarge(). The former will return a null pointer
1826         upon a failed allocation, allowing the caller to fail gracefully just as
1827         the API entrypoint implies, while the latter currently provokes a crash
1828         in these circumstances.
1829
1830 2017-10-19  Saam Barati  <sbarati@apple.com>
1831
1832         Runtime disable gigacage on iOS because it broke WasmBench
1833         https://bugs.webkit.org/show_bug.cgi?id=178556
1834
1835         Reviewed by Keith Miller.
1836
1837         * bmalloc/Gigacage.cpp:
1838         (Gigacage::shouldBeEnabled):
1839
1840 2017-10-17  Filip Pizlo  <fpizlo@apple.com>
1841
1842         You can't vmDeallocate null
1843         <rdar://problem/35038926>
1844
1845         Reviewed by Michael Saboff.
1846         
1847         After failing allocation, we would try to deallocate the thing we failed to allocate. The fix is to
1848         not try to deallocate something that is obviously null.
1849
1850         * bmalloc/Gigacage.cpp:
1851         (Gigacage::ensureGigacage):
1852
1853 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1854
1855         Enable gigacage on iOS
1856         https://bugs.webkit.org/show_bug.cgi?id=177586
1857
1858         Reviewed by JF Bastien.
1859         
1860         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1861         allocation fails, we free all of the gigacages and turn off gigacage support.
1862         
1863         Roll this back in after discussion.
1864
1865         * CMakeLists.txt:
1866         * bmalloc.xcodeproj/project.pbxproj:
1867         * bmalloc/Cache.cpp:
1868         (bmalloc::Cache::scavenge):
1869         * bmalloc/Cache.h:
1870         (bmalloc::Cache::tryAllocate):
1871         (bmalloc::Cache::allocate):
1872         (bmalloc::Cache::deallocate):
1873         (bmalloc::Cache::reallocate):
1874         * bmalloc/Gigacage.cpp:
1875         (Gigacage::ensureGigacage):
1876         (Gigacage::runway):
1877         (Gigacage::totalSize):
1878         (Gigacage::shouldBeEnabled):
1879         (): Deleted.
1880         (Gigacage::Callback::Callback): Deleted.
1881         (Gigacage::Callback::function): Deleted.
1882         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1883         * bmalloc/Gigacage.h:
1884         (Gigacage::wasEnabled):
1885         (Gigacage::isEnabled):
1886         (Gigacage::runway): Deleted.
1887         (Gigacage::totalSize): Deleted.
1888         * bmalloc/HeapKind.cpp: Added.
1889         (bmalloc::isActiveHeapKind):
1890         (bmalloc::mapToActiveHeapKind):
1891         * bmalloc/HeapKind.h:
1892         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1893         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1894         * bmalloc/Scavenger.cpp:
1895         (bmalloc::Scavenger::scavenge):
1896         * bmalloc/bmalloc.h:
1897         (bmalloc::api::tryLargeMemalignVirtual):
1898         (bmalloc::api::freeLargeVirtual):
1899         (bmalloc::api::isEnabled):
1900
1901 2017-10-11  Commit Queue  <commit-queue@webkit.org>
1902
1903         Unreviewed, rolling out r223113 and r223121.
1904         https://bugs.webkit.org/show_bug.cgi?id=178182
1905
1906         Reintroduced 20% regression on Kraken (Requested by rniwa on
1907         #webkit).
1908
1909         Reverted changesets:
1910
1911         "Enable gigacage on iOS"
1912         https://bugs.webkit.org/show_bug.cgi?id=177586
1913         https://trac.webkit.org/changeset/223113
1914
1915         "Use one virtual allocation for all gigacages and their
1916         runways"
1917         https://bugs.webkit.org/show_bug.cgi?id=178050
1918         https://trac.webkit.org/changeset/223121
1919
1920 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
1921
1922         Use one virtual allocation for all gigacages and their runways
1923         https://bugs.webkit.org/show_bug.cgi?id=178050
1924
1925         Reviewed by Saam Barati.
1926
1927         * bmalloc/Gigacage.cpp:
1928         (Gigacage::ensureGigacage):
1929         (Gigacage::runway): Deleted.
1930         (Gigacage::totalSize): Deleted.
1931         * bmalloc/Gigacage.h:
1932
1933 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1934
1935         Enable gigacage on iOS
1936         https://bugs.webkit.org/show_bug.cgi?id=177586
1937
1938         Reviewed by JF Bastien.
1939         
1940         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1941         allocation fails, we free all of the gigacages and turn off gigacage support.
1942         
1943         Reland this after confirming that the 20% Kraken regression was a one-bot fluke. Local testing on the
1944         same kind of system did not show the regression. Saam and I both tried independently.
1945
1946         * CMakeLists.txt:
1947         * bmalloc.xcodeproj/project.pbxproj:
1948         * bmalloc/Cache.cpp:
1949         (bmalloc::Cache::scavenge):
1950         * bmalloc/Cache.h:
1951         (bmalloc::Cache::tryAllocate):
1952         (bmalloc::Cache::allocate):
1953         (bmalloc::Cache::deallocate):
1954         (bmalloc::Cache::reallocate):
1955         * bmalloc/Gigacage.cpp:
1956         (Gigacage::ensureGigacage):
1957         (Gigacage::runway):
1958         (Gigacage::totalSize):
1959         (Gigacage::shouldBeEnabled):
1960         (): Deleted.
1961         (Gigacage::Callback::Callback): Deleted.
1962         (Gigacage::Callback::function): Deleted.
1963         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1964         * bmalloc/Gigacage.h:
1965         (Gigacage::wasEnabled):
1966         (Gigacage::isEnabled):
1967         (Gigacage::runway): Deleted.
1968         (Gigacage::totalSize): Deleted.
1969         * bmalloc/HeapKind.cpp: Added.
1970         (bmalloc::isActiveHeapKind):
1971         (bmalloc::mapToActiveHeapKind):
1972         * bmalloc/HeapKind.h:
1973         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1974         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1975         * bmalloc/Scavenger.cpp:
1976         (bmalloc::Scavenger::scavenge):
1977         * bmalloc/bmalloc.h:
1978         (bmalloc::api::tryLargeMemalignVirtual):
1979         (bmalloc::api::freeLargeVirtual):
1980         (bmalloc::api::isEnabled):
1981
1982 2017-10-09  Commit Queue  <commit-queue@webkit.org>
1983
1984         Unreviewed, rolling out r223015 and r223025.
1985         https://bugs.webkit.org/show_bug.cgi?id=178093
1986
1987         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
1988         #webkit).
1989
1990         Reverted changesets:
1991
1992         "Enable gigacage on iOS"
1993         https://bugs.webkit.org/show_bug.cgi?id=177586
1994         http://trac.webkit.org/changeset/223015
1995
1996         "Unreviewed, disable Gigacage on ARM64 Linux"
1997         https://bugs.webkit.org/show_bug.cgi?id=177586
1998         http://trac.webkit.org/changeset/223025
1999
2000 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2001
2002         Unreviewed, disable Gigacage on ARM64 Linux
2003         https://bugs.webkit.org/show_bug.cgi?id=177586
2004
2005         Gigacage's LLInt change breaks ARM64 Linux.
2006         Currently we do not have maintainers for this.
2007         Let's simply disable it.
2008
2009         * bmalloc/Gigacage.h:
2010
2011 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2012
2013         Enable gigacage on iOS
2014         https://bugs.webkit.org/show_bug.cgi?id=177586
2015
2016         Reviewed by JF Bastien.
2017         
2018         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
2019         allocation fails, we free all of the gigacages and turn off gigacage support.
2020
2021         * CMakeLists.txt:
2022         * bmalloc.xcodeproj/project.pbxproj:
2023         * bmalloc/Cache.cpp:
2024         (bmalloc::Cache::scavenge):
2025         * bmalloc/Cache.h:
2026         (bmalloc::Cache::tryAllocate):
2027         (bmalloc::Cache::allocate):
2028         (bmalloc::Cache::deallocate):
2029         (bmalloc::Cache::reallocate):
2030         * bmalloc/Gigacage.cpp:
2031         (Gigacage::ensureGigacage):
2032         (Gigacage::runway):
2033         (Gigacage::totalSize):
2034         (Gigacage::shouldBeEnabled):
2035         (): Deleted.
2036         (Gigacage::Callback::Callback): Deleted.
2037         (Gigacage::Callback::function): Deleted.
2038         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
2039         * bmalloc/Gigacage.h:
2040         (Gigacage::wasEnabled):
2041         (Gigacage::isEnabled):
2042         (Gigacage::runway): Deleted.
2043         (Gigacage::totalSize): Deleted.
2044         * bmalloc/HeapKind.cpp: Added.
2045         (bmalloc::isActiveHeapKind):
2046         (bmalloc::mapToActiveHeapKind):
2047         * bmalloc/HeapKind.h:
2048         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
2049         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
2050         * bmalloc/Scavenger.cpp:
2051         (bmalloc::Scavenger::scavenge):
2052         * bmalloc/bmalloc.h:
2053         (bmalloc::api::tryLargeMemalignVirtual):
2054         (bmalloc::api::freeLargeVirtual):
2055         (bmalloc::api::isEnabled):
2056
2057 2017-10-05  Filip Pizlo  <fpizlo@apple.com>
2058
2059         Use one Scavenger thread for all Heaps
2060         https://bugs.webkit.org/show_bug.cgi?id=174973
2061
2062         Reviewed by JF Bastien.
2063         
2064         This combines the scavengers from all Heap instances into a single scavenger. It also combines
2065         the accounting for deciding when to run. Each Heap still controls what it means to scavenge
2066         itself (it's all in Heap::scavenge) but the policy decisions are all controlled by Scavenger.
2067         Because Scavenger is also the only thing that needs an AsyncTask, this removes AsyncTask and
2068         moves all of AsyncTask's logic into Scavenger.
2069         
2070         This appears to be a 1% progression on JetStream (with high statistical confidence: p = 0.0049).
2071
2072         * bmalloc.xcodeproj/project.pbxproj:
2073         * bmalloc/AsyncTask.h: Removed.
2074         * bmalloc/Heap.cpp:
2075         (bmalloc::Heap::Heap):
2076         (bmalloc::Heap::allocateSmallChunk):
2077         (bmalloc::Heap::allocateSmallPage):
2078         (bmalloc::Heap::deallocateSmallLine):
2079         (bmalloc::Heap::splitAndAllocate):
2080         (bmalloc::Heap::tryAllocateLarge):
2081         (bmalloc::Heap::shrinkLarge):
2082         (bmalloc::Heap::deallocateLarge):
2083         (bmalloc::Heap::concurrentScavenge): Deleted.
2084         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Deleted.
2085         (bmalloc::Heap::scheduleScavenger): Deleted.
2086         * bmalloc/Heap.h:
2087         * bmalloc/Scavenger.cpp:
2088         (bmalloc::Scavenger::Scavenger):
2089         (bmalloc::Scavenger::run):
2090         (bmalloc::Scavenger::runHoldingLock):
2091         (bmalloc::Scavenger::runSoon):
2092         (bmalloc::Scavenger::runSoonHoldingLock):
2093         (bmalloc::Scavenger::didStartGrowing):
2094         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
2095         (bmalloc::Scavenger::scheduleIfUnderMemoryPressureHoldingLock):
2096         (bmalloc::Scavenger::schedule):
2097         (bmalloc::Scavenger::threadEntryPoint):
2098         (bmalloc::Scavenger::threadRunLoop):
2099         (bmalloc::Scavenger::setSelfQOSClass):
2100         * bmalloc/Scavenger.h:
2101         (bmalloc::Scavenger::willRun):
2102         (bmalloc::Scavenger::willRunSoon):
2103
2104 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
2105
2106         bmalloc mutex should be adaptive
2107         https://bugs.webkit.org/show_bug.cgi?id=177839
2108
2109         Reviewed by Michael Saboff.
2110         
2111         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
2112         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
2113         anything other than malloc.
2114
2115         Reland after fixing ancient WordLock bug: the notify_one has to happen with the lock held
2116         to ensure it doesn't run after that thread has died.
2117
2118         * bmalloc/Algorithm.h:
2119         (bmalloc::compareExchangeWeak):
2120         (bmalloc::compareExchangeStrong):
2121         * bmalloc/PerThread.h:
2122         * bmalloc/StaticMutex.cpp:
2123         (bmalloc::StaticMutex::lockSlow):
2124         (bmalloc::StaticMutex::unlockSlow):
2125         (bmalloc::StaticMutex::lockSlowCase): Deleted.
2126         * bmalloc/StaticMutex.h:
2127         (bmalloc::StaticMutex::try_lock):
2128         (bmalloc::StaticMutex::isLocked const):
2129         (bmalloc::StaticMutex::init):
2130         (bmalloc::StaticMutex::tryLock):
2131         (bmalloc::StaticMutex::lock):
2132         (bmalloc::StaticMutex::unlock):
2133         (bmalloc::sleep): Deleted.
2134         (bmalloc::waitUntilFalse): Deleted.
2135
2136 2017-10-05  Matt Lewis  <jlewis3@apple.com>
2137
2138         Unreviewed, rolling out r222893.
2139
2140         This caused multiple API failures.
2141
2142         Reverted changeset:
2143
2144         "bmalloc mutex should be adaptive"
2145         https://bugs.webkit.org/show_bug.cgi?id=177839
2146         http://trac.webkit.org/changeset/222893
2147
2148 2017-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2149
2150         [Linux] Port MallocBench
2151         https://bugs.webkit.org/show_bug.cgi?id=177856
2152
2153         Reviewed by Filip Pizlo.
2154
2155         * CMakeLists.txt:
2156
2157 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
2158
2159         bmalloc mutex should be adaptive
2160         https://bugs.webkit.org/show_bug.cgi?id=177839
2161
2162         Reviewed by Michael Saboff.
2163         
2164         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
2165         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
2166         anything other than malloc.
2167
2168         * bmalloc/Algorithm.h:
2169         (bmalloc::compareExchangeWeak):
2170         (bmalloc::compareExchangeStrong):
2171         * bmalloc/PerThread.h:
2172         * bmalloc/StaticMutex.cpp:
2173         (bmalloc::StaticMutex::lockSlow):
2174         (bmalloc::StaticMutex::unlockSlow):
2175         (bmalloc::StaticMutex::lockSlowCase): Deleted.
2176         * bmalloc/StaticMutex.h:
2177         (bmalloc::StaticMutex::try_lock):
2178         (bmalloc::StaticMutex::isLocked const):
2179         (bmalloc::StaticMutex::init):
2180         (bmalloc::StaticMutex::tryLock):
2181         (bmalloc::StaticMutex::lock):
2182         (bmalloc::StaticMutex::unlock):
2183         (bmalloc::sleep): Deleted.
2184         (bmalloc::waitUntilFalse): Deleted.
2185
2186 2017-10-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2187
2188         [Linux] Enable Gigacage in x64 Linux environment
2189         https://bugs.webkit.org/show_bug.cgi?id=177745
2190
2191         Reviewed by Carlos Garcia Campos.
2192
2193         This patch enables Gigacage in x64 Linux environment.
2194         Gigacage enforces a caged pointer to reference to the
2195         specific memory region. This reduces the effectiveness
2196         of some types of attacks setting a pointer to ArrayBuffer
2197         and modifying arbitrary memory region.
2198
2199         * bmalloc/Gigacage.h:
2200
2201 2017-09-29  Commit Queue  <commit-queue@webkit.org>
2202
2203         Unreviewed, rolling out r222625.
2204         https://bugs.webkit.org/show_bug.cgi?id=177664
2205
2206         causes crashes on iOS (Requested by pizlo-mbp on #webkit).
2207
2208         Reverted changeset:
2209
2210         "Enable gigacage on iOS"
2211         https://bugs.webkit.org/show_bug.cgi?id=177586
2212         http://trac.webkit.org/changeset/222625
2213
2214 2017-09-28  Filip Pizlo  <fpizlo@apple.com>
2215
2216         Enable gigacage on iOS
2217         https://bugs.webkit.org/show_bug.cgi?id=177586
2218
2219         Reviewed by Michael Saboff.
2220         
2221         This enables Gigacage on iOS using a much smaller cage size. It's not necessary for it to be so
2222         small, but this is a good conservative starting point to start to exercise the code.
2223
2224         * bmalloc/Gigacage.h:
2225
2226 2017-09-26  Filip Pizlo  <fpizlo@apple.com>
2227
2228         Put g_gigacageBasePtr into its own page and make it read-only
2229         https://bugs.webkit.org/show_bug.cgi?id=174972
2230
2231         Reviewed by Michael Saboff.
2232         
2233         This puts the gigacage base pointers into their own page and makes that page read-only.
2234
2235         * bmalloc/Gigacage.cpp:
2236         (Gigacage::ensureGigacage):
2237         (Gigacage::disablePrimitiveGigacage):
2238         (Gigacage::addPrimitiveDisableCallback):
2239         * bmalloc/Gigacage.h:
2240         (Gigacage::basePtr):
2241         (Gigacage::basePtrs):
2242
2243 2017-09-04  Adrian Perez de Castro  <aperez@igalia.com>
2244
2245         Unreviewed build fix for Clang with libc++
2246
2247         Fixes a build failure when building with Clang, -stdlib=libc++, and gigacage
2248         support enabled, which resulted in "stderr" being undefined.
2249
2250         * bmalloc/Gigacage.cpp: Add missing <ctsdio> include to pull the definition.
2251
2252 2017-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2253
2254         Large virtual memory region allocation requires MMAP_NORESERVE in Linux
2255         https://bugs.webkit.org/show_bug.cgi?id=176211
2256
2257         Reviewed by Geoffrey Garen.
2258
2259         In Linux, we cannot allocate very large memory region without MMAP_NORESERVE.
2260         Linux kernel needs to reserve swap area for allocated memory region. If the
2261         swap area is exhausted, kernel fails to allocate the memory region with ENOMEM.
2262
2263         This patch adds MMAP_NORESERVE to mmap flags in Linux. By adding this flag,
2264         mmap does not need to reserve swap area for the reserved memory region.
2265         This allows us to reserve very large memory region that is necessary for Gigacage.
2266
2267         * bmalloc/BPlatform.h:
2268         * bmalloc/VMAllocate.h:
2269         (bmalloc::tryVMAllocate):
2270
2271 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
2272
2273         Strings need to be in some kind of gigacage
2274         https://bugs.webkit.org/show_bug.cgi?id=174924
2275
2276         Reviewed by Oliver Hunt.
2277         
2278         This adds a StringGigacage.
2279
2280         * bmalloc/Gigacage.cpp:
2281         * bmalloc/Gigacage.h:
2282         (Gigacage::name):
2283         (Gigacage::basePtr):
2284         (Gigacage::forEachKind):
2285         * bmalloc/HeapKind.h:
2286         (bmalloc::isGigacage):
2287         (bmalloc::gigacageKind):
2288         (bmalloc::heapKind):
2289
2290 2017-08-30  Matt Lewis  <jlewis3@apple.com>
2291
2292         Unreviewed, rolling out r221384.
2293
2294         This patch caused multiple 32-bit JSC test failures.
2295
2296         Reverted changeset:
2297
2298         "Strings need to be in some kind of gigacage"
2299         https://bugs.webkit.org/show_bug.cgi?id=174924
2300         http://trac.webkit.org/changeset/221384
2301
2302 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
2303
2304         Strings need to be in some kind of gigacage
2305         https://bugs.webkit.org/show_bug.cgi?id=174924
2306
2307         Reviewed by Oliver Hunt.
2308         
2309         This adds a StringGigacage.
2310
2311         * bmalloc/Gigacage.cpp:
2312         * bmalloc/Gigacage.h:
2313         (Gigacage::name):
2314         (Gigacage::basePtr):
2315         (Gigacage::forEachKind):
2316         * bmalloc/HeapKind.h:
2317         (bmalloc::isGigacage):
2318         (bmalloc::gigacageKind):
2319         (bmalloc::heapKind):
2320
2321 2017-08-25  Daniel Bates  <dabates@apple.com>
2322
2323         Demarcate code added due to lack of NSDMI for aggregates
2324         https://bugs.webkit.org/show_bug.cgi?id=175990
2325
2326         Reviewed by Andy Estes.
2327
2328         * bmalloc/BPlatform.h:
2329         * bmalloc/List.h: Be explicit when initializing m_node to improve readability.
2330         (bmalloc::ListNode::ListNode):
2331
2332 2017-08-23  Filip Pizlo  <fpizlo@apple.com>
2333
2334         Reduce Gigacage sizes
2335         https://bugs.webkit.org/show_bug.cgi?id=175920
2336
2337         Reviewed by Mark Lam.
2338
2339         This introduces the ability to have different gigacage sizes for different gigacages, and uses it to reduce the size of both
2340         gigacages, but to different extents: Primitive gets 32GB with a 16GB runway and JSValue gets 16GB.
2341
2342         This is a ~10% membuster progression on my Mac Pro.
2343
2344         * bmalloc/Gigacage.cpp:
2345         (Gigacage::ensureGigacage):
2346         * bmalloc/Gigacage.h:
2347         (Gigacage::size):
2348         (Gigacage::alignment):
2349         (Gigacage::mask):
2350         (Gigacage::runway):
2351         (Gigacage::totalSize):
2352         (Gigacage::caged):
2353         * bmalloc/Heap.cpp:
2354         (bmalloc::Heap::Heap):
2355         (bmalloc::Heap::gigacageSize):
2356         * bmalloc/Heap.h:
2357
2358 2017-08-08  Filip Pizlo  <fpizlo@apple.com>
2359
2360         Baseline JIT should do caging
2361         https://bugs.webkit.org/show_bug.cgi?id=175037
2362
2363         Reviewed by Mark Lam.
2364         
2365         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
2366         and WebProcess.
2367         
2368         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
2369         checks on each typed array access.
2370
2371         * bmalloc/Gigacage.cpp:
2372         (Gigacage::primitiveGigacageDisabled):
2373         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2374         (Gigacage::isDisablingPrimitiveGigacageDisabled):
2375         * bmalloc/Gigacage.h:
2376         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
2377         (Gigacage::canPrimitiveGigacageBeDisabled):
2378
2379 2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>
2380
2381         Unreviewed, rolling out r220368.
2382
2383         This change caused WK1 tests to exit early with crashes.
2384
2385         Reverted changeset:
2386
2387         "Baseline JIT should do caging"
2388         https://bugs.webkit.org/show_bug.cgi?id=175037
2389         http://trac.webkit.org/changeset/220368
2390
2391 2017-08-07  Filip Pizlo  <fpizlo@apple.com>
2392
2393         Baseline JIT should do caging
2394         https://bugs.webkit.org/show_bug.cgi?id=175037
2395
2396         Reviewed by Mark Lam.
2397         
2398         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
2399         and WebProcess.
2400         
2401         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
2402         checks on each typed array access.
2403
2404         * bmalloc/Gigacage.cpp:
2405         (Gigacage::primitiveGigacageDisabled):
2406         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
2407         (Gigacage::isDisablingPrimitiveGigacageDisabled):
2408         * bmalloc/Gigacage.h:
2409         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
2410         (Gigacage::canPrimitiveGigacageBeDisabled):
2411
2412 2017-08-06  Filip Pizlo  <fpizlo@apple.com>
2413
2414         Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
2415         https://bugs.webkit.org/show_bug.cgi?id=174919
2416
2417         Reviewed by Keith Miller.
2418         
2419         This introduces two kinds of Gigacage, Primitive and JSValue. This translates to two kinds of
2420         HeapKind, PrimitiveGigacage and JSValueGigacage.
2421         
2422         The new support functionality required turning Inline.h into BInline.h, and INLINE into BINLINE, and
2423         NO_INLINE into BNO_INLINE.
2424
2425         * bmalloc.xcodeproj/project.pbxproj:
2426         * bmalloc/Allocator.cpp:
2427         (bmalloc::Allocator::refillAllocatorSlowCase):
2428         (bmalloc::Allocator::refillAllocator):
2429         (bmalloc::Allocator::allocateLarge):
2430         (bmalloc::Allocator::allocateLogSizeClass):
2431         * bmalloc/AsyncTask.h:
2432         * bmalloc/BInline.h: Copied from Source/bmalloc/bmalloc/Inline.h.
2433         * bmalloc/Cache.cpp:
2434         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2435         (bmalloc::Cache::allocateSlowCaseNullCache):
2436         (bmalloc::Cache::deallocateSlowCaseNullCache):
2437         (bmalloc::Cache::reallocateSlowCaseNullCache):
2438         * bmalloc/Deallocator.cpp:
2439         * bmalloc/Gigacage.cpp:
2440         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
2441         (Gigacage::ensureGigacage):
2442         (Gigacage::disablePrimitiveGigacage):
2443         (Gigacage::addPrimitiveDisableCallback):
2444         (Gigacage::removePrimitiveDisableCallback):
2445         (Gigacage::Callbacks::Callbacks): Deleted.
2446         (Gigacage::disableGigacage): Deleted.
2447         (Gigacage::addDisableCallback): Deleted.
2448         (Gigacage::removeDisableCallback): Deleted.
2449         * bmalloc/Gigacage.h:
2450         (Gigacage::name):
2451         (Gigacage::basePtr):
2452         (Gigacage::forEachKind):
2453         (Gigacage::caged):
2454         (Gigacage::isCaged):
2455         * bmalloc/Heap.cpp:
2456         (bmalloc::Heap::Heap):
2457         (bmalloc::Heap::usingGigacage):
2458         (bmalloc::Heap::gigacageBasePtr):
2459         * bmalloc/Heap.h:
2460         * bmalloc/HeapKind.h:
2461         (bmalloc::isGigacage):
2462         (bmalloc::gigacageKind):
2463         (bmalloc::heapKind):
2464         * bmalloc/Inline.h: Removed.
2465         * bmalloc/Map.h:
2466         * bmalloc/PerProcess.h:
2467         (bmalloc::PerProcess<T>::getFastCase):
2468         (bmalloc::PerProcess<T>::get):
2469         (bmalloc::PerProcess<T>::getSlowCase):
2470         * bmalloc/PerThread.h:
2471         (bmalloc::PerThread<T>::getFastCase):
2472         * bmalloc/Vector.h:
2473         (bmalloc::Vector<T>::push):
2474         (bmalloc::Vector<T>::shrinkCapacity):
2475         (bmalloc::Vector<T>::growCapacity):
2476
2477 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
2478
2479         If Gigacage is disabled, bmalloc should service large aligned memory allocation requests through vmAllocate
2480         https://bugs.webkit.org/show_bug.cgi?id=175085
2481
2482         Reviewed by Saam Barati.
2483         
2484         This fixes a problem where if we used gmalloc, WebAssembly memory allocations would still use
2485         bmalloc's large allocator.
2486         
2487         We want to use the page allocator for those "large" allocations when the Gigacage is disabled.
2488
2489         * bmalloc/DebugHeap.cpp:
2490         (bmalloc::DebugHeap::DebugHeap):
2491         (bmalloc::DebugHeap::memalignLarge):
2492         (bmalloc::DebugHeap::freeLarge):
2493         * bmalloc/DebugHeap.h:
2494         * bmalloc/Heap.cpp:
2495         (bmalloc::Heap::tryAllocateLarge):
2496         (bmalloc::Heap::deallocateLarge):
2497
2498 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
2499
2500         We should be OK with the gigacage being disabled on gmalloc
2501         https://bugs.webkit.org/show_bug.cgi?id=175082
2502
2503         Reviewed by Michael Saboff.
2504         
2505         This adds Gigacage::shouldBeEnabled(), which returns false when we're using gmalloc or other things
2506         that enable DebugHeap.
2507
2508         * bmalloc/Environment.cpp:
2509         (bmalloc::Environment::Environment):
2510         * bmalloc/Environment.h:
2511         * bmalloc/Gigacage.cpp:
2512         (Gigacage::ensureGigacage):
2513         (Gigacage::shouldBeEnabled):
2514         * bmalloc/Gigacage.h:
2515         * bmalloc/Heap.cpp:
2516         (bmalloc::Heap::Heap):
2517         * bmalloc/Heap.h:
2518
2519 2017-08-01  Filip Pizlo  <fpizlo@apple.com>
2520
2521         Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
2522         https://bugs.webkit.org/show_bug.cgi?id=174727
2523
2524         Reviewed by Mark Lam.
2525         
2526         This adds a mechanism for managing multiple isolated heaps in bmalloc. For now, these isoheaps
2527         (isolated heaps) have a very simple relationship with each other and with the rest of bmalloc:
2528         
2529         - You have to choose how many isoheaps you will have statically. See numHeaps in HeapKind.h.
2530         
2531         - Because numHeaps is static, each isoheap gets fast thread-local allocation. Basically, we have a
2532           Cache for each heap kind.
2533         
2534         - Each isoheap gets its own Heap.
2535         
2536         - Each Heap gets a scavenger thread.
2537         
2538         - Some things, like Zone/VMHeap/Scavenger, are per-process.
2539         
2540         Most of the per-HeapKind functionality is handled by PerHeapKind<>.
2541         
2542         This approach is ideal for supporting special per-HeapKind behaviors. For now we have two heaps:
2543         the Primary heap for normal malloc and the Gigacage. The gigacage is a 64GB-aligned 64GB virtual
2544         region that we now use for variable-length random-access allocations. No Primary allocations will
2545         go into the Gigacage.
2546
2547         * CMakeLists.txt:
2548         * bmalloc.xcodeproj/project.pbxproj:
2549         * bmalloc/AllocationKind.h: Added.
2550         * bmalloc/Allocator.cpp:
2551         (bmalloc::Allocator::Allocator):
2552         (bmalloc::Allocator::tryAllocate):
2553         (bmalloc::Allocator::allocateImpl):
2554         (bmalloc::Allocator::reallocate):
2555         (bmalloc::Allocator::refillAllocatorSlowCase):
2556         (bmalloc::Allocator::allocateLarge):
2557         * bmalloc/Allocator.h:
2558         * bmalloc/BExport.h: Added.
2559         * bmalloc/Cache.cpp:
2560         (bmalloc::Cache::scavenge):
2561         (bmalloc::Cache::Cache):
2562         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2563         (bmalloc::Cache::allocateSlowCaseNullCache):
2564         (bmalloc::Cache::deallocateSlowCaseNullCache):
2565         (bmalloc::Cache::reallocateSlowCaseNullCache):
2566         (bmalloc::Cache::operator new): Deleted.
2567         (bmalloc::Cache::operator delete): Deleted.
2568         * bmalloc/Cache.h:
2569         (bmalloc::Cache::tryAllocate):
2570         (bmalloc::Cache::allocate):
2571         (bmalloc::Cache::deallocate):
2572         (bmalloc::Cache::reallocate):
2573         * bmalloc/Deallocator.cpp:
2574         (bmalloc::Deallocator::Deallocator):
2575         (bmalloc::Deallocator::scavenge):
2576         (bmalloc::Deallocator::processObjectLog):
2577         (bmalloc::Deallocator::deallocateSlowCase):
2578         * bmalloc/Deallocator.h:
2579         * bmalloc/Gigacage.cpp: Added.
2580         (Gigacage::Callback::Callback):
2581         (Gigacage::Callback::function):
2582         (Gigacage::Callbacks::Callbacks):
2583         (Gigacage::ensureGigacage):
2584         (Gigacage::disableGigacage):
2585         (Gigacage::addDisableCallback):
2586         (Gigacage::removeDisableCallback):
2587         * bmalloc/Gigacage.h: Added.
2588         (Gigacage::caged):
2589         (Gigacage::isCaged):
2590         * bmalloc/Heap.cpp:
2591         (bmalloc::Heap::Heap):
2592         (bmalloc::Heap::usingGigacage):
2593         (bmalloc::Heap::concurrentScavenge):
2594         (bmalloc::Heap::splitAndAllocate):
2595         (bmalloc::Heap::tryAllocateLarge):
2596         (bmalloc::Heap::allocateLarge):
2597         (bmalloc::Heap::shrinkLarge):
2598         (bmalloc::Heap::deallocateLarge):
2599         * bmalloc/Heap.h:
2600         (bmalloc::Heap::mutex):
2601         (bmalloc::Heap::kind const):
2602         (bmalloc::Heap::setScavengerThreadQOSClass): Deleted.
2603         * bmalloc/HeapKind.h: Added.
2604         * bmalloc/ObjectType.cpp:
2605         (bmalloc::objectType):
2606         * bmalloc/ObjectType.h:
2607         * bmalloc/PerHeapKind.h: Added.
2608         (bmalloc::PerHeapKindBase::PerHeapKindBase):
2609         (bmalloc::PerHeapKindBase::size):
2610         (bmalloc::PerHeapKindBase::at):
2611         (bmalloc::PerHeapKindBase::at const):
2612         (bmalloc::PerHeapKindBase::operator[]):
2613         (bmalloc::PerHeapKindBase::operator[] const):
2614         (bmalloc::StaticPerHeapKind::StaticPerHeapKind):
2615         (bmalloc::PerHeapKind::PerHeapKind):
2616         (bmalloc::PerHeapKind::~PerHeapKind):
2617         * bmalloc/PerThread.h:
2618         (bmalloc::PerThread<T>::destructor):
2619         (bmalloc::PerThread<T>::getSlowCase):
2620         (bmalloc::PerThreadStorage<Cache>::get): Deleted.
2621         (bmalloc::PerThreadStorage<Cache>::init): Deleted.
2622         * bmalloc/Scavenger.cpp: Added.
2623         (bmalloc::Scavenger::Scavenger):
2624         (bmalloc::Scavenger::scavenge):
2625         * bmalloc/Scavenger.h: Added.
2626         (bmalloc::Scavenger::setScavengerThreadQOSClass):
2627         (bmalloc::Scavenger::requestedScavengerThreadQOSClass const):
2628         * bmalloc/VMHeap.cpp:
2629         (bmalloc::VMHeap::VMHeap):
2630         (bmalloc::VMHeap::tryAllocateLargeChunk):
2631         * bmalloc/VMHeap.h:
2632         * bmalloc/Zone.cpp:
2633         (bmalloc::Zone::Zone):
2634         * bmalloc/Zone.h:
2635         * bmalloc/bmalloc.h:
2636         (bmalloc::api::tryMalloc):
2637         (bmalloc::api::malloc):
2638         (bmalloc::api::tryMemalign):
2639         (bmalloc::api::memalign):
2640         (bmalloc::api::realloc):
2641         (bmalloc::api::tryLargeMemalignVirtual):
2642         (bmalloc::api::free):
2643         (bmalloc::api::freeLargeVirtual):
2644         (bmalloc::api::scavengeThisThread):
2645         (bmalloc::api::scavenge):
2646         (bmalloc::api::isEnabled):
2647         (bmalloc::api::setScavengerThreadQOSClass):
2648         * bmalloc/mbmalloc.cpp:
2649
2650 2017-08-01  Daewoong Jang  <daewoong.jang@navercorp.com>
2651
2652         Implement __builtin_clzl for MSVC
2653         https://bugs.webkit.org/show_bug.cgi?id=174232
2654
2655         Reviewed by Geoffrey Garen.
2656
2657         * bmalloc/Algorithm.h:
2658         (bmalloc::clzl):
2659         (bmalloc::clzl<1>):
2660         (bmalloc::__builtin_clzl):
2661         * bmalloc/BPlatform.h:
2662
2663 2017-07-31  Mark Lam  <mark.lam@apple.com>
2664
2665         Fixed some comment typos.
2666
2667         Not reviewed.
2668
2669         * bmalloc/PerProcess.h:
2670
2671 2017-07-14  Filip Pizlo  <fpizlo@apple.com>
2672
2673         It should be easy to decide how WebKit yields
2674         https://bugs.webkit.org/show_bug.cgi?id=174298
2675
2676         Reviewed by Saam Barati.
2677         
2678         Use sched_yield() explicitly.
2679
2680         * bmalloc/StaticMutex.cpp:
2681         (bmalloc::StaticMutex::lockSlowCase):
2682
2683 2017-07-20  Chris Dumez  <cdumez@apple.com>
2684
2685         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
2686         https://bugs.webkit.org/show_bug.cgi?id=174660
2687
2688         Reviewed by Geoffrey Garen.
2689
2690         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
2691         This essentially replaces a branch to figure out if the new size is less or greater than the
2692         current size by an assertion.
2693
2694         * bmalloc/Map.h:
2695         (bmalloc::Hash>::rehash):
2696
2697 2017-07-18  Andy Estes  <aestes@apple.com>
2698
2699         [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
2700         https://bugs.webkit.org/show_bug.cgi?id=174631
2701
2702         Reviewed by Tim Horton.
2703
2704         * Configurations/Base.xcconfig:
2705
2706 2017-07-18  Andy Estes  <aestes@apple.com>
2707
2708         [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
2709         https://bugs.webkit.org/show_bug.cgi?id=174631
2710
2711         Reviewed by Sam Weinig.
2712
2713         * Configurations/Base.xcconfig:
2714
2715 2017-07-18  Andy Estes  <aestes@apple.com>
2716
2717         [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
2718         https://bugs.webkit.org/show_bug.cgi?id=174631
2719
2720         Reviewed by Dan Bernstein.
2721
2722         * Configurations/Base.xcconfig:
2723
2724 2017-07-18  Andy Estes  <aestes@apple.com>
2725
2726         [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
2727         https://bugs.webkit.org/show_bug.cgi?id=174631
2728
2729         Reviewed by Darin Adler.
2730
2731         * Configurations/Base.xcconfig:
2732
2733 2017-07-12  Adrian Perez de Castro  <aperez@igalia.com>
2734
2735         bmalloc: Failure to build when the compiler specifically targets ARMv8-A / defines __ARM_ARCH_8A__
2736         https://bugs.webkit.org/show_bug.cgi?id=174424
2737
2738         Reviewed by Michael Catanzaro.
2739
2740         * bmalloc/BPlatform.h: Also check for __ARCH_ARM_8A__ to detect ARMv8.
2741
2742 2017-07-05  Daewoong Jang  <daewoong.jang@navercorp.com>
2743
2744         reinterpret_cast does not evaluate to constexpr
2745         https://bugs.webkit.org/show_bug.cgi?id=173622
2746
2747         Reviewed by Yusuke Suzuki.
2748
2749         * bmalloc/Algorithm.h:
2750         (bmalloc::mask):
2751         (bmalloc::roundUpToMultipleOf):
2752
2753 2017-07-03  Andy Estes  <aestes@apple.com>
2754
2755         [Xcode] Add an experimental setting to build with ccache
2756         https://bugs.webkit.org/show_bug.cgi?id=173875
2757
2758         Reviewed by Tim Horton.
2759
2760         * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.
2761
2762 2017-07-01  Dan Bernstein  <mitz@apple.com>
2763
2764         [iOS] Remove code only needed when building for iOS 9.x
2765         https://bugs.webkit.org/show_bug.cgi?id=174068
2766
2767         Reviewed by Tim Horton.
2768
2769         * bmalloc/BPlatform.h:
2770         * bmalloc/VMAllocate.h:
2771         (bmalloc::vmPageSizePhysical):
2772
2773 2017-07-01  Dan Bernstein  <mitz@apple.com>
2774
2775         [macOS] Remove code only needed when building for OS X Yosemite
2776         https://bugs.webkit.org/show_bug.cgi?id=174067
2777
2778         Reviewed by Tim Horton.
2779
2780         * Configurations/Base.xcconfig:
2781         * Configurations/DebugRelease.xcconfig:
2782
2783 2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>
2784
2785         Ran sort-Xcode-project-file.
2786
2787         * bmalloc.xcodeproj/project.pbxproj:
2788
2789 2017-06-19  Geoffrey Garen  <ggaren@apple.com>
2790
2791         bmalloc: Add a per-thread line cache
2792         https://bugs.webkit.org/show_bug.cgi?id=173552
2793
2794         Reviewed by Darin Adler.
2795
2796         Previously, any thread could allocate out of any page with free lines.
2797         Now, the first thread to free a line in a page owns that page's free
2798         lines until the whole page becomes free.
2799
2800         This patch is a big speedup on multi-threaded benchmarks.
2801         tree_churn --parallel gets 14% faster on a 2-core (4-hyper-core) MacBook
2802         Air and 2.85X faster on 12-core (24-hyper-core) Mac Pro. Other parallel
2803         benchmarks show significant but smaller speedups.
2804
2805         Thread affinity is a great predictor of object lifetime. The per-thread
2806         line cache avoids the pathology of shuffling pages between threads,
2807         turning predictable lifetimes into unpredictable lifetimes, increasing
2808         fragmentation. On tree_churn --parallel, the per-thread line cache
2809         increases free memory found per page scanned by 2.85X.
2810
2811         Free line scanning in fragmented pages is pretty expensive relative to
2812         other allocate / initialize / free operations. According to Instruments,
2813         on tree_churn --parallel, scanning is about 10X more expensive than
2814         freeing. This explains why a 2.85X improvement in scanning efficiency
2815         translates into a 2.85X overall speedup on tree_churn --parallel.
2816
2817         * bmalloc/Allocator.cpp:
2818         (bmalloc::Allocator::refillAllocatorSlowCase): Pass through our line
2819         cache so the Heap can fill it.
2820
2821         * bmalloc/Deallocator.cpp:
2822         (bmalloc::Deallocator::scavenge): Scavenge our line cache.
2823
2824         (bmalloc::Deallocator::processObjectLog): Deleted.
2825
2826         * bmalloc/Deallocator.h:
2827         (bmalloc::Deallocator::lineCache): Added a line cache.
2828
2829         * bmalloc/Heap.cpp:
2830         (bmalloc::Heap::deallocateLineCache): Deallocation function for thread
2831         destruction.
2832
2833         (bmalloc::Heap::allocateSmallPage):
2834         (bmalloc::Heap::deallocateSmallLine):
2835         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2836         (bmalloc::Heap::allocateSmallBumpRangesByObject): Consult the new per-thread line
2837         cache for allocation and deallocation.
2838
2839         * bmalloc/Heap.h:
2840         (bmalloc::Heap::allocateSmallBumpRanges):
2841         (bmalloc::Heap::derefSmallLine):
2842
2843         * bmalloc/List.h:
2844         (bmalloc::List::remove): Remove has always been a logically static
2845         operation. Declare it static now so that the Heap can remove a page from
2846         a thread's line cache without holding a direct pointer to the cache.
2847
2848         * bmalloc/SmallPage.h:
2849
2850 2017-06-10  Dan Bernstein  <mitz@apple.com>
2851
2852         Reverted r218056 because it made the IDE reindex constantly.
2853
2854         * Configurations/DebugRelease.xcconfig:
2855
2856 2017-06-10  Dan Bernstein  <mitz@apple.com>
2857
2858         [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
2859         https://bugs.webkit.org/show_bug.cgi?id=173223
2860
2861         Reviewed by Sam Weinig.
2862
2863         The rebuilds were happening due to a difference in the compiler options that the IDE and
2864         xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
2865         xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
2866         specify an appropriate path in CLANG_INDEX_STORE_PATH.
2867
2868         * Configurations/DebugRelease.xcconfig:
2869
2870 2017-06-07  Geoffrey Garen  <ggaren@apple.com>
2871
2872         bmalloc: memory APIs don't need to be heap members
2873         https://bugs.webkit.org/show_bug.cgi?id=173076
2874
2875         Reviewed by Sam Weinig.
2876
2877         Asking the OS about memory use is unrelated to the state of bmalloc's
2878         heap, so it's a better separation of concerns if related code is not 
2879         part of the heap.
2880
2881         * bmalloc/AvailableMemory.cpp:
2882         (bmalloc::memoryStatus):
2883         * bmalloc/AvailableMemory.h:
2884         (bmalloc::MemoryStatus::MemoryStatus):
2885         (bmalloc::isUnderMemoryPressure):
2886         (bmalloc::memoryFootprint):
2887         (bmalloc::percentAvailableMemoryInUse):
2888         * bmalloc/Heap.cpp:
2889         (bmalloc::Heap::Heap):
2890         (bmalloc::Heap::updateMemoryInUseParameters): Deleted.
2891         * bmalloc/Heap.h:
2892         (bmalloc::Heap::isUnderMemoryPressure): Deleted.
2893         (bmalloc::Heap::memoryFootprint): Deleted.
2894         (bmalloc::Heap::percentAvailableMemoryInUse): Deleted.
2895
2896 2017-06-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2897
2898         struct does not accept initializer-form if member has initializers in GCC 4.9
2899         https://bugs.webkit.org/show_bug.cgi?id=172974
2900
2901         Reviewed by Carlos Garcia Campos.
2902
2903         struct cannot accept initializer-form constructor (like, `ListNode<T> t { ... }`) if
2904         the member of the struct has a default initializer.
2905         Here is a simple snippet.
2906
2907         template<typename T>
2908         struct Pair {
2909             T* prev { nullptr };
2910             T* next { nullptr };
2911         };
2912
2913         Pair<int> pair { nullptr, nullptr };  // compile erorr in GCC 4.9.
2914
2915         Instead, we define a default constructor (to invoke default initializers) and a constructor
2916         to accept the above initialization.
2917
2918         * bmalloc/List.h:
2919         (bmalloc::ListNode::ListNode):
2920         (bmalloc::List::iterator::iterator):
2921
2922 2017-06-06  Geoffrey Garen  <ggaren@apple.com>
2923
2924         Try to fix the GTK build.
2925
2926         Unreviewed.
2927
2928         * bmalloc/List.h:
2929         (bmalloc::List::List):
2930
2931 2017-06-05  Geoffrey Garen  <ggaren@apple.com>
2932
2933         Try to fix the GTK build.
2934
2935         Unreviewed.
2936
2937         * bmalloc/List.h:
2938
2939 2017-06-02  Geoffrey Garen  <ggaren@apple.com>
2940
2941         bmalloc: Small and large objects should share memory
2942         https://bugs.webkit.org/show_bug.cgi?id=172880
2943         <rdar://problem/31494732>
2944
2945         Reviewed by Sam Weinig.
2946
2947         This reduces our high water mark memory usage on JetStream on macOS
2948         by 10%-20%. It also has the nice side effect that we can free small
2949         object metadata after returning from a high water mark.
2950
2951         No change in throughput.
2952
2953         Our old algorithm allocated small object chunks and large objects in
2954         segregated virtual memory and never recycled addresses between them.
2955         This provided a slight security benefit because we could apply guard
2956         pages between the segregated ranges and we would never reuse the same
2957         virtual address for object and metadata memory.
2958
2959         Our new algorithm allocates small object chunks from the large object
2960         allocator. This naturally recycles memory between small chunks and large
2961         objects, and between small chunks of different page classes. This allows
2962         us to shift memory between allocation types as a program moves between
2963         different phases of allocation, and to delete small object chunk metadata
2964         when a program shrinks back from a high water mark.
2965
2966         Two intuitions I had about memory use turned out to be backwards in
2967         this context:
2968
2969         (1) I thought that this optimization would work because it allowed you to
2970         allocate and free a 4MB object and then reuse that large allocation to
2971         service small allocations. In practice, the common benefit seems to be
2972         the opposite: After you allocate and free many small objects, you can
2973         stitch them together to allocate a large object without growing the heap.
2974
2975         (2) I thought that it would be more memory-efficient to allocate
2976         fine-grained pages from the large object allocator. In practice, giving
2977         the large object allocator too many arbitrarily-sized ranges to manage
2978         leads to fragmentation. Meanwhile, segregated fit is a powerful memory
2979         optimization. So, it's best to return small object memory to the large
2980         allocator only when a whole small object chunk is free.
2981
2982         * bmalloc/Chunk.h:
2983         (bmalloc::Chunk::ref):
2984         (bmalloc::Chunk::deref):
2985         (bmalloc::Chunk::refCount):
2986         (bmalloc::Chunk::freePages): We keep a free list per chunk and refcount
2987         each chunk so we can notice when a chunk becomes empty, and return it
2988         to the large allocator.
2989
2990         (bmalloc::forEachPage): A new helper function for iterating the pages
2991         in a Chunk.
2992
2993         (bmalloc::Chunk::Chunk): Use forEachPage instead of manual iteration.
2994         Use { } initialization because we don't get zero-initialized by the OS
2995         anymore.
2996
2997         * bmalloc/Heap.cpp:
2998         (bmalloc::Heap::Heap):
2999         (bmalloc::Heap::concurrentScavenge):
3000         (bmalloc::Heap::scavenge): Don't bother unlocking while scavenging. I
3001         wasn't able to show it to be a consistent speedup. A more promising
3002         approach, if we find a motivating example, is for the scavenger to give
3003         up and return early if any other client is waiting on the lock.
3004
3005         (bmalloc::Heap::allocateSmallChunk): New helper function for allocating
3006         a small chunk. It allocates through the large allocator to facilitate
3007         sharing. We still allocate a chunk at a time instead of a page at a time.
3008         Surprisingly, more precise page-at-a-time allocation is worse for memory
3009         use because of fragmentation. Segregated fit is a powerful optimization.
3010
3011         (bmalloc::Heap::deallocateSmallChunk): New helper function for deallocating
3012         a small chunk.
3013
3014         (bmalloc::Heap::allocateSmallPage): Updated for new APIs.
3015
3016         (bmalloc::Heap::deallocateSmallLine):  Updated for new APIs. Note that
3017         we cache one free chunk per page class. This avoids churn in the large
3018         allocator when you free(malloc(X)).
3019
3020         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
3021         (bmalloc::Heap::allocateSmallBumpRangesByObject):
3022         (bmalloc::Heap::tryAllocateLarge):
3023         (bmalloc::Heap::scavengeSmallPages): Deleted.
3024         (bmalloc::Heap::scavengeLargeObjects): Deleted.
3025         * bmalloc/Heap.h:
3026
3027         * bmalloc/LargeMap.h:
3028         (bmalloc::LargeMap::begin):
3029         (bmalloc::LargeMap::end): Added iteration helpers for scavenging.
3030
3031         * bmalloc/LargeRange.h:
3032         (bmalloc::LargeRange::physicalSize): Added a comment about something
3033         that I confused myself about in this patch.
3034
3035         * bmalloc/List.h:
3036         (bmalloc::List::iterator::operator*):
3037         (bmalloc::List::iterator::operator->):
3038         (bmalloc::List::iterator::operator!=):
3039         (bmalloc::List::iterator::operator++):
3040         (bmalloc::List::begin):
3041         (bmalloc::List::end):
3042         (bmalloc::List::pushFront):
3043         (bmalloc::List::remove):
3044         (bmalloc::ListNode::ListNode): Deleted. Added iteration helpers for
3045         scavenging. Changed the default state of a Node to null pointers instead
3046         of self pointers to distinguish the null node from the empty node for
3047         easier debugging.
3048
3049         * bmalloc/Sizes.h: Changed the chunk size to 1MB to increase the chances
3050         of a chunk becoming free and recyclable.
3051
3052         * bmalloc/SmallPage.h:
3053         (bmalloc::SmallPage::hasPhysicalPages):
3054         (bmalloc::SmallPage::setHasPhysicalPages): Track physical state by page
3055         instead of implicitly by which list a page is in. It's simpler not
3056         to have to move chunks and pages between physical vs virtual lists.
3057
3058         (bmalloc::SmallPage::SmallPage): Deleted.
3059
3060         * bmalloc/VMHeap.cpp:
3061         (bmalloc::VMHeap::tryAllocateLargeChunk):
3062         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
3063         * bmalloc/VMHeap.h:
3064         (bmalloc::VMHeap::allocateSmallPage): Deleted.
3065         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Small chunk allocation
3066         just forwards to the large allocator now.
3067
3068         * bmalloc/bmalloc.h:
3069         (bmalloc::api::scavenge):
3070
3071 2017-05-28  Dan Bernstein  <mitz@apple.com>
3072
3073         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
3074         https://bugs.webkit.org/show_bug.cgi?id=172691
3075
3076         Reviewed by Tim Horton.
3077
3078         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
3079
3080 2017-05-25  Geoffrey Garen  <ggaren@apple.com> and Michael Saboff  <msaboff@apple.com>
3081
3082         bmalloc: scavenger runs too much on JetStream
3083         https://bugs.webkit.org/show_bug.cgi?id=172373
3084
3085         Reviewed by Geoffrey Garen.
3086
3087         Instruments says that JetStream on macOS spends about 3% of its time in
3088         madvise.
3089
3090         In <https://bugs.webkit.org/show_bug.cgi?id=160098>, Ben saw some
3091         evidence that madvise was the reason that switching to bmalloc for
3092         DFG::Node allocations was a slowdown the first time around.
3093
3094         In <https://bugs.webkit.org/show_bug.cgi?id=172124>, Michael saw that
3095         scavening policy can affect JetStream.
3096
3097         Intuitively, it seems wrong for the heap to idle shrink during hardcore
3098         benchmarking.
3099
3100         The strategy here is to back off in response to any heap growth event,
3101         and to wait 2s instead of 0.5s for heap growth to take place -- but we
3102         scavenge immediately in response to critical memory pressure, to avoid
3103         jetsam.
3104
3105         One hole in this strategy is that a workload with a perfectly
3106         unfragmented heap that allocates and deallocates ~16kB every 2s will
3107         never shrink its heap. This doesn't seem to be a problem in practice.
3108
3109         This looks like a 2% - 4% speedup on JetStream on Mac Pro and MacBook Air.
3110
3111         * bmalloc/AsyncTask.h:
3112         (bmalloc::AsyncTask::willRun):
3113         (bmalloc::AsyncTask::willRunSoon):
3114         (bmalloc::Function>::AsyncTask):
3115         (bmalloc::Function>::run):
3116         (bmalloc::Function>::runSoon):
3117         (bmalloc::Function>::threadRunLoop):
3118         (bmalloc::Function>::runSlowCase): Deleted. Added a "run soon" state
3119         so that execution delay is modeled directly instead of implicitly
3120         through sleep events. This enables the Heap to issue a "run now" event
3121         at any moment in response ot memory pressure.
3122
3123         * bmalloc/Heap.cpp:
3124         (bmalloc::Heap::Heap): Don't call into our own API -- that's a layering
3125         violation.
3126
3127         (bmalloc::Heap::updateMemoryInUseParameters): No need for
3128         m_scavengeSleepDuration anymore.
3129
3130         (bmalloc::Heap::concurrentScavenge): Added a back-off policy when the
3131         heap is growing.
3132         (bmalloc::Heap::scavenge):
3133
3134         (bmalloc::Heap::scavengeSmallPages):
3135         (bmalloc::Heap::scavengeLargeObjects): Don't try to give up in the middle
3136         of a scavenge event. Our new backoff policy supplants that design. Also,
3137         it's easier to profile and understand scavenging behavior if it always
3138         runs to completion once started.
3139
3140         (bmalloc::Heap::scheduleScavenger):
3141         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Added a
3142         synchronous amortized check for memory pressure. This check has the
3143         benefit that it runs immediately during high rates of heap activity,
3144         so we can detect memory pressure right away and wake the scavenger
3145         instead of waiting for the scavenger to wake up.
3146
3147         (bmalloc::Heap::allocateSmallPage):
3148         (bmalloc::Heap::deallocateSmallLine):
3149         (bmalloc::Heap::splitAndAllocate):
3150         (bmalloc::Heap::tryAllocateLarge):
3151         (bmalloc::Heap::shrinkLarge):
3152         (bmalloc::Heap::deallocateLarge):
3153         * bmalloc/Heap.h:
3154         (bmalloc::Heap::isUnderMemoryPressure):
3155         * bmalloc/Sizes.h:
3156         * bmalloc/VMHeap.h:
3157         (bmalloc::VMHeap::deallocateSmallPage):
3158         * bmalloc/bmalloc.h:
3159         (bmalloc::api::scavenge): Updated for API changes above.
3160
3161 2017-05-17  Michael Saboff  <msaboff@apple.com>
3162
3163         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info (172186)
3164         https://bugs.webkit.org/show_bug.cgi?id=172186
3165
3166         Reviewed by Geoffrey Garen.
3167
3168         The calls memoryFootprint() and percentAvailableMemoryInUse() now make a system call to get
3169         the current memory footprint value.
3170
3171         * bmalloc/Heap.h:
3172         (bmalloc::Heap::memoryFootprint):
3173         (bmalloc::Heap::percentAvailableMemoryInUse):
3174
3175 2017-05-16  Michael Saboff  <msaboff@apple.com>
3176
3177         REGRESSION(r216763): JetStream is 1% slower on Mac
3178         https://bugs.webkit.org/show_bug.cgi?id=172124
3179
3180         Reviewed by Filip Pizlo.
3181
3182         It appears that changing maxScavengeSleepDuration from 512 to 250ms in r216763 is
3183         responsible for the regression.
3184
3185         * bmalloc/Sizes.h:
3186
3187 2017-05-15  Geoffrey Garen  <ggaren@apple.com>
3188
3189         bmalloc: Bump the size of the deallocator log to 512
3190         https://bugs.webkit.org/show_bug.cgi?id=172143
3191
3192         Reviewed by Michael Saboff.
3193
3194         This is a speedup on parallel workloads for machines with lots of CPUs.
3195
3196         * bmalloc/Sizes.h:
3197
3198 2017-05-12  Michael Saboff  <msaboff@apple.com>
3199
3200         [iOS] Use memory footprint to dynamically adjust behavior of allocators
3201         https://bugs.webkit.org/show_bug.cgi?id=171944
3202
3203         Reviewed by Filip Pizlo.
3204
3205         This change is iOS only.
3206
3207         After the scavenger thread completes scavenging, it asks the OS for how much total memory the
3208         process is using.  This information is used to update the sleep delay for the scanvenger thread,
3209         as well as to provide memory in use data for other parts of the system.
3210
3211         The scavenger sleep time is calculated using the following quadradic equation.
3212
3213             scavengerSleep = 1.2*percentFreeMemory^2 - percentFreeMemory + 2
3214
3215         Where percentFreeMemory is between 0 and 100.  The result is constrained to the values 2 and 250.
3216
3217         This equation empirically works out to providing a 2ms sleep time when we have less than 10%
3218         memory available, 30ms when 20% is available and 250ms when 50% or more is available.  In testing,
3219         this exponentially agressive scavenging delay by itself reduced memory usage and made it much
3220         more deterministic when used without the corresponding change in the JSC Heap.
3221
3222         Changed the scavenger thread to use the User Initiated QOS priority to ensure it doesn't
3223         get starved.
3224
3225         Moved the non-Windows functionality of WTF::RAMSize() to new files AvailableMemory.{cpp,h}
3226         and implemented in the function availableMemory().  That functions limits the value returned
3227         on iOS to a maximum of 840MB as that is the jetsam soft memory limit.
3228         Added a new API availableMemory() so that WTF::RAMSize() will use this value.
3229
3230         * CMakeLists.txt:
3231         * bmalloc.xcodeproj/project.pbxproj:
3232         * bmalloc/BPlatform.h:
3233         * bmalloc/Heap.cpp:
3234         (bmalloc::Heap::Heap):
3235         (bmalloc::Heap::updateMemoryInUseParameters):
3236         (bmalloc::Heap::concurrentScavenge):
3237         (bmalloc::Heap::scavenge):
3238         * bmalloc/Heap.h:
3239         (bmalloc::Heap::memoryFootprint):
3240         (bmalloc::Heap::percentAvailableMemoryInUse):
3241         * bmalloc/Sizes.h:
3242         * bmalloc/bmalloc.h:
3243         (bmalloc::api::availableMemory):
3244         (bmalloc::api::memoryFootprint):
3245         (bmalloc::api::percentAvailableMemoryInUse):
3246         * bmalloc/AvailableMemory.cpp: Added.
3247         (bmalloc::computeAvailableMemory):
3248         (bmalloc::availableMemory):
3249         * bmalloc/AvailableMemory.h: Added.
3250
3251 2017-05-05  Joseph Pecoraro  <pecoraro@apple.com>
3252
3253         Leaks always reports "WebKit Malloc Memory Pressure Handler" dispatch_queue/source as leaking
3254         https://bugs.webkit.org/show_bug.cgi?id=171532
3255
3256         Reviewed by Geoffrey Garen.
3257
3258         * bmalloc/Heap.cpp:
3259         (bmalloc::Heap::Heap):
3260         * bmalloc/Heap.h:
3261         Store the dispatch_source_t in a member to avoid a false positive leak.
3262
3263 2017-04-27  Michael Saboff  <msaboff@apple.com>
3264
3265         bmalloc scavenger should know what page classes are allocating
3266         https://bugs.webkit.org/show_bug.cgi?id=171384
3267
3268         Reviewed by Geoffrey Garen.
3269
3270         This change replaces m_isAllocatingPages with a per page class flag to track which page
3271         classes are currently allocating.  When scavenging, we skip page classes that are actively
3272         allocating and come back to them on a subsequent pass.  This reduces the amount of time it
3273         takes for scavenger to free up pages as well as the total time it takes to handle all
3274         page classes.
3275
3276         * bmalloc/Heap.cpp:
3277         (bmalloc::Heap::Heap):
3278         (bmalloc::Heap::concurrentScavenge):
3279         (bmalloc::Heap::scavenge):
3280         (bmalloc::Heap::scavengeSmallPages):
3281         (bmalloc::Heap::scavengeLargeObjects):
3282         (bmalloc::Heap::allocateSmallPage):
3283         (bmalloc::Heap::splitAndAllocate):
3284         (bmalloc::Heap::deallocateLarge):
3285         * bmalloc/Heap.h:
3286         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass): Deleted.
3287         * bmalloc/VMHeap.h:
3288         (bmalloc::VMHeap::deallocateSmallPage):
3289         * bmalloc/bmalloc.h:
3290         (bmalloc::api::scavenge):
3291
3292 2017-04-25  Michael Saboff  <msaboff@apple.com>
3293
3294         Call bmalloc scavenger first when handling a memory pressure event
3295         https://bugs.webkit.org/show_bug.cgi?id=171289
3296
3297         Reviewed by Geoffrey Garen.
3298
3299         Registered a critical memory pressure handler.  We add this handler in addition to the
3300         call to release bmalloc memory in the WebCore releaseMemory handler for the case of
3301         JSC API users that don't use WebCore.  When both handlers are in the process, it is
3302         basically a race.  One will win, but the loser won't do any more work, so it is harmless.
3303
3304         * bmalloc/Heap.cpp:
3305         (bmalloc::Heap::Heap):
3306
3307 2017-04-14  Mark Lam  <mark.lam@apple.com>
3308
3309         Update architectures in xcconfig files.
3310         https://bugs.webkit.org/show_bug.cgi?id=170867
3311         <rdar://problem/31628104>
3312
3313         Reviewed by Joseph Pecoraro.
3314
3315         * Configurations/Base.xcconfig:
3316
3317 2017-04-12  Dan Bernstein  <mitz@apple.com>
3318
3319         [Mac] Future-proof .xcconfig files
3320         https://bugs.webkit.org/show_bug.cgi?id=170802
3321
3322         Reviewed by Tim Horton.
3323
3324         * Configurations/Base.xcconfig:
3325         * Configurations/DebugRelease.xcconfig:
3326
3327 2017-02-03  Ting-Wei Lan  <lantw44@gmail.com>
3328
3329         Include cstdlib before using ::malloc and posix_memalign
3330         https://bugs.webkit.org/show_bug.cgi?id=167800
3331
3332         Reviewed by Geoffrey Garen.
3333
3334         * bmalloc/DebugHeap.cpp:
3335
3336 2017-02-01  Andreas Kling  <akling@apple.com>
3337
3338         Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
3339         <https://webkit.org/b/167387>
3340         <rdar://problem/29711409>
3341
3342         Reviewed by Antti Koivisto.
3343
3344         Support changing the QoS level of the scavenger thread asynchronously through
3345         a request variable. This is not the most elegant thing in the world, but since
3346         threads are only allowed to change their own QoS class, our options are limited.
3347
3348         * bmalloc/Heap.cpp:
3349         (bmalloc::Heap::concurrentScavenge):
3350         * bmalloc/Heap.h:
3351         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
3352         (bmalloc::Heap::setScavengerThreadQOSClass):
3353         * bmalloc/bmalloc.h:
3354         (bmalloc::api::setScavengerThreadQOSClass):
3355
3356 2017-01-13  Geoffrey Garen  <ggaren@apple.com>
3357
3358         bmalloc: Use a separate zone when using system malloc
3359         https://bugs.webkit.org/show_bug.cgi?id=167014
3360
3361         Reviewed by Filip Pizlo.
3362
3363         Harris asked for this so he could separate Safari and WebKit memory use
3364         when doing memory analysis.
3365
3366         This patch adds an explicit DebugHeap class that contains all our
3367         code for specialized allocation with debugging.
3368
3369         * bmalloc.xcodeproj/project.pbxproj:
3370
3371         * bmalloc/Allocator.cpp:
3372         (bmalloc::Allocator::Allocator):
3373         (bmalloc::Allocator::tryAllocate):
3374         (bmalloc::Allocator::allocateImpl):
3375         (bmalloc::Allocator::reallocate):
3376         (bmalloc::Allocator::allocateSlowCase):
3377         * bmalloc/Allocator.h: Forward to DebugHeap instead of inlining all the
3378         code. This is required for our new interface, and it is also a nice
3379         simplification that moves some not-very-important code out of the way.
3380
3381         * bmalloc/Deallocator.cpp:
3382         (bmalloc::Deallocator::Deallocator):
3383         (bmalloc::Deallocator::scavenge):
3384         (bmalloc::Deallocator::deallocateSlowCase):
3385         * bmalloc/Deallocator.h: Ditto.
3386
3387         * bmalloc/DebugHeap.cpp: Added.
3388         (bmalloc::DebugHeap::DebugHeap):
3389         (bmalloc::DebugHeap::malloc):
3390         (bmalloc::DebugHeap::memalign):
3391         (bmalloc::DebugHeap::realloc):
3392         (bmalloc::DebugHeap::free):
3393         * bmalloc/DebugHeap.h: Added. New class for overriding normal heap
3394         behavior. Right now, it just adds a malloc zone and then forwards to
3395         system malloc -- but we can add lots more kinds of debug heaps in the
3396         future if we find them useful.
3397
3398         * bmalloc/Environment.cpp:
3399         (bmalloc::Environment::Environment):
3400         (bmalloc::Environment::computeIsDebugHeapEnabled):
3401         (bmalloc::Environment::computeIsBmallocEnabled): Deleted.
3402         * bmalloc/Environment.h:
3403         (bmalloc::Environment::isDebugHeapEnabled):
3404         (bmalloc::Environment::isBmallocEnabled): Deleted. Renamed everything to
3405         reflect our new use of DebugHeap.
3406
3407         * bmalloc/Heap.cpp:
3408         (bmalloc::Heap::Heap):
3409         * bmalloc/Heap.h:
3410         (bmalloc::Heap::debugHeap): Updated to use DebugHeap.
3411         (bmalloc::Heap::environment): Deleted. 
3412
3413         * bmalloc/bmalloc.h:
3414         (bmalloc::api::isEnabled): Updated to use DebugHeap.
3415
3416 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
3417
3418         Sort Xcode project files
3419         https://bugs.webkit.org/show_bug.cgi?id=165937
3420
3421         Reviewed by Simon Fraser.
3422
3423         * bmalloc.xcodeproj/project.pbxproj:
3424
3425 2016-12-08  David Kilzer  <ddkilzer@apple.com>
3426
3427         Always check the return value of pthread_key_create()
3428         <https://webkit.org/b/165274>
3429
3430         Reviewed by Darin Adler.
3431
3432         * bmalloc/PerThread.h:
3433         (bmalloc::PerThreadStorage::init): Call BCRASH() if
3434         pthread_key_create() returns an error.  The error code will be
3435         stored in a register available in a crash log, so no need to log
3436         the value explicitly.
3437
3438 2016-12-06  Alexey Proskuryakov  <ap@apple.com>
3439
3440         Correct SDKROOT values in xcconfig files
3441         https://bugs.webkit.org/show_bug.cgi?id=165487
3442         rdar://problem/29539209
3443
3444         Reviewed by Dan Bernstein.
3445
3446         Fix suggested by Dan Bernstein.
3447
3448         * Configurations/DebugRelease.xcconfig:
3449
3450 2016-11-29  Andy Estes  <aestes@apple.com>
3451
3452         [Cocoa] Enable two clang warnings recommended by Xcode
3453         https://bugs.webkit.org/show_bug.cgi?id=164498
3454
3455         Reviewed by Mark Lam.
3456
3457         * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
3458
3459 2016-11-10  Geoffrey Garen  <ggaren@apple.com>
3460
3461         bmalloc threads should have a non-default QoS
3462         https://bugs.webkit.org/show_bug.cgi?id=164612
3463
3464         Reviewed by Filip Pizlo.
3465
3466         * bmalloc/AsyncTask.h:
3467         (bmalloc::Function>::threadEntryPoint): Request user-interactive quality
3468         of service because user-interactive tasks use malloc.
3469
3470 2016-10-20  Mark Lam  <mark.lam@apple.com>
3471
3472         bmalloc api should crash on failure to allocate when !isBmallocEnabled.
3473         https://bugs.webkit.org/show_bug.cgi?id=163766
3474
3475         Reviewed by Keith Miller and Filip Pizlo.
3476
3477         We want to crash in bmalloc on failure to allocate even when !isBmallocEnabled.
3478         This is so that failures to allocate memory will manifest as crashes with a
3479         unique signature (i.e. as a SIGTRAP on release builds, or as a write to illegal
3480         address 0xbbadbeef on debug builds) and the crash will manifest inside bmalloc.
3481         This distinguishes allocation failures from other crashing bugs that manifest as
3482         SIGSEGVs due to random pointer dereferences in the clients of bmalloc.
3483
3484         * bmalloc/Allocator.cpp:
3485         (bmalloc::Allocator::allocateImpl):
3486         (bmalloc::Allocator::reallocate):
3487         (bmalloc::Allocator::allocateSlowCase):
3488
3489 2016-09-26  Yoshiaki Jitsukawa  <Yoshiaki.Jitsukawa@sony.com>
3490
3491         Avoid implicit conversion from iterator to pointer
3492         https://bugs.webkit.org/show_bug.cgi?id=162482
3493
3494         Reviewed by Geoffrey Garen.
3495
3496         Not every STL supporting such conversion, we should get a pointer explicitly.
3497
3498         * bmalloc/Chunk.h:
3499         (bmalloc::Chunk::lines):
3500         (bmalloc::Chunk::pages):
3501         * bmalloc/FixedVector.h:
3502         (bmalloc::FixedVector::begin):
3503
3504 2016-08-31  Filip Pizlo  <fpizlo@apple.com>
3505
3506         Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
3507         https://bugs.webkit.org/show_bug.cgi?id=160125
3508
3509         Reviewed by Geoffrey Garen and Keith Miller.
3510         
3511         I needed to tryMemalign, so I added such a thing.
3512
3513         * bmalloc/Allocator.cpp:
3514         (bmalloc::Allocator::allocate):
3515         (bmalloc::Allocator::tryAllocate):
3516         (bmalloc::Allocator::allocateImpl):
3517         * bmalloc/Allocator.h:
3518         * bmalloc/Cache.h:
3519         (bmalloc::Cache::tryAllocate):
3520         * bmalloc/bmalloc.h:
3521         (bmalloc::api::tryMemalign):
3522
3523 2016-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3524
3525         Unreviewed, build fix for GCC ports
3526
3527         std::forward is declared in <utility> header.
3528
3529         * bmalloc/ScopeExit.h:
3530
3531 2016-08-30  Geoffrey Garen  <ggaren@apple.com>
3532
3533         bmalloc: speed up the lock slow path
3534         https://bugs.webkit.org/show_bug.cgi?id=161058
3535
3536         Unreviewed roll-in - with regression fixed.
3537
3538         Revert to using yield() instead of swtch() because very low priority
3539         background tasks can cause priority inversion and deadlock. In the
3540         network process, that happened with com.apple.WebKit.Cache.Storage.serialBackground.
3541
3542         Still a big speedup on MallocBench.
3543
3544         * bmalloc.xcodeproj/project.pbxproj:
3545         * bmalloc/ScopeExit.h: Added.
3546         (bmalloc::ScopeExit::ScopeExit):
3547         (bmalloc::ScopeExit::~ScopeExit):
3548         (bmalloc::makeScopeExit):
3549         * bmalloc/StaticMutex.cpp:
3550         (bmalloc::StaticMutex::lockSlowCase):
3551         * bmalloc/StaticMutex.h:
3552         (bmalloc::StaticMutex::init):
3553
3554 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
3555
3556         Unreviewed build fix.
3557
3558         Fix the CMake build.
3559
3560         * CMakeLists.txt:
3561
3562 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
3563
3564         Renamed XLarge* => Large*
3565         https://bugs.webkit.org/show_bug.cgi?id=161261
3566
3567         Reviewed by Andreas Kling.
3568
3569         XLarge is not a thing anymore: We just have Small and Large.
3570
3571         * bmalloc.xcodeproj/project.pbxproj:
3572         * bmalloc/Heap.cpp:
3573         (bmalloc::Heap::splitAndAllocate):
3574         (bmalloc::Heap::tryAllocateLarge):
3575         (bmalloc::Heap::shrinkLarge):
3576         (bmalloc::Heap::deallocateLarge):
3577         * bmalloc/Heap.h:
3578         * bmalloc/LargeMap.cpp: Copied from Source/bmalloc/bmalloc/XLargeMap.cpp.
3579         (bmalloc::LargeMap::remove):
3580         (bmalloc::LargeMap::add):
3581         (bmalloc::XLargeMap::remove): Deleted.
3582         (bmalloc::XLargeMap::add): Deleted.
3583         * bmalloc/LargeMap.h: Copied from Source/bmalloc/bmalloc/XLargeMap.h.
3584         (bmalloc::LargeMap::ranges):
3585         (bmalloc::XLargeMap::ranges): Deleted.
3586         * bmalloc/LargeRange.h: Copied from Source/bmalloc/bmalloc/XLargeRange.h.
3587         (bmalloc::LargeRange::LargeRange):
3588         (bmalloc::LargeRange::operator<):
3589         (bmalloc::canMerge):
3590         (bmalloc::merge):
3591         (bmalloc::LargeRange::split):
3592         (bmalloc::XLargeRange::XLargeRange): Deleted.
3593         (bmalloc::XLargeRange::operator<): Deleted.
3594         (bmalloc::XLargeRange::split): Deleted.
3595         * bmalloc/VMHeap.cpp:
3596         (bmalloc::VMHeap::tryAllocateLargeChunk):
3597         * bmalloc/VMHeap.h:
3598         * bmalloc/XLargeMap.cpp: Removed.
3599         * bmalloc/XLargeMap.h: Removed.
3600         * bmalloc/XLargeRange.h: Removed.
3601
3602 2016-08-26  Gavin Barraclough  <barraclough@apple.com>
3603
3604         bmalloc: speed up the lock slow path
3605         https://bugs.webkit.org/show_bug.cgi?id=161058
3606
3607         Unreviewed rollout - this caused regressions <rdar://problem/28026089>.
3608
3609         * bmalloc.xcodeproj/project.pbxproj:
3610         * bmalloc/ScopeExit.h: Removed.
3611         * bmalloc/StaticMutex.cpp:
3612         (bmalloc::StaticMutex::lockSlowCase):
3613         * bmalloc/StaticMutex.h:
3614         (bmalloc::StaticMutex::init):
3615         * bmalloc/ThreadSwitch.h: Removed.
3616
3617 2016-08-24  Andreas Kling  <akling@apple.com>
3618
3619         Add bmalloc::api::isEnabled().
3620         <https://webkit.org/b/160534>
3621
3622         Reviewed by Joseph Pecoraro.
3623
3624         * bmalloc/bmalloc.h:
3625         (bmalloc::api::isEnabled):
3626
3627 2016-08-24  Filip Pizlo  <fpizlo@apple.com>
3628
3629         Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.
3630
3631         * bmalloc/Allocator.cpp:
3632         (bmalloc::Allocator::allocate):
3633         (bmalloc::Allocator::tryAllocate): Deleted.
3634         (bmalloc::Allocator::allocateImpl): Deleted.
3635         * bmalloc/Allocator.h:
3636         * bmalloc/Cache.h:
3637         (bmalloc::Cache::tryAllocate): Deleted.
3638         * bmalloc/bmalloc.h:
3639         (bmalloc::api::tryMemalign): Deleted.
3640
3641 2016-08-12  Filip Pizlo  <fpizlo@apple.com>
3642
3643         Butterflies should be allocated in Auxiliary MarkedSpace instead of CopiedSpace and we should rewrite as much of the GC as needed to make this not a regression
3644         https://bugs.webkit.org/show_bug.cgi?id=160125
3645
3646         Reviewed by Geoffrey Garen.
3647         
3648         I needed to tryMemalign, so I added such a thing.
3649
3650         * bmalloc/Allocator.cpp:
3651         (bmalloc::Allocator::allocate):
3652         (bmalloc::Allocator::tryAllocate):
3653         (bmalloc::Allocator::allocateImpl):
3654         (bmalloc::Allocator::reallocate):
3655         * bmalloc/Allocator.h:
3656         * bmalloc/Cache.h:
3657         (bmalloc::Cache::allocate):
3658         (bmalloc::Cache::tryAllocate):
3659         * bmalloc/bmalloc.h:
3660         (bmalloc::api::malloc):
3661         (bmalloc::api::tryMemalign):
3662         (bmalloc::api::memalign):
3663
3664 2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3665
3666         Unreviewed, build fix on GCC environment
3667         https://bugs.webkit.org/show_bug.cgi?id=161058
3668
3669         std::forward is declared in <utility> header.
3670
3671         * bmalloc/ScopeExit.h:
3672
3673 2016-08-22  Geoffrey Garen  <ggaren@apple.com>
3674
3675         bmalloc: speed up the lock slow path
3676         https://bugs.webkit.org/show_bug.cgi?id=161058
3677
3678         Reviewed by Filip Pizlo.
3679
3680         It is generally accepted practice that a lock should yield instead of
3681         spinning when a lock acquisition fails, to avoid wasting CPU and power.
3682
3683         There are two problems with this generally accepted practice:
3684
3685         (1) It's a fallacy that yielding is free. In reality, yielding itself
3686         consumes CPU and power -- by performing a syscall, running the OS
3687         scheduler, and possibly performing a context switch. (Instruments
3688         traces of MallocBench show the cost of yielding.) Therefore, spinning a
3689         little to avoid yielding can actually *save* CPU and power.
3690
3691         (2) std::this_thread_yield() on Darwin is way too aggressive: It not only
3692         yields but also depresses your priority to absolute zero for 10ms. A
3693         recent PLT trace showed a few spots where the main thread just gave up
3694         on loading and rendering a page for 10ms so an unimportant background
3695         task could run.
3696
3697         To correct these problems, this patch adds a little bit of spinning to
3698         the bmalloc lock slow path.
3699
3700         Below are performance results on various CPUs.
3701
3702         Mac Pro (12 hyperthreaded cores = 24 threads):
3703
3704                                                             Baseline                       Patch                           Δ
3705             Execution Time:
3706                 message_one                                    173ms                       173ms                            
3707                 message_many                                   953ms                       927ms              ^ 1.03x faster
3708                 churn --parallel                                60ms                        41ms              ^ 1.46x faster
3709                 list_allocate --parallel                       224ms                       143ms              ^ 1.57x faster
3710                 tree_allocate --parallel                     1,190ms                       758ms              ^ 1.57x faster
3711                 tree_churn --parallel                        1,517ms                       906ms              ^ 1.67x faster
3712                 facebook --parallel                          6,519ms                     4,580ms              ^ 1.42x faster
3713                 reddit --parallel                            5,097ms                     3,411ms              ^ 1.49x faster
3714                 flickr --parallel                            4,903ms                     3,501ms               ^ 1.4x faster
3715                 theverge --parallel                          6,641ms                     4,505ms              ^ 1.47x faster
3716
3717                 <geometric mean>                             1,158ms                       832ms              ^ 1.39x faster
3718                 <arithmetic mean>                            2,728ms                     1,895ms              ^ 1.44x faster
3719                 <harmonic mean>                                332ms                       240ms              ^ 1.38x faster
3720
3721         MacBook Air (2 hyperthreaded cores = 4 threads):
3722
3723                                                             Baseline                       Patch                           Δ
3724             Execution Time:
3725                 message_one                                    911ms                       907ms               ^ 1.0x faster
3726                 message_many                                   515ms                       513ms               ^ 1.0x faster
3727                 churn --parallel                               132ms                       134ms              ! 1.02x slower
3728                 list_allocate --parallel                       104ms                       102ms              ^ 1.02x faster
3729                 tree_allocate --parallel                       117ms                       111ms              ^ 1.05x faster
3730                 tree_churn --parallel                          154ms                       151ms              ^ 1.02x faster
3731                 facebook --parallel                            719ms                       687ms              ^ 1.05x faster
3732                 reddit --parallel                              382ms                       341ms              ^ 1.12x faster
3733                 flickr --parallel                              372ms                       345ms              ^ 1.08x faster
3734                 theverge --parallel                            489ms                       444ms               ^ 1.1x faster
3735
3736                 <geometric mean>                               299ms                       287ms              ^ 1.04x faster
3737                 <arithmetic mean>                              390ms                       374ms              ^ 1.04x faster
3738                 <harmonic mean>                                227ms                       220ms              ^ 1.03x faster
3739
3740         iPad (2 cores = 2 threads):
3741
3742             [ Doesn't run Ruby, so no pretty subtest output. ]
3743
3744                                                             Baseline                       Patch                           Δ
3745             Execution Time:                                 174.14ms                     171.5ms              ^ 1.02x faster
3746
3747         * bmalloc.xcodeproj/project.pbxproj:
3748
3749         * bmalloc/ScopeExit.h: Added. A barebones very wimpy version of
3750         WTF::ScopeExit.
3751         (bmalloc::ScopeExit::ScopeExit):
3752         (bmalloc::ScopeExit::~ScopeExit):
3753         (bmalloc::makeScopeExit):
3754
3755         * bmalloc/StaticMutex.cpp:
3756         (bmalloc::StaticMutex::lockSlowCase): Spin before yielding -- that's the
3757         speedup. Don't spin if another CPU is already spinning. In theory, more
3758         than one spinner accomplishes nothing, and I found that there's a cutoff
3759         around 8 or 16 spinners that becomes performance negative on Mac Pro.
3760
3761         (Note: Another way to accomplish a similar result, if you don't want to
3762         use a bit of state in the lock, is to spin for a random duration between
3763         0 and aLot. I tested a version of WTF::WeakRandom with unsynchronized
3764         static state and it worked great. But I ultimately opted for the explicit
3765         bit because I thought it was clearer.)
3766
3767         * bmalloc/StaticMutex.h:
3768         (bmalloc::StaticMutex::init): Initialize our new bit.
3769
3770         * bmalloc/ThreadSwitch.h: Added.
3771         (bmalloc::threadSwitch): Don't call yield() on Darwin because it's too
3772         aggressive. swtch() does what we want: Go run something else, without
3773         any other side-effects.
3774
3775 2016-08-03  Geoffrey Garen  <ggaren@apple.com>
3776
3777         [bmalloc] Merging of XLargeRanges can leak the upper range
3778         https://bugs.webkit.org/show_bug.cgi?id=160403
3779
3780         Reviewed by Michael Saboff.
3781
3782         * bmalloc/Heap.cpp:
3783         (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
3784         Recorded physical size is a performance optimization. It is not the
3785         truth. So it might be zero even if a range contains physical pages.
3786
3787         Instead, iterate each range in the map unconditionally.
3788
3789         The map can shrink when we release the lock, so we must clamp our
3790         iterator each time through the loop.
3791
3792         The map can grow when we release the lock, but we don't care because
3793         growth restarts the scavenger from the beginning.
3794
3795         * bmalloc/XLargeMap.cpp:
3796         (bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.
3797
3798         * bmalloc/XLargeMap.h:
3799         (bmalloc::XLargeMap::ranges): Added direct access for the sake of
3800         scavengeLargeObjects. (This violates our naming conventions -- I'll do
3801         a rename in a follow-up patch.)
3802
3803 2016-07-13  Enrica Casucci  <enrica@apple.com>
3804
3805         Update supported platforms in xcconfig files to match the sdk names.
3806         https://bugs.webkit.org/show_bug.cgi?id=159728
3807
3808         Reviewed by Tim Horton.
3809
3810         * Configurations/Base.xcconfig:
3811
3812 2016-07-11  Geoffrey Garen  <ggaren@apple.com>
3813
3814         Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
3815         https://bugs.webkit.org/show_bug.cgi?id=159655
3816
3817         Reviewed by Sam Weinig.
3818
3819         It's not entirely clear what was happening in these crashes, but our
3820         use of detach() was 100% forward-looking, so we can just remove it for
3821         now.
3822
3823         This patch removes the ability for the scavenger owner to die before
3824         the scavenger thread dies (which was unused) and also removes the
3825         ability for the scavenger thread to exit (which was used, but we
3826         messed up and did thread joining lazily, so we never got any benefit
3827         from thread exit.)
3828
3829         We can add these features back when we need them, and make them work then.
3830
3831         * bmalloc/AsyncTask.h:
3832         (bmalloc::Function>::AsyncTask): We start out in the running state now
3833         because we know that starting our thread will run it.
3834
3835         (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
3836
3837         (bmalloc::Function>::runSlowCase): I removed the Exited state.
3838
3839         (bmalloc::Function>::threadRunLoop): I removed the Exited and
3840         ExitRequested states.
3841
3842         * bmalloc/Heap.h:
3843
3844         * bmalloc/VMHeap.h:
3845
3846 2016-06-12  David Kilzer  <ddkilzer@apple.com>
3847
3848         Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
3849         <https://webkit.org/b/158660>
3850         <rdar://problem/25652686>
3851
3852         Reviewed by Darin Adler.
3853
3854         * bmalloc/Logging.cpp: Switch to use
3855         BSOFT_LINK_PRIVATE_FRAMEWORK() to link
3856         CrashReporterSupport.framework.
3857         * bmalloc/darwin/BSoftLinking.h:
3858         (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
3859         Switch to use /System/Library/PrivateFrameworks/.
3860
3861 2016-06-11  David Kilzer  <ddkilzer@apple.com>
3862
3863         Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
3864         <http://webkit.org/b/155992>
3865
3866         Reviewed by Geoff Garen.
3867
3868         * bmalloc/BAssert.h:
3869         (BLOG_ERROR): Add method to always log error messages.
3870         (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
3871         logging in Debug builds.
3872         * bmalloc/BPlatform.h:
3873         (BPLATFORM_MAC): Add.
3874         (BUSE): Add BUSE() macro.
3875         (BATTRIBUTE_PRINTF): Add.
3876         (BUSE_OS_LOG): Add.
3877         * bmalloc/Logging.cpp:
3878         (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
3879         stderr.
3880         * bmalloc/Logging.h:
3881         (bmalloc::reportAssertionFailureWithMessage): Add declaration.
3882
3883 2016-06-07  Pranjal Jumde  <pjumde@apple.com>
3884
3885         Prevents integer overflow in Vector.h
3886         https://bugs.webkit.org/show_bug.cgi?id=158455
3887         <rdar://problem/20235469>
3888
3889         Reviewed by Mark Lam.
3890
3891         * bmalloc/Vector.h:
3892         (bmalloc::Vector<T>::reallocateBuffer):
3893
3894 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
3895
3896         [cmake] Deduplicated bmalloc/Zone.cpp handling.
3897         https://bugs.webkit.org/show_bug.cgi?id=158154
3898
3899         Reviewed by Alex Christensen.
3900
3901         File bmalloc/Zone.cpp is required on Darwin irrespectively from what
3902         port is being built.
3903
3904         Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
3905         unlikely that bmalloc will ever need port-specific customizations (as
3906         opposed to OS-specific customizations which should be done in
3907         CMakeLists.txt).
3908
3909         * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
3910         * PlatformGTK.cmake: Removed.
3911         * PlatformMac.cmake: Removed.
3912
3913 2016-05-22  Brady Eidson  <beidson@apple.com>
3914
3915         Move to C++14.
3916         https://bugs.webkit.org/show_bug.cgi?id=157948
3917
3918         Reviewed by Michael Catanzaro.
3919
3920         * Configurations/Base.xcconfig:
3921
3922 2016-05-17  Geoffrey Garen  <ggaren@apple.com>
3923
3924         REGRESSION: JetStream crashes on some iPhones
3925         https://bugs.webkit.org/show_bug.cgi?id=157814
3926
3927         Reviewed by Michael Saboff.
3928
3929         * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
3930
3931         Previous justification for 64kB was:
3932
3933             * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
3934             reasonable, since sizes between 16kB and 32kB share page sizes. I went
3935             all the way up to 64kB because the GC uses 64kB blocks, and also just
3936             for extra padding to ensure that large allocations are indeed rare.
3937
3938         It turns out that the bump to 64kB substantially increases our memory
3939         high water mark on JetStream, leading to jetsam crashes. Also, there
3940         doesn't seem to be a practical performance problem to putting objects in
3941         the (32kB - 64kB) range in the large allocator.
3942
3943 2016-05-16  Geoffrey Garen  <ggaren@apple.com>
3944
3945         REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
3946         https://bugs.webkit.org/show_bug.cgi?id=157764
3947
3948         Reviewed by Gavin Barraclough.
3949
3950         We need to allow for guard pages and only report unguarded pages to the
3951         leaks tool -- otherwise, it will try to remote map our guarded pages,
3952         and crash.
3953
3954         * bmalloc/VMHeap.cpp:
3955         (bmalloc::VMHeap::tryAllocateLargeChunk):
3956         (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
3957         a range instead of a Chunk*, and report the unguarded range.
3958
3959         This also fixes a separate bug -- very large allocations would not
3960         fully participate in pointer scanning because they would only report 2MB
3961         (chunkSize) in size. This could cause false-positive leak reports.
3962
3963         * bmalloc/Zone.cpp:
3964         (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
3965         Chunk pointers.
3966
3967         * bmalloc/Zone.h:
3968         (bmalloc::Zone::ranges):
3969         (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
3970         pointers because our VM ranges have variable sizes -- both due to guard
3971         pages and due to large allocations.
3972
3973         (bmalloc::Zone::chunks): Deleted.
3974         (bmalloc::Zone::addChunk): Deleted.
3975
3976 2016-05-10  David Kilzer  <ddkilzer@apple.com>
3977
3978         bmalloc should automatically disable itself when ThreadSanitizer is used
3979         <https://webkit.org/b/157527>
3980
3981         Reviewed by Michael Catanzaro.
3982
3983         * bmalloc/Environment.cpp:
3984         (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
3985         (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
3986         support for detecting ThreadSanitizer.
3987         (bmalloc::Environment::computeIsBmallocEnabled): Switch from
3988         isASanEnabled to isSanitizerEnabled.
3989
3990 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
3991
3992         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3993         https://bugs.webkit.org/show_bug.cgi?id=157047
3994
3995         Reviewed by Filip Pizlo.
3996
3997         Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
3998
3999         * bmalloc/Algorithm.h:
4000         (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
4001         (bmalloc::roundUpToMultipleOfSloppy): Deleted.
4002         * bmalloc/VMHeap.cpp:
4003         (bmalloc::VMHeap::allocateSmallChunk):
4004
4005 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
4006
4007         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
4008         https://bugs.webkit.org/show_bug.cgi?id=157047
4009
4010         Reviewed by Filip Pizlo.
4011
4012         The previous fix aligned the guard page sizes correctly but forgot to
4013         align the guard page start address correctly.
4014
4015         * bmalloc/Algorithm.h:
4016         (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
4017         up when not working with a power of two, instead of writing out the
4018         math by hand.
4019
4020         * bmalloc/VMHeap.cpp:
4021         (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
4022         page start address in addition to its size. Assert at the very end to
4023         try to catch more bugs.
4024
4025 2016-04-27  Geoffrey Garen  <ggaren@apple.com>
4026
4027         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
4028         https://bugs.webkit.org/show_bug.cgi?id=157047
4029
4030         Reviewed by Darin Adler.
4031
4032         * bmalloc/Chunk.h:
4033         (bmalloc::Chunk::Chunk):
4034         (bmalloc::Chunk::get):
4035         (bmalloc::Chunk::offset):
4036         (bmalloc::Chunk::address):
4037         (bmalloc::Object::Object):
4038         (bmalloc::Object::address):
4039         (bmalloc::Object::line):
4040         (bmalloc::Chunk::object): Deleted.
4041         (bmalloc::Object::begin): Deleted.
4042         * bmalloc/Heap.cpp:
4043         (bmalloc::Heap::allocateSmallBumpRangesByObject):
4044         * bmalloc/Object.h:
4045         (bmalloc::Object::chunk):
4046         (bmalloc::Object::offset): Renamed begin() to address() because this is
4047         not an iterator.
4048
4049         * bmalloc/VMHeap.cpp:
4050         (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
4051         multiple because pageSize might be smaller than vmPageSize, but we
4052         think the VM system requires vmPageSize-aligned values.
4053
4054 2016-04-25  Geoffrey Garen  <ggaren@apple.com>
4055
4056         bmalloc: vm allocations should plant guard pages