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