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