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