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