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