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