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