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