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