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