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