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