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