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