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