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