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