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