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