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