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