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