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