bmalloc: Don't use a whole page for metadata
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2016-02-21  Geoffrey Garen  <ggaren@apple.com>
2
3         bmalloc: Don't use a whole page for metadata
4         https://bugs.webkit.org/show_bug.cgi?id=154510
5
6         Reviewed by Andreas Kling.
7
8         (1) Don't round up metadata to a page boundary. This saves 1.5% dirty
9         memory on iOS and 0.2% on Mac. It also enables a future patch to allocate
10         smaller chunks without wasting memory.
11
12         (2) Initialize metadata lazily. This saves dirty memory when the program
13         allocates primarily small or large objects (but not both), leaving some
14         metadata uninitialized.
15
16         * bmalloc.xcodeproj/project.pbxproj: Medium objects are gone now.
17
18         * bmalloc/BumpAllocator.h:
19         (bmalloc::BumpAllocator::refill): Added an ASSERT to help debug a bug
20         I cause while working on this patch.
21
22         * bmalloc/Heap.cpp:
23         (bmalloc::Heap::allocateSmallBumpRanges): Ditto.
24
25         (bmalloc::Heap::splitAndAllocate):
26         (bmalloc::Heap::allocateLarge): Updated for interface change.
27
28         * bmalloc/LargeChunk.h: Changed the boundaryTagCount calculation to
29         a static_assert.
30
31         Don't round up to page boundary. (See above.)
32
33         (bmalloc::LargeChunk::LargeChunk): Moved code here from LargeChunk::init.
34         A constructor is a more natural / automatic way to do this initialization.
35
36         * bmalloc/LargeObject.h:
37         (bmalloc::LargeObject::init): Deleted. Moved to LargeChunk.
38
39         * bmalloc/Sizes.h: Chagned largeChunkMetadataSize to a simpler constant
40         because metadata size no longer varies by page size.
41
42         * bmalloc/SmallChunk.h:
43         (bmalloc::SmallChunk::begin):
44         (bmalloc::SmallChunk::end):
45         (bmalloc::SmallChunk::lines):
46         (bmalloc::SmallChunk::pages): Use std::array to make begin/end
47         calculations easier.
48
49         (bmalloc::SmallChunk::SmallChunk): Treat our metadata like a series
50         of allocated objects. We used to avoid trampling our metadata by
51         starting object memory at the next page. Now we share the first page
52         between metadata and objects, and we account for metadata explicitly.
53
54         * bmalloc/SuperChunk.h:
55         (bmalloc::SuperChunk::SuperChunk):
56         (bmalloc::SuperChunk::smallChunk):
57         (bmalloc::SuperChunk::largeChunk):
58         (bmalloc::SuperChunk::create): Deleted. Don't eagerly run the SmallChunk
59         and LargeChunk constructors. We'll run them lazily as needed.
60
61         * bmalloc/VMHeap.cpp:
62         (bmalloc::VMHeap::VMHeap):
63         (bmalloc::VMHeap::allocateSmallChunk):
64         (bmalloc::VMHeap::allocateLargeChunk):
65         (bmalloc::VMHeap::allocateSuperChunk):
66         (bmalloc::VMHeap::grow): Deleted. Track small and large chunks explicitly
67         so we can initialize them lazily.
68
69         * bmalloc/VMHeap.h:
70         (bmalloc::VMHeap::allocateSmallPage):
71         (bmalloc::VMHeap::allocateLargeObject): Specify whether we're allocating
72         a small or large chunk since we don't allocate both at once anymore.
73
74 2016-02-20  Mark Lam  <mark.lam@apple.com>
75
76         Use of inlined asm statements causes problems for -std=c99 builds.
77         https://bugs.webkit.org/show_bug.cgi?id=154507
78
79         Reviewed by Dan Bernstein.
80
81         * bmalloc/BAssert.h:
82
83 2016-02-19  Joonghun Park  <jh718.park@samsung.com>
84
85         Unreviewed. Fix debug build error since r196847
86
87         Fix gcc build warning appeared as below
88         by removing BASSERT(refCount <= maxRefCount).
89         error: comparison is always true due to limited range of data type
90         [-Werror=type-limits]
91
92         * bmalloc/SmallLine.h:
93         (bmalloc::SmallLine::ref): Deleted.
94
95 2016-02-19  Geoffrey Garen  <ggaren@apple.com>
96
97         bmalloc: Chunk, Page, and Line don't need to be class templates
98         https://bugs.webkit.org/show_bug.cgi?id=154480
99
100         Reviewed by Gavin Barraclough.
101
102         We needed class templates to distinguish between small and medium,
103         but medium is gone now.
104
105         * bmalloc.xcodeproj/project.pbxproj:
106         * bmalloc/Chunk.h: Removed.
107         * bmalloc/Heap.cpp:
108         (bmalloc::Heap::initializeLineMetadata):
109         (bmalloc::Heap::allocateSmallBumpRanges):
110         * bmalloc/Heap.h:
111         * bmalloc/Line.h: Removed.
112         * bmalloc/Page.h: Removed.
113         * bmalloc/Sizes.h:
114         * bmalloc/SmallChunk.h: Replaced with Source/bmalloc/bmalloc/Chunk.h.
115         (bmalloc::SmallChunk::begin):
116         (bmalloc::SmallChunk::end):
117         (bmalloc::SmallChunk::lines):
118         (bmalloc::SmallChunk::pages):
119         (bmalloc::SmallChunk::get):
120         (bmalloc::SmallLine::get):
121         (bmalloc::SmallLine::begin):
122         (bmalloc::SmallLine::end):
123         (bmalloc::SmallPage::get):
124         (bmalloc::SmallPage::begin):
125         (bmalloc::SmallPage::end):
126         (bmalloc::Chunk::begin): Deleted.
127         (bmalloc::Chunk::end): Deleted.
128         (bmalloc::Chunk::lines): Deleted.
129         (bmalloc::Chunk::pages): Deleted.
130         * bmalloc/SmallLine.h: Replaced with Source/bmalloc/bmalloc/Line.h.
131         (bmalloc::SmallLine::ref):
132         (bmalloc::SmallLine::deref):
133         (bmalloc::Line<Traits>::begin): Deleted.
134         (bmalloc::Line<Traits>::end): Deleted.
135         (bmalloc::Line<Traits>::ref): Deleted.
136         (bmalloc::Line<Traits>::deref): Deleted.
137         * bmalloc/SmallPage.h: Replaced with Source/bmalloc/bmalloc/Page.h.
138         (bmalloc::SmallPage::hasFreeLines):
139         (bmalloc::SmallPage::setHasFreeLines):
140         (bmalloc::SmallPage::ref):
141         (bmalloc::SmallPage::deref):
142         (bmalloc::Page::hasFreeLines): Deleted.
143         (bmalloc::Page::setHasFreeLines): Deleted.
144         (bmalloc::Page<Traits>::ref): Deleted.
145         (bmalloc::Page<Traits>::deref): Deleted.
146         * bmalloc/SmallTraits.h: Removed.
147
148 2016-02-18  Geoffrey Garen  <ggaren@apple.com>
149
150         bmalloc: Remove the concept of medium objects
151         https://bugs.webkit.org/show_bug.cgi?id=154436
152
153         Reviewed by Sam Weinig.
154
155         There's no need to distinguish medium objects from small: Small object
156         metadata works naturally for both as long as we allow an object to
157         span more than two small lines. (We already allow an object to span
158         more than one small line.)
159
160         This change reduces memory use because it eliminates the 1kB line size,
161         so we don't have to hold down 1kB lines for individual 264+ byte objects.
162
163         1kB lines were always a bit of a compromise. The main point of bump
164         allocation is to take advantage of cache lines. Cache lines are usually
165         64 bytes, so line sizes above 256 bytes are a bit of a stretch.
166
167         This change speeds up small object benchmarks because it eliminates the
168         branch to detect medium objects in deallocation log processing.
169
170         This change reduces virtual memory use from worst cast 4X to worst case
171         2X because the medium chunk is gone. iOS cares about virtual memory use
172         and terminates apps above ~1GB, so this change gives us more breathing room.
173
174         This change slows down medium benchmarks a bit because we end up doing
175         more work to recycle fragmented medium objects. Overall, the tradeoff
176         seems justified, since we have a net speedup and a memory use savings.
177
178         * bmalloc.xcodeproj/project.pbxproj: Removed all the medium files. We
179         can simplify even further in a follow-up patch, removing the base class
180         templates for Chunk, Page, and Line as well.
181
182         * bmalloc/Allocator.cpp:
183         (bmalloc::Allocator::Allocator):
184         (bmalloc::Allocator::allocate):
185         (bmalloc::Allocator::reallocate):
186         (bmalloc::Allocator::scavenge):
187         (bmalloc::Allocator::refillAllocatorSlowCase):
188         (bmalloc::Allocator::refillAllocator):
189         (bmalloc::Allocator::allocateSlowCase): Medium is gone. Small max is the
190         new medium max.
191
192         * bmalloc/Allocator.h:
193         (bmalloc::Allocator::allocateFastCase): Ditto.
194
195         * bmalloc/BumpAllocator.h:
196         (bmalloc::BumpAllocator::validate):
197         (bmalloc::BumpAllocator::allocate): No more medium.
198
199         * bmalloc/Chunk.h: No more medium.
200
201         * bmalloc/Deallocator.cpp:
202         (bmalloc::Deallocator::processObjectLog): No check for medium. This is
203         a speedup.
204
205         (bmalloc::Deallocator::deallocateSlowCase): No more medium.
206
207         * bmalloc/Deallocator.h:
208         (bmalloc::Deallocator::deallocateFastCase): Ditto.
209
210         * bmalloc/Heap.cpp:
211         (bmalloc::Heap::initializeLineMetadata): The algorithm here changed from
212         iterating each line to iterating each object. This helps us accomodate
213         objects that might span more than two lines -- i.e., all objects between
214         (512 bytes, 1024 bytes].
215
216         (bmalloc::Heap::scavenge):
217         (bmalloc::Heap::scavengeSmallPages):
218         (bmalloc::Heap::scavengeLargeObjects): Medium is gone.
219
220         (bmalloc::Heap::allocateSmallBumpRanges): Allow for lines that allocate
221         zero objects. This happens when an object spans more than two lines --
222         the middle lines allocate zero objects.
223
224         Also set the "has free lines" bit to false if we consume the last free
225         line. This needs to be a bit now because not all pages agree on their
226         maximum refcount anymore, so we need an explicit signal for the transition
227         from maximum to maximum - 1.
228
229         (bmalloc::Heap::allocateSmallPage): This code didn't change; I just removed
230         the medium code.
231
232         (bmalloc::Heap::deallocateSmallLine): Changed the algorithm to check
233         hasFreeLines. See allocateSmallBumpRanges.
234
235         (bmalloc::Heap::scavengeMediumPages): Deleted.
236         (bmalloc::Heap::allocateMediumBumpRanges): Deleted.
237         (bmalloc::Heap::allocateMediumPage): Deleted.
238         (bmalloc::Heap::deallocateMediumLine): Deleted.
239         * bmalloc/Heap.h:
240         (bmalloc::Heap::derefMediumLine): Deleted.
241
242         * bmalloc/LargeChunk.h:
243         (bmalloc::LargeChunk::get):
244         (bmalloc::LargeChunk::endTag):
245         * bmalloc/Line.h: No more medium.
246
247         * bmalloc/MediumChunk.h: Removed.
248         * bmalloc/MediumLine.h: Removed.
249         * bmalloc/MediumPage.h: Removed.
250         * bmalloc/MediumTraits.h: Removed.
251
252         * bmalloc/ObjectType.cpp:
253         (bmalloc::objectType):
254         * bmalloc/ObjectType.h:
255         (bmalloc::isSmall):
256         (bmalloc::isXLarge):
257         (bmalloc::isSmallOrMedium): Deleted.
258         (bmalloc::isMedium): Deleted. No more medium.
259
260         * bmalloc/Page.h:
261         (bmalloc::Page::sizeClass):
262         (bmalloc::Page::setSizeClass):
263         (bmalloc::Page::hasFreeLines):
264         (bmalloc::Page::setHasFreeLines): Add the free lines bit. You get better
265         codegen if you make it the low bit, since ref / deref can then add / sub
266         2. So do that.
267
268         * bmalloc/Sizes.h:
269         (bmalloc::Sizes::sizeClass): Expand the small size class to include the
270         medium size class.
271
272         * bmalloc/SuperChunk.h:
273         (bmalloc::SuperChunk::SuperChunk):
274         (bmalloc::SuperChunk::smallChunk):
275         (bmalloc::SuperChunk::largeChunk):
276         (bmalloc::SuperChunk::mediumChunk): Deleted. No more medium.
277
278         * bmalloc/VMHeap.cpp:
279         (bmalloc::VMHeap::grow):
280         * bmalloc/VMHeap.h:
281         (bmalloc::VMHeap::allocateSmallPage): Set the has free lines bit before
282         returning a Page to the Heap since this is the correct default state
283         when we first allocate a page.
284
285         (bmalloc::VMHeap::allocateMediumPage): Deleted.
286         (bmalloc::VMHeap::deallocateMediumPage): Deleted.
287
288 2016-02-19  Michael Saboff  <msaboff@apple.com>
289
290         bmalloc: Unify VMHeap and Heap LargeObjects free lists to reduce fragmentation
291         https://bugs.webkit.org/show_bug.cgi?id=154192
292
293         Reviewed by Geoffrey Garen.
294
295         Change the operation of Heap and VMHeap LargeObject free lists.
296         Renamed Owner to VMState to track the state of each LargeObject.
297             Physical - The pages have been allocated.
298             Virtual - The pages have not been allocated.
299             Mixed - The object contains a mixture of Physical and Virtual pages.
300         VMState uses one bit each for Physical and Virtual to simplify merging states
301         when merging two adjacent blocks.  This change enforces the rule that objects in
302         the Heap free list must have have the Physical bit set in their VMState while objects
303         in the VMHeap free list must have the Physical bit clear.  Thie means that the Heap
304         can have LargeObjects in Physical or Mixed VMState, but the VMHeap's free list can
305         only contain Virtual LargeObjects.
306         
307         In both Heap::allocateLarge(), we now allocate physical pages if the LargeObject we
308         pull from the free list has any Virtual pages before we possilby split the 
309         object.  When we merge objects, the result might be made up of Mixed page allocations.
310         When allocating a Mixed LargeObject, we need to allocate memory for them as well.
311         The scavenger deallocates both Physical and Mixed LargeObjects, placing them back into
312         the VMHeap's free list.
313
314         When we allocate or deallocate Mixed LargeObjects, there are pages that within these
315         objects that will be redundantly modified.  It would require additional metadata to
316         eliminate this redundancy.
317
318         * bmalloc.xcodeproj/project.pbxproj:
319         * bmalloc/BoundaryTag.h:
320         (bmalloc::BoundaryTag::vmState): New helper.
321         (bmalloc::BoundaryTag::setVMState): New helper.
322         (bmalloc::BoundaryTag::owner): Deleted.
323         (bmalloc::BoundaryTag::setOwner): Deleted.
324         * bmalloc/Heap.h:
325         (bmalloc::Heap::splitAndAllocate): New helpers.
326         * bmalloc/LargeObject.h:
327         (bmalloc::LargeObject::vmState): New helper.
328         (bmalloc::LargeObject::setVMState): New helper.
329
330         * bmalloc/Heap.cpp:
331         (bmalloc::Heap::splitAndAllocate): New helpers.
332         (bmalloc::Heap::allocateLarge): 
333         (bmalloc::Heap::deallocatePhysicalPages): Refactored from VMHeap::deallocateLargeObjectMemory.
334
335         * bmalloc/FreeList.cpp:
336         (bmalloc::FreeList::takeGreedy):
337         (bmalloc::FreeList::take):
338         (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
339         * bmalloc/FreeList.h:
340         (bmalloc::FreeList::FreeList):
341         (bmalloc::FreeList::push):
342         * bmalloc/Heap.cpp:
343         (bmalloc::Heap::Heap):
344         (bmalloc::Heap::scavengeLargeObjects):
345         * bmalloc/LargeObject.h:
346         (bmalloc::LargeObject::isValidAndFree):
347         (bmalloc::LargeObject::validateSelf):
348         * bmalloc/SegregatedFreeList.cpp:
349         (bmalloc::SegregatedFreeList::SegregatedFreeList): Changed to initialize our required Physical state.
350         * bmalloc/SegregatedFreeList.h:
351         (bmalloc::SegregatedFreeList::SegregatedFreeList):
352         (bmalloc::SegregatedFreeList::insert):
353         (bmalloc::SegregatedFreeList::takeGreedy):
354         (bmalloc::SegregatedFreeList::take):
355         Replaced Owner parameters and checks with VMState::HasPhysical.
356
357         * bmalloc/LargeObject.h:
358         (bmalloc::LargeObject::prevCanMerge): Removed owner from tests.
359         (bmalloc::LargeObject::nextCanMerge): Removed owner from tests.
360         (bmalloc::LargeObject::merge): Removed owner from tests.  Updated to merge VMStates andset the
361         VMState after the merge.
362
363         * bmalloc/LargeObject.h:
364         (bmalloc::LargeObject::owner): Deleted.
365         (bmalloc::LargeObject::setOwner): Deleted.
366
367         * bmalloc/Owner.h: Removed.
368
369         * bmalloc/VMAllocate.h:
370         (bmalloc::vmAllocatePhysicalPagesSloppy): Changed to round begin down to eliminate the left to right
371         allocation constraint.
372
373         * bmalloc/VMHeap.cpp:
374         (bmalloc::VMHeap::grow): Large space managed like small or medium as a vector of LargeChunks.
375         (bmalloc::VMHeap::VMHeap): Changed to initialize our required Physical state.
376
377         * bmalloc/VMHeap.h:
378         (bmalloc::VMHeap::allocateLargeObject): These no longer allocate memory.
379         (bmalloc::VMHeap::deallocateLargeObject): Removed setOwner.  Now we set the VMState after any merges.
380
381         * bmalloc/VMState.h: Copied from Source/bmalloc/bmalloc/Owner.h.
382         (bmalloc::VMState::VMState):
383         (bmalloc::VMState::hasPhysical):
384         (bmalloc::VMState::hasVirtual):
385         (bmalloc::VMState::merge):
386         (bmalloc::VMState::operator ==):
387         (bmalloc::VMState::operator unsigned):
388         New class with various helpers.
389
390 2016-02-12  Michael Saboff  <msaboff@apple.com>
391
392         BASSERTs added in r196421 are causing debug test failures
393         https://bugs.webkit.org/show_bug.cgi?id=154113
394
395         Reviewed by Geoffrey Garen.
396
397         In VMHeap::deallocateLargeObject(), we drop the lock to deallocate the physical pages.
398         If the scavenger thread is running at the same time a synchronous call to scavenge()
399         comes in, we could call VMHeap::deallocateLargeObject() for an adjacent object while the
400         lock in the other thread is dropped.  We fix this by checking for adjacent objects we
401         can merge with and loop if we have one.
402
403         * bmalloc/FreeList.h:
404         (bmalloc::FreeList::push): Added BASSERT to catch adding unmerged free objects
405         * bmalloc/Heap.cpp:
406         (bmalloc::Heap::allocateLarge): Changed to use nextCanMerge().
407         * bmalloc/LargeObject.h:
408         (bmalloc::LargeObject::prevCanMerge): Repurposed prevIsAllocated.
409         (bmalloc::LargeObject::nextCanMerge): Repurposed nextIsAllocated.
410         (bmalloc::LargeObject::prevIsAllocated): Deleted.
411         (bmalloc::LargeObject::nextIsAllocated): Deleted.
412         * bmalloc/VMHeap.h:
413         (bmalloc::VMHeap::allocateLargeObject): Moved adding the extra object back to the free list
414         to after we set the object we'll return as being allocated.
415         (bmalloc::VMHeap::deallocateLargeObject):
416
417 2016-02-12  Mark Lam  <mark.lam@apple.com>
418
419         Make BCRASH() use breakpoint traps too for non-debug OS(DARWIN).
420         https://bugs.webkit.org/show_bug.cgi?id=154184
421
422         Reviewed by Saam Barati.
423
424         This makes it behave consistently with WTFCrash().
425
426         * bmalloc/BAssert.h:
427         * bmalloc/BPlatform.h:
428
429 2016-02-11  Michael Saboff  <msaboff@apple.com>
430
431         Unreviewed build fix after r196421.
432
433         Removed BASSERTs that are firing to eliminate Debug build crashes.  I'll debug locally and
434         enable or alter after the issue is understood.
435
436         * bmalloc/LargeObject.h:
437         (bmalloc::LargeObject::merge): Removed BASSERTs that are firing.
438
439 2016-02-11  Michael Saboff  <msaboff@apple.com>
440
441         bmalloc: large aligned allocations will put 1 or 2 free object on free list without merging with free neighbors
442         https://bugs.webkit.org/show_bug.cgi?id=154091
443
444         Reviewed by Geoffrey Garen.
445
446         If we split off any unused free object in the aligned version of Heap::allocateLarge(), we merge them with
447         free neighbors before putting them back on the free list.  Added helpers to verify that when we
448         add LargeObjects to the free list their neighbors are allocated.
449
450         * bmalloc/Heap.cpp:
451         (bmalloc::Heap::allocateLarge): Deleted private helper version and rolled it into the two the
452         two public versions of allocateLarge().
453         * bmalloc/Heap.h:
454         * bmalloc/LargeObject.h:
455         (bmalloc::LargeObject::prevIsAllocated): New helper.
456         (bmalloc::LargeObject::nextIsAllocated): New helper.
457         (bmalloc::LargeObject::merge): Check that the merge object has allocated neighbors.
458
459 2016-02-05  Saam barati  <sbarati@apple.com>
460
461         bmalloc: largeMax calculation is wrong on iOS
462         https://bugs.webkit.org/show_bug.cgi?id=153923
463
464         Reviewed by Mark Lam.
465
466         Our number for largeMax was larger than what we had
467         space to actually allocate inside the LargeChunk. This made 
468         it so that we would allocate a large object for something
469         that really should be extra large. Previously:
470         largeMax + sizeof(LargeChunk) > 1MB
471         which meant that when we would grow() to accommodate an allocation
472         of a particular size inside a LargeObject despite the fact that
473         the allocation size would be too large to actually fit in the LargeObject.
474         This would manifest when we had an allocation size in the range:
475         1MB - sizeof(LargeChunk) < allocation size < largeMax
476
477         We fix this bug by being precise in our calculation of largeMax
478         instead of just assuming largeChunkSize * 99/100 is enough
479         space for the metadata.
480
481         * bmalloc/LargeChunk.h:
482         (bmalloc::LargeChunk::get):
483         * bmalloc/Sizes.h:
484
485 2016-01-31  Dan Bernstein  <mitz@apple.com>
486
487         [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
488         https://bugs.webkit.org/show_bug.cgi?id=153729
489
490         Reviewed by Sam Weinig.
491
492         After r141700, HAVE_HEADER_DETECTION_H is no longer used.
493
494         * Configurations/Base.xcconfig:
495
496 2015-12-19  Dan Bernstein  <mitz@apple.com>
497
498         [Mac] WebKit contains dead source code for OS X Mavericks and earlier
499         https://bugs.webkit.org/show_bug.cgi?id=152462
500
501         Reviewed by Alexey Proskuryakov.
502
503         * Configurations/DebugRelease.xcconfig: Removed definition of MACOSX_DEPLOYMENT_TARGET for
504           OS X 10.9.
505
506 2015-12-03  Anders Carlsson  <andersca@apple.com>
507
508         Remove Objective-C GC support
509         https://bugs.webkit.org/show_bug.cgi?id=151819
510         rdar://problem/23746991
511
512         Reviewed by Dan Bernstein.
513
514         * Configurations/Base.xcconfig:
515
516 2015-12-03  Michael Saboff  <msaboff@apple.com>
517
518         bmalloc: extra large allocations could be more efficient
519         https://bugs.webkit.org/show_bug.cgi?id=151817
520
521         Reviewed by Geoffrey Garen.
522
523         Reduced the super chunk size from 4MB to 2MB.
524
525         Added path to reallocate() of an extra large object to see if we can extend the allocation.
526
527         * bmalloc/Allocator.cpp:
528         (bmalloc::Allocator::reallocate):
529         * bmalloc/SegregatedFreeList.h:
530         * bmalloc/Sizes.h:
531         * bmalloc/VMAllocate.h:
532         (bmalloc::tryVMAllocate):
533         (bmalloc::tryVMExtend):
534         (bmalloc::vmAllocate):
535
536 2015-11-11  Akos Kiss  <akiss@inf.u-szeged.hu>
537
538         bmalloc: Add libdl dependency
539         https://bugs.webkit.org/show_bug.cgi?id=151140
540
541         Reviewed by Csaba Osztrogonác.
542
543         Make sure that the linker links libdl and finds the references to
544         dlopen, dlsym and dlclose in Environment.cpp.
545
546         * CMakeLists.txt:
547
548 2015-11-02  Andy Estes  <aestes@apple.com>
549
550         [Cocoa] Add tvOS and watchOS to SUPPORTED_PLATFORMS
551         https://bugs.webkit.org/show_bug.cgi?id=150819
552
553         Reviewed by Dan Bernstein.
554
555         This tells Xcode to include these platforms in its Devices dropdown, making it possible to build in the IDE.
556
557         * Configurations/Base.xcconfig:
558
559 2015-11-01  Philip Chimento  <philip.chimento@gmail.com>
560
561         [GTK] Fix combinations of PLATFORM(GTK) and OS(DARWIN)
562         https://bugs.webkit.org/show_bug.cgi?id=144560
563
564         Reviewed by Darin Adler.
565
566         * PlatformGTK.cmake: Added. This adds Zone.cpp to the PlatformGTK
567         build, on Darwin only. Since there was previously nothing for the
568         build system to do that was specific to the GTK platform in
569         bmalloc, we need to create this file.
570
571 2015-10-29  Geoffrey Garen  <ggaren@apple.com>
572
573         bmalloc: AsyncTask should handle destruction
574         https://bugs.webkit.org/show_bug.cgi?id=150648
575
576         Reviewed by Mark Lam.
577
578         So we can use it in more places.
579
580         * bmalloc/AsyncTask.h: Use std::thread instead of pthread because it
581         should be more portable.
582
583         (bmalloc::Function>::AsyncTask): Renamed Signaled to RunRequested for
584         clarity. Added an ExitRequested state.
585
586         (bmalloc::Function>::~AsyncTask): Wait for our child thread to exit
587         before destroying ourselves because our child thread will modify our
588         data (and might modify our client's data). Note that we only need to
589         wait for the last child thread since any prior child thread, having
590         reached the Exited condition, is guaranteed not to read or write any
591         data.
592
593         (bmalloc::Function>::run):
594         (bmalloc::Function>::runSlowCase): Updated for interface changes. Also
595         changed to use our WebKit style for condition signal: Hold the lock
596         during the signal and always notify all. Technically, neither is necessary,
597         but it is easier to understand the code this way, and harder to make
598         mistakes.
599
600         (bmalloc::Function>::threadEntryPoint):
601         (bmalloc::Function>::threadRunLoop): Handle the new ExitRequested state.
602         Technically, this state has no meaningful difference from the Exited
603         state, but it is nice to be explicit.
604
605         (bmalloc::Function>::join): Deleted.
606         (bmalloc::Function>::pthreadEntryPoint): Deleted.
607         (bmalloc::Function>::entryPoint): Deleted.
608
609 2015-10-15  Geoffrey Garen  <ggaren@apple.com>
610
611         bmalloc: per-thread cache data structure should be smaller
612         https://bugs.webkit.org/show_bug.cgi?id=150218
613
614         Reviewed by Andreas Kling.
615
616         Reduce the number of entries in the range cache because it's really
617         big, and the bigness only helps in cases of serious fragmentation, and
618         it only saves us a little bit of lock acquisition time.
619
620         * bmalloc/Allocator.cpp:
621         (bmalloc::Allocator::scavenge):
622         (bmalloc::Allocator::refillAllocatorSlowCase):
623         (bmalloc::Allocator::refillAllocator):
624         (bmalloc::Allocator::allocateLarge):
625         (bmalloc::Allocator::allocateSlowCase):
626         (bmalloc::Allocator::allocateBumpRangeSlowCase): Deleted.
627         (bmalloc::Allocator::allocateBumpRange): Deleted.
628         * bmalloc/Allocator.h: Pass through the empty allocator and the range
629         cache when refilling, and refill both. Otherwise, we always immediately
630         pop the last item in the range cache, wasting that slot of capacity.
631
632         * bmalloc/Heap.cpp:
633         (bmalloc::Heap::allocateSmallBumpRanges):
634         (bmalloc::Heap::allocateMediumBumpRanges): Account for the fact that
635         the range cache is no longer big enough to guarantee that it can hold
636         all the ranges in a page.
637
638         (bmalloc::Heap::refillSmallBumpRangeCache): Deleted.
639         (bmalloc::Heap::refillMediumBumpRangeCache): Deleted.
640
641         * bmalloc/Heap.h: Move VMHeap to the end of the object because it
642         contains a lot of unused / wasted space, and we want to pack our data
643         together in memory.
644
645         * bmalloc/Sizes.h: Make the range cache smaller.
646
647 2015-10-13  Chris Dumez  <cdumez@apple.com>
648
649         Avoid useless copies in range-loops that are using 'auto'
650         https://bugs.webkit.org/show_bug.cgi?id=150091
651
652         Reviewed by Sam Weinig.
653
654         Avoid useless copies in range-loops that are using 'auto'. Also use
655         'auto*' instead of 'auto' when range values are pointers for clarity.
656
657         * bmalloc/Deallocator.cpp:
658         (bmalloc::Deallocator::processObjectLog):
659
660 2015-10-12  Geoffrey Garen  <ggaren@apple.com>
661
662         bmalloc: Don't ASSERT that all syscalls succeed
663         https://bugs.webkit.org/show_bug.cgi?id=150047
664         <rdar://problem/22649531>
665
666         Reviewed by Mark Lam.
667
668         madvise can fail due to VM behaviors outside of our control:
669         copy-on-write, fork, mprotect, and other stuff.
670
671         Older darwin kernels sometimes return this error value, and new kernels
672         might again in future.
673
674         We haven't gained much from this ASSERT so far, so let's remove it.
675
676         Perhaps in future we can come up with a scheme that makes madvise
677         never fail, or that responds to failure.
678
679         * bmalloc/Syscall.h:
680
681 2015-10-10  Dan Bernstein  <mitz@apple.com>
682
683         [iOS] Remove project support for iOS 8
684         https://bugs.webkit.org/show_bug.cgi?id=149993
685
686         Reviewed by Alexey Proskuryakov.
687
688         * Configurations/Base.xcconfig:
689         * Configurations/bmalloc.xcconfig:
690         * Configurations/mbmalloc.xcconfig:
691
692 2015-08-31  Michael Catanzaro  <mcatanzaro@igalia.com>
693
694         Implement bmalloc::isASanEnabled for generic Unix
695         https://bugs.webkit.org/show_bug.cgi?id=148623
696
697         Reviewed by Geoffrey Garen.
698
699         * bmalloc/BPlatform.h: Add BOS_UNIX to detect whether the OS is a Unix.
700         * bmalloc/Environment.cpp:
701         (bmalloc::isASanEnabled): Implement a runtime check that should work on any Unix.
702
703 2015-08-19  Geoffrey Garen  <ggaren@apple.com>
704
705         Crash @ bmalloc::Environment::computeIsBmallocEnabled
706         https://bugs.webkit.org/show_bug.cgi?id=148183
707
708         Reviewed by NOBODY Michael Saboff.
709
710         CrashTracer says we have some crashes beneath computeIsBmallocEnabled
711         dereferencing null in strstr. We null check getenv but not
712         _dyld_get_image_name, so deduction indicates that _dyld_get_image_name
713         must be returning null. _dyld_get_image_name isn't really documented,
714         so let's assume it can return null.
715
716         * bmalloc/Environment.cpp:
717         (bmalloc::isASanEnabled): Check _dyld_get_image_name's return value for
718         null because we can't prove it won't be null.
719
720 2015-07-24  Geoffrey Garen  <ggaren@apple.com>
721
722         vmmap crash at JavaScriptCore: 0x31cd12f6 (the JavaScript malloc zone enumerator)
723         https://bugs.webkit.org/show_bug.cgi?id=147274
724
725         Reviewed by Anders Carlsson.
726
727         It's not really clear why vmmap sometimes fails to read the target
728         process, but we can avoid a crash when it does. This is useful because
729         you'll still get all the non-bmalloc data out of the target process,
730         and bmalloc might not even be relevant to your investigation.
731
732         * bmalloc/Zone.cpp:
733         (bmalloc::remoteRead): Check for failure.
734
735 2015-07-24  Geoffrey Garen  <ggaren@apple.com>
736
737         JavaScriptCore bmalloc should not register its malloc zone more than once
738         https://bugs.webkit.org/show_bug.cgi?id=147273
739
740         Reviewed by Andreas Kling.
741
742         This was a goof: The Zone constructor, by virtue of running automatically,
743         was registering a Zone inside the analysis process.
744
745         * bmalloc/Zone.cpp:
746         (bmalloc::remoteRead): Clarify that the pointer is remote.
747
748         (bmalloc::enumerator):
749         (bmalloc::Zone::Zone):
750         * bmalloc/Zone.h: Separate the normal constructor and the remote constructor.
751         The remote constructor skips zone registration since its goal is not
752         to register a zone in the current process or do any allocation but rather
753         to mirror the bytes of the zone from the target process.
754
755 2015-07-23  Geoffrey Garen  <ggaren@apple.com>
756
757         bmalloc: Shrink the super chunk size (again)
758         https://bugs.webkit.org/show_bug.cgi?id=147240
759
760         Reviewed by Andreas Kling.
761
762         Shrinking to 8MB reduced VM exhaustion crashes but did not eliminate them.
763         Let's try 4MB.
764
765         (My previous comment was that the maximum fast object was 2MB. But it
766         was 4MB! Now it's 2MB for realsies.)
767
768         * bmalloc/Sizes.h:
769
770 2015-07-03  Dan Bernstein  <mitz@apple.com>
771
772         [Xcode] Update some build settings as recommended by Xcode 7
773         https://bugs.webkit.org/show_bug.cgi?id=146597
774
775         Reviewed by Sam Weinig.
776
777         * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE, GCC_NO_COMMON_BLOCKS,
778         and ENABLE_STRICT_OBJC_MSGSEND. Removed GCC_MODEL_TUNING.
779
780         * bmalloc.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
781
782 2015-07-02  Geoffrey Garen  <ggaren@apple.com>
783
784         bmalloc: Shrink the super chunk size
785         https://bugs.webkit.org/show_bug.cgi?id=146519
786
787         Reviewed by Andreas Kling.
788
789         We have lots of reports of crashing due to failed VM allocation on iOS.
790         (This VM limit on iOS is usually 1GB-2GB, and has been as low as 256MB.)
791
792         Shrink the super chunk size in case fragmentation is the reason for
793         VM allocation failure.
794
795         This has the downside that >= 2MB allocations will now be super slow,
796         but they are also super rare (as in never on most websites), so this
797         is probably an OK tradeoff.
798
799         * bmalloc/Sizes.h:
800
801 2015-07-01  Geoffrey Garen  <ggaren@apple.com>
802
803         bmalloc: realloc of an XLarge range can unmap adjacent VM ranges
804         https://bugs.webkit.org/show_bug.cgi?id=146535
805
806         Reviewed by Anders Carlsson.
807
808         This bug causes a crash when running fast/css/large-list-of-rules-crash.html
809         with the fix applied for https://bugs.webkit.org/show_bug.cgi?id=146519.
810
811         * bmalloc/Allocator.cpp:
812         (bmalloc::Allocator::reallocate): Start at object + newSize since starting
813         at object + oldSize means deleting the adjacent VM range.
814
815 2015-05-26  Geoffrey Garen  <ggaren@apple.com>
816
817         Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf)
818         https://bugs.webkit.org/show_bug.cgi?id=145385
819
820         Reviewed by Andreas Kling.
821
822         Added some checking to verify that round-up operations will not overflow
823         a size_t.
824
825         The simplest way to do this was to introduce a notion of xLargeMax, like
826         we have for smallMax, mediumMax, and largeMax. It's a bit surprising at
827         first to think that there is an xLargeMax, since xLarge is what we use
828         to handle the biggest things. But computers have limits, so it makes sense.
829
830         FWIW, TCMalloc used to have an xLargeMax too, which it called kMaxValidPages.
831
832         No test because this bug was found by code inspection and I don't know
833         of a practical way to convince WebKit to make an allocation this large.
834
835         * bmalloc/Allocator.cpp:
836         (bmalloc::Allocator::tryAllocate):
837         (bmalloc::Allocator::allocate):
838         (bmalloc::Allocator::reallocate):
839         (bmalloc::Allocator::allocateSlowCase): Check against xLargeMax to avoid
840         overflow when rounding up.
841
842         * bmalloc/BAssert.h: Added support for explicit crashing.
843
844         * bmalloc/Sizes.h:
845
846 2015-05-26  Dan Bernstein  <mitz@apple.com>
847
848         <rdar://problem/21104551> Update build settings
849
850         Reviewed by Anders Carlsson.
851
852         * Configurations/DebugRelease.xcconfig:
853
854 2015-05-23  Dan Bernstein  <mitz@apple.com>
855
856         Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
857         https://bugs.webkit.org/show_bug.cgi?id=145345
858
859         Reviewed by Sam Weinig.
860
861         * Configurations/Base.xcconfig: Also changed to use $(inherited).
862
863 2015-05-07  Geoffrey Garen  <ggaren@apple.com>
864
865         Release assert in com.apple.WebKit.WebContent under JavaScriptCore: JSC::JSONProtoFuncStringify
866         https://bugs.webkit.org/show_bug.cgi?id=144758
867
868         Reviewed by Andreas Kling.
869
870         This was an out-of-memory error when trying to shrink a string builder.
871         bmalloc was missing the optimization that allowed realloc() to shrink
872         without copying. So, let's add it.
873
874         * bmalloc/Allocator.cpp:
875         (bmalloc::Allocator::reallocate): Added Large and XLarge cases for
876         shrinking without copying. This isn't possible for small and medium
877         objects, and probably not very profitable, either.
878
879         * bmalloc/Heap.cpp:
880         (bmalloc::Heap::findXLarge):
881         (bmalloc::Heap::deallocateXLarge):
882         * bmalloc/Heap.h: Refactored this code to return a reference to an
883         XLarge range. This makes the code reusable, and also makes it easier
884         for realloc() to update metadata.
885
886         * bmalloc/LargeObject.h:
887         (bmalloc::LargeObject::split): Allow allocated objects to split because
888         that's what realloc() wants to do, and there's nothing intrinsically
889         wrong with it.
890
891 2015-05-07  Dan Bernstein  <mitz@apple.com>
892
893         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
894         https://bugs.webkit.org/show_bug.cgi?id=144727
895
896         Reviewed by Darin Adler.
897
898         * Configurations/Base.xcconfig: Dont’s include AspenFamily.xcconfig, and define
899         INSTALL_PATH_PREFIX for the iOS 8.x Simulator.
900
901 2015-04-01  Alex Christensen  <achristensen@webkit.org>
902
903         Progress towards CMake on Windows and Mac.
904         https://bugs.webkit.org/show_bug.cgi?id=143293
905
906         Reviewed by Filip Pizlo.
907
908         * bmalloc/BAssert.h:
909         Removed ellipses from macros to appease Visual Studio.
910
911 2015-03-13  Alex Christensen  <achristensen@webkit.org>
912
913         Progress towards CMake on Mac.
914         https://bugs.webkit.org/show_bug.cgi?id=142680
915
916         Reviewed by Gyuyoung Kim.
917
918         * CMakeLists.txt:
919         * PlatformMac.cmake:
920         Added Zone.cpp to Mac CMake builds.
921
922 2015-03-12  Geoffrey Garen  <ggaren@apple.com>
923
924         Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
925         https://bugs.webkit.org/show_bug.cgi?id=142642
926
927         Reviewed by Michael Saboff.
928
929         The typical backtrace to this crash shows the main thread trying to
930         realloc a large string while a DFG compiler thread tries to
931         free a large vector buffer.
932
933         I believe that this is a race condition -- at least in debug builds --
934         since the main thread will try to validate its object's neighbors
935         without holding a lock, even though those neighbors might be in the
936         midst of changing.
937
938         In general, there may be sneaky times when it is valid to look at an
939         object's metadata without holding the heap lock, but it is best not to
940         do so unless we have a really really good reason to.
941
942         * bmalloc/Allocator.cpp:
943         (bmalloc::Allocator::reallocate): Take a lock before reading the metadata
944         for this object, since we generally require any access to shared heap
945         metadata to take a lock.
946
947 2015-03-10  Geoffrey Garen  <ggaren@apple.com>
948
949         bmalloc: tryFastMalloc shouldn't crash
950         https://bugs.webkit.org/show_bug.cgi?id=142443
951
952         Reviewed by Sam Weinig.
953
954         Rolling back in r181307 with a check for whether bmalloc is enabled, to
955         avoid crashes when running with ASan and GuardMalloc.
956
957         * bmalloc/Allocator.cpp:
958         (bmalloc::Allocator::tryAllocate):
959         * bmalloc/Allocator.h:
960         * bmalloc/Cache.cpp:
961         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
962         * bmalloc/Cache.h:
963         (bmalloc::Cache::tryAllocate):
964         * bmalloc/Heap.cpp:
965         (bmalloc::Heap::allocateXLarge):
966         (bmalloc::Heap::tryAllocateXLarge):
967         * bmalloc/Heap.h:
968         * bmalloc/VMAllocate.h:
969         (bmalloc::tryVMAllocate):
970         (bmalloc::vmAllocate):
971         * bmalloc/bmalloc.h:
972         (bmalloc::api::tryMalloc):
973         (bmalloc::api::realloc):
974         (bmalloc::api::free):
975
976 2015-03-09  Commit Queue  <commit-queue@webkit.org>
977
978         Unreviewed, rolling out r181307.
979         https://bugs.webkit.org/show_bug.cgi?id=142525
980
981         Broke ASan tests (Requested by ap on #webkit).
982
983         Reverted changeset:
984
985         "bmalloc: tryFastMalloc shouldn't crash"
986         https://bugs.webkit.org/show_bug.cgi?id=142443
987         http://trac.webkit.org/changeset/181307
988
989 2015-03-09  Geoffrey Garen  <ggaren@apple.com>
990
991         bmalloc: tryFastMalloc shouldn't crash
992         https://bugs.webkit.org/show_bug.cgi?id=142443
993
994         Reviewed by Darin Adler.
995
996         Added support for tryMalloc.
997
998         We assume that non-x-large allocations always succeed, and we crash
999         otherwise, since normal allocation failure will just cause the next
1000         non-try allocation or internal metadata allocation to fail, and it's
1001         hard and not really useful to keep limping along after that. But
1002         extra-large allocations can meaningfully fail, and we can recover.
1003
1004         * bmalloc/Heap.cpp:
1005         (bmalloc::Heap::allocateXLarge):
1006         (bmalloc::Heap::tryAllocateXLarge):
1007         * bmalloc/Heap.h: Added support for non-crashy x-large allocation.
1008
1009         * bmalloc/VMAllocate.h:
1010         (bmalloc::tryVMAllocate):
1011         (bmalloc::vmAllocate): Added support for non-crashy VM allocation.
1012
1013         * bmalloc/bmalloc.h:
1014         (bmalloc::api::tryMalloc):
1015         (bmalloc::api::realloc):
1016         (bmalloc::api::free): Tried to clarify our behavior with some comments.
1017         Unfortunately, calling what we do "malloc" is still not quite right, since
1018         malloc returns null on failure and we don't.
1019
1020 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
1021
1022         bmalloc: Don't branch when setting the owner of a large object
1023         https://bugs.webkit.org/show_bug.cgi?id=142241
1024
1025         Reviewed by Andreas Kling.
1026
1027         * bmalloc/BoundaryTag.h:
1028         (bmalloc::BoundaryTag::owner):
1029         (bmalloc::BoundaryTag::setOwner):
1030
1031 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
1032
1033         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
1034         https://bugs.webkit.org/show_bug.cgi?id=141802
1035
1036         Reviewed by Andreas Kling.
1037
1038         Re-enabled this feature on iOS, now that the iOS crash should be fixed.
1039
1040         * bmalloc/VMHeap.cpp:
1041         (bmalloc::VMHeap::grow):
1042         * bmalloc/VMHeap.h:
1043
1044 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
1045
1046         bmalloc: Added missing features to the malloc zone introspection API
1047         https://bugs.webkit.org/show_bug.cgi?id=142235
1048
1049         Reviewed by Andreas Kling.
1050
1051         This should fix the crash we saw on the iOS PLT bot
1052         (c.f. http://trac.webkit.org/changeset/180604).
1053
1054         * bmalloc/Zone.cpp:
1055         (bmalloc::good_size):
1056         (bmalloc::check):
1057         (bmalloc::print):
1058         (bmalloc::log):
1059         (bmalloc::force_lock):
1060         (bmalloc::force_unlock):
1061         (bmalloc::statistics):
1062         (bmalloc::size):
1063         (bmalloc::enumerator): Provide all of these functions since they are called
1064         indiscriminately on all zones.
1065
1066         (bmalloc::Zone::Zone):
1067         (bmalloc::Zone::size): Deleted.
1068         (bmalloc::Zone::enumerator): Deleted. Moved these functions out of the
1069         Zone class since they can stand alone.
1070
1071         * bmalloc/Zone.h:
1072
1073 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
1074
1075         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
1076         https://bugs.webkit.org/show_bug.cgi?id=141802
1077
1078         Reviewed by Andreas Kling.
1079
1080         Rolling back in but disabled on iOS until I can debug why the iOS PLT crashes.
1081
1082         * bmalloc/VMHeap.cpp:
1083         (bmalloc::VMHeap::grow):
1084         * bmalloc/VMHeap.h:
1085         * bmalloc/Zone.cpp:
1086         (bmalloc::Zone::size):
1087         (bmalloc::Zone::Zone):
1088         * bmalloc/Zone.h:
1089
1090 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
1091
1092         bmalloc: Miscellaneous cleanup
1093         https://bugs.webkit.org/show_bug.cgi?id=142231
1094
1095         Reviewed by Andreas Kling.
1096
1097         No performance change -- maybe a tiny reduction in memory use.
1098
1099         * bmalloc/Heap.cpp: Moved the sleep function into StaticMutex, since
1100         it's a helper for working with mutexes.
1101
1102         (bmalloc::Heap::scavenge): Make sure to wait before we start any
1103         scavenging, since individual scavenging functions now always scavenge
1104         at least one page before waiting themselves.
1105
1106         (bmalloc::Heap::scavengeSmallPages):
1107         (bmalloc::Heap::scavengeMediumPages):
1108         (bmalloc::Heap::scavengeLargeObjects): Use the new wait helper to
1109         simplify this code. Also, we now require our caller to wait until at
1110         least one deallocation is desirable. This simplifies our loop.
1111
1112         (bmalloc::Heap::allocateSmallPage):
1113         (bmalloc::Heap::allocateMediumPage):
1114         (bmalloc::Heap::allocateXLarge):
1115         (bmalloc::Heap::allocateLarge): Don't freak out any time the heap does
1116         an allocation. Only consider the heap to be growing if it actually needs
1117         to allocate new VM. This allows us to shrink the heap back down from a
1118         high water mark more reliably even if heap activity continues.
1119
1120         (bmalloc::sleep): Deleted.
1121         (bmalloc::Heap::scavengeLargeRanges): Renamed to match our use of
1122         "LargeObject".
1123
1124         * bmalloc/Heap.h:
1125
1126         * bmalloc/LargeObject.h:
1127         (bmalloc::LargeObject::operator bool): Added to simplify a while loop.
1128
1129         * bmalloc/StaticMutex.h:
1130         (bmalloc::sleep):
1131         (bmalloc::waitUntilFalse): New helper for waiting until a condition
1132         becomes reliably false.
1133
1134         * bmalloc/Vector.h:
1135         (bmalloc::Vector<T>::~Vector): Oops! Don't deallocate the null pointer.
1136         We don't actually run any Vector destructors, but an iteration of this
1137         patch did, and then crashed. So, let's fix that.
1138
1139 2015-03-02  Geoffrey Garen  <ggaren@apple.com>
1140
1141         bmalloc: Eagerly remove allocated objects from the free list
1142         https://bugs.webkit.org/show_bug.cgi?id=142194
1143
1144         Reviewed by Andreas Kling.
1145
1146         This reduces the pressure to garbage collect the free list.
1147
1148         Might be a 1% speedup on MallocBench.
1149
1150         * bmalloc/FreeList.cpp: Put this comment at the top of the file instead
1151         of repeating it inside of each function. Tried to clarify the details.
1152
1153         (bmalloc::FreeList::takeGreedy): Matched the other iteration code in this
1154         file for consistency -- even though either direction works fine in this
1155         function.
1156
1157         (bmalloc::FreeList::take): Change to iterate from low to high so that we
1158         can maintain an index into the vector that is not disturbed even if we
1159         pop from the middle (which invalidates the last index in the vector).
1160
1161         Decrement i when popping from the middle to make sure that we don't
1162         skip the next item after popping.
1163
1164         (bmalloc::FreeList::removeInvalidAndDuplicateEntries): Ditto.
1165
1166 2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>
1167
1168         Fixed a typo in the previous commit.
1169
1170         * bmalloc/BoundaryTag.h:
1171         (bmalloc::BoundaryTag::setOwner):
1172
1173 2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>
1174
1175         EFL build fix after r180797.
1176
1177         * bmalloc/BoundaryTag.h:
1178         (bmalloc::BoundaryTag::owner):
1179         (bmalloc::BoundaryTag::setOwner):
1180
1181 2015-02-27  Geoffrey Garen  <ggaren@apple.com>
1182
1183         bmalloc: Pathological madvise churn on the free(malloc(x)) benchmark
1184         https://bugs.webkit.org/show_bug.cgi?id=142058
1185
1186         Reviewed by Andreas Kling.
1187
1188         The churn was caused by repeatedly splitting an object with physical
1189         pages from an object without, and then merging them back together again.
1190         The merge would conservatively forget that we had physical pages, forcing
1191         a new call to madvise on the next allocation.
1192
1193         This patch more strictly segregates objects in the heap from objects in
1194         the VM heap, with these changes:
1195
1196         (1) Objects in the heap are not allowed to merge with objects in the VM
1197         heap, and vice versa -- since that would erase our precise knowledge of
1198         which physical pages had been allocated.
1199
1200         (2) The VM heap is exclusively responsible for allocating and deallocating
1201         physical pages.
1202
1203         (3) The heap free list must consider entries for objects that are in the
1204         VM heap to be invalid, and vice versa. (This condition can arise
1205         because the free list does not eagerly remove items.)
1206
1207         With these changes, we can know that any valid object in the heap's free
1208         list already has physical pages, and does not need to call madvise.
1209
1210         Note that the VM heap -- as before -- might sometimes contain ranges
1211         or pieces of ranges that have physical pages, since we allow splitting
1212         of ranges at granularities smaller than the VM page size. These ranges
1213         can eventually merge with ranges in the heap during scavenging.
1214
1215         * bmalloc.xcodeproj/project.pbxproj:
1216
1217         * bmalloc/BoundaryTag.h:
1218         (bmalloc::BoundaryTag::owner):
1219         (bmalloc::BoundaryTag::setOwner):
1220         (bmalloc::BoundaryTag::initSentinel):
1221         (bmalloc::BoundaryTag::hasPhysicalPages): Deleted.
1222         (bmalloc::BoundaryTag::setHasPhysicalPages): Deleted. Replaced the concept
1223         of "has physical pages" with a bit indicating which heap owns the large
1224         object. This is a more precise concept, since the old bit was really a
1225         Yes / Maybe bit.
1226
1227         * bmalloc/Deallocator.cpp:
1228
1229         * bmalloc/FreeList.cpp: Adopt
1230         (bmalloc::FreeList::takeGreedy):
1231         (bmalloc::FreeList::take):
1232         (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
1233         * bmalloc/FreeList.h:
1234         (bmalloc::FreeList::push): Added API for considering the owner when
1235         deciding if a free list entry is valid.
1236
1237         * bmalloc/Heap.cpp:
1238         (bmalloc::Heap::Heap): Adopt new API.
1239
1240         (bmalloc::Heap::scavengeLargeRanges): Scavenge all ranges with no minimum,
1241         since some ranges might be able to merge with ranges in the VM heap, and
1242         they won't be allowed to until we scavenge them.
1243
1244         (bmalloc::Heap::allocateSmallPage):
1245         (bmalloc::Heap::allocateMediumPage):
1246         (bmalloc::Heap::allocateLarge): New VM heap API makes this function
1247         simpler, since we always get back physical pages now.
1248
1249         * bmalloc/Heap.h:
1250         * bmalloc/LargeObject.h:
1251         (bmalloc::LargeObject::end):
1252         (bmalloc::LargeObject::owner):
1253         (bmalloc::LargeObject::setOwner):
1254         (bmalloc::LargeObject::isValidAndFree):
1255         (bmalloc::LargeObject::merge): Do not merge objects across heaps since
1256         that causes madvise churn.
1257         (bmalloc::LargeObject::validateSelf):
1258         (bmalloc::LargeObject::init):
1259         (bmalloc::LargeObject::hasPhysicalPages): Deleted.
1260         (bmalloc::LargeObject::setHasPhysicalPages): Deleted. Propogate the Owner API.
1261
1262         * bmalloc/Owner.h: Added.
1263
1264         * bmalloc/SegregatedFreeList.cpp:
1265         (bmalloc::SegregatedFreeList::SegregatedFreeList):
1266         (bmalloc::SegregatedFreeList::insert):
1267         (bmalloc::SegregatedFreeList::takeGreedy):
1268         (bmalloc::SegregatedFreeList::take):
1269         * bmalloc/SegregatedFreeList.h: Propogate the owner API.
1270
1271         * bmalloc/VMAllocate.h:
1272         (bmalloc::vmDeallocatePhysicalPagesSloppy):
1273         (bmalloc::vmAllocatePhysicalPagesSloppy): Clarified these functions and
1274         removed an edge case.
1275
1276         * bmalloc/VMHeap.cpp:
1277         (bmalloc::VMHeap::VMHeap):
1278         * bmalloc/VMHeap.h:
1279         (bmalloc::VMHeap::allocateSmallPage):
1280         (bmalloc::VMHeap::allocateMediumPage):
1281         (bmalloc::VMHeap::allocateLargeObject):
1282         (bmalloc::VMHeap::deallocateLargeObject): Be sure to give each object
1283         a new chance to merge, since it might have been prohibited from merging
1284         before by virtue of not being in the VM heap.
1285
1286         (bmalloc::VMHeap::allocateLargeRange): Deleted.
1287         (bmalloc::VMHeap::deallocateLargeRange): Deleted.
1288
1289 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
1290
1291         bmalloc: Large object free list can grow infinitely
1292         https://bugs.webkit.org/show_bug.cgi?id=142055
1293
1294         Reviewed by Andreas Kling.
1295
1296         By design, we don't eagerly remove large objects from the free list.
1297         This creates two simple pathologies:
1298
1299             (1) If you free and then allocate the same object repeatedly, it will
1300             duplicate itself in the free list repeatedly. Since it is never
1301             invalid at the time of allocation, it will never be removed.
1302
1303             (2) If you split and then merge the same object repeatedly, it will
1304             duplicate its split sibling in the free list repeatedly. If its
1305             sibling is in a separate free list size class, it will never be
1306             consulted at the time of allocation, so it will never be removed.
1307
1308         So, a simple "while (1) { free(malloc(x)); }" causes infinite memory
1309         use in the free list.
1310
1311         The solution in this patch is a simple helper to remove garbage from the
1312         free list if it grows too large. This pathology is not common, so the
1313         cost is OK.
1314
1315         Long-term, perhaps we should rethink the laziness of these free lists.
1316
1317         * bmalloc/BoundaryTag.h:
1318         (bmalloc::BoundaryTag::isMarked):
1319         (bmalloc::BoundaryTag::setMarked): New bit, used by free list GC.
1320
1321         * bmalloc/FreeList.cpp:
1322         (bmalloc::FreeList::removeInvalidAndDuplicateEntries): The GC algorithm.
1323
1324         * bmalloc/FreeList.h:
1325         (bmalloc::FreeList::FreeList):
1326         (bmalloc::FreeList::push): Invoke the GC if we're getting huge.
1327
1328         * bmalloc/LargeObject.h:
1329         (bmalloc::LargeObject::isMarked):
1330         (bmalloc::LargeObject::setMarked):
1331         (bmalloc::LargeObject::validateSelf): Expose the new bit.
1332
1333         * bmalloc/Sizes.h: New constant to control GC frequency.
1334
1335 2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>
1336
1337         URTBF after r180693.
1338
1339         * CMakeLists.txt:
1340
1341 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
1342
1343         Try to fix the Mac build.
1344
1345         Unreviewed.
1346
1347         * bmalloc.xcodeproj/project.pbxproj: Make FreeList.h available.
1348
1349 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
1350
1351         bmalloc: Refactored SegregatedFreeList and BoundaryTag::init
1352         https://bugs.webkit.org/show_bug.cgi?id=142049
1353
1354         Reviewed by Anders Carlsson.
1355
1356         Split out a FreeList class from SegregatedFreeList. This will make it
1357         easier to add behaviors on free list insertion and removal -- and it's
1358         probably how I should have designed things at the start.
1359
1360         Moved BoundaryTag::init into LargeObject, since all the related logic
1361         lives in LargeObject now too, and this allows us to remove BoundaryTagInlines.h.
1362
1363         * bmalloc.xcodeproj/project.pbxproj:
1364         * bmalloc/BoundaryTagInlines.h: Removed.
1365         * bmalloc/FreeList.cpp: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.cpp.
1366         (bmalloc::FreeList::takeGreedy):
1367         (bmalloc::FreeList::take):
1368         (bmalloc::SegregatedFreeList::SegregatedFreeList): Deleted.
1369         (bmalloc::SegregatedFreeList::insert): Deleted.
1370         (bmalloc::SegregatedFreeList::takeGreedy): Deleted.
1371         (bmalloc::SegregatedFreeList::take): Deleted.
1372         * bmalloc/FreeList.h: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.h.
1373         (bmalloc::FreeList::push):
1374         * bmalloc/LargeObject.h:
1375         (bmalloc::LargeObject::init):
1376         * bmalloc/SegregatedFreeList.cpp:
1377         (bmalloc::SegregatedFreeList::SegregatedFreeList):
1378         (bmalloc::SegregatedFreeList::insert):
1379         (bmalloc::SegregatedFreeList::takeGreedy):
1380         (bmalloc::SegregatedFreeList::take):
1381         * bmalloc/SegregatedFreeList.h:
1382         * bmalloc/Sizes.h:
1383         * bmalloc/VMHeap.cpp:
1384         (bmalloc::VMHeap::grow):
1385
1386 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
1387
1388         bmalloc: free up a bit in BoundaryTag
1389         https://bugs.webkit.org/show_bug.cgi?id=142048
1390
1391         Reviewed by Brady Eidson.
1392
1393         We were wasting a bit by accident, and I need one now.
1394
1395         * bmalloc/Algorithm.h:
1396         (bmalloc::rightShift): Deleted. Not needed, now that I've simplified
1397         the math.
1398
1399         * bmalloc/BoundaryTag.h: Since each boundary tag bucket is 1024 bytes
1400         long, the maximum offset into a bucket is 1023.
1401
1402         You need 5 bits to count up to 1024, but only 4 to count up to 1023.
1403         
1404         Math is hard.
1405
1406         (bmalloc::BoundaryTag::compactBegin): Switched to division because it
1407         is simpler, and easier to match up with our ASSERT. The compiler will
1408         turn division by constant power of two into a shift for us.
1409
1410         (bmalloc::BoundaryTag::setRange): Added an ASSERT for compactBegin
1411         because we do encode it, so we should ASSERT that encoding did not
1412         lose information.
1413
1414         * bmalloc/Sizes.h: Shifting is no longer used since we use division
1415         instead.
1416
1417 2015-02-24  Stephanie Lewis  <slewis@apple.com>
1418
1419         Rolling out http://trac.webkit.org/changeset/180430 as it causes the PLT to crash.
1420         <rdar://problem/19948015>
1421
1422         Unreviewed.
1423
1424         * bmalloc/VMHeap.cpp:
1425         (bmalloc::VMHeap::grow):
1426         * bmalloc/VMHeap.h:
1427         * bmalloc/Zone.cpp:
1428         (bmalloc::Zone::Zone):
1429         (bmalloc::Zone::size): Deleted.
1430         * bmalloc/Zone.h:
1431
1432 2015-02-24  Geoffrey Garen  <ggaren@apple.com>
1433
1434         bmalloc: Added a little more abstraction for large objects
1435         https://bugs.webkit.org/show_bug.cgi?id=141978
1436
1437         Reviewed by Sam Weinig.
1438
1439         Previously, each client needed to manage the boundary tags of
1440         a large object using free functions. This patch introduces a LargeObject
1441         class that does things a little more automatically.
1442
1443         * bmalloc.xcodeproj/project.pbxproj:
1444
1445         * bmalloc/Allocator.cpp:
1446         (bmalloc::Allocator::reallocate): Use the new LargeObject class.
1447
1448         * bmalloc/BeginTag.h:
1449         (bmalloc::BeginTag::isInFreeList): Deleted. Moved this logic into the
1450         LargeObject class.
1451
1452         * bmalloc/BoundaryTag.h:
1453         (bmalloc::BoundaryTag::isSentinel):
1454         (bmalloc::BoundaryTag::compactBegin):
1455         (bmalloc::BoundaryTag::setRange):
1456         (bmalloc::BoundaryTag::initSentinel): Added an explicit API for sentinels,
1457         which we used to create and test for implicitly.
1458
1459         * bmalloc/BoundaryTagInlines.h:
1460         (bmalloc::BoundaryTag::init):
1461         (bmalloc::validate): Deleted.
1462         (bmalloc::validatePrev): Deleted.
1463         (bmalloc::validateNext): Deleted.
1464         (bmalloc::BoundaryTag::mergeLeft): Deleted.
1465         (bmalloc::BoundaryTag::mergeRight): Deleted.
1466         (bmalloc::BoundaryTag::merge): Deleted.
1467         (bmalloc::BoundaryTag::deallocate): Deleted.
1468         (bmalloc::BoundaryTag::split): Deleted.
1469         (bmalloc::BoundaryTag::allocate): Deleted. Moved this logic into the
1470         LargeObject class.
1471
1472         * bmalloc/EndTag.h:
1473         (bmalloc::EndTag::init):
1474         (bmalloc::EndTag::operator=): Deleted. Re-reading this code, I found
1475         special behavior in the assignment operator to be a surprising API.
1476         So, I replaced the assignment operation with an explicit initializing
1477         function.
1478
1479         * bmalloc/Heap.cpp:
1480         (bmalloc::Heap::scavengeLargeRanges):
1481         (bmalloc::Heap::allocateXLarge):
1482         (bmalloc::Heap::findXLarge):
1483         (bmalloc::Heap::deallocateXLarge):
1484         (bmalloc::Heap::allocateLarge):
1485         (bmalloc::Heap::deallocateLarge):
1486         * bmalloc/Heap.h: No behavior changes here -- just adopting the
1487         LargeObject interface.
1488
1489         * bmalloc/LargeObject.h: Added.
1490         (bmalloc::LargeObject::operator!):
1491         (bmalloc::LargeObject::begin):
1492         (bmalloc::LargeObject::size):
1493         (bmalloc::LargeObject::range):
1494         (bmalloc::LargeObject::LargeObject):
1495         (bmalloc::LargeObject::setFree):
1496         (bmalloc::LargeObject::isFree):
1497         (bmalloc::LargeObject::hasPhysicalPages):
1498         (bmalloc::LargeObject::setHasPhysicalPages):
1499         (bmalloc::LargeObject::isValidAndFree):
1500         (bmalloc::LargeObject::merge):
1501         (bmalloc::LargeObject::split):
1502         (bmalloc::LargeObject::validateSelf):
1503         (bmalloc::LargeObject::validate): Moved this code into a class, out of
1504         BoundaryTag free functions.
1505
1506         New to the class are these features:
1507
1508             (1) Every reference to an object is validated upon creation and use.
1509
1510             (2) There's an explicit API for "This is a reference to an object
1511             that might be stale (the DoNotValidate API)".
1512
1513             (3) The begin and end tags are kept in sync automatically.
1514
1515         * bmalloc/SegregatedFreeList.cpp:
1516         (bmalloc::SegregatedFreeList::insert):
1517         (bmalloc::SegregatedFreeList::takeGreedy):
1518         (bmalloc::SegregatedFreeList::take):
1519         * bmalloc/SegregatedFreeList.h: Adopt the LargeObject interface.
1520
1521         * bmalloc/VMHeap.cpp:
1522         (bmalloc::VMHeap::grow):
1523         * bmalloc/VMHeap.h:
1524         (bmalloc::VMHeap::allocateLargeRange):
1525         (bmalloc::VMHeap::deallocateLargeRange): Adopt the LargeObject interface.
1526
1527 2015-02-20  Geoffrey Garen  <ggaren@apple.com>
1528
1529         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
1530         https://bugs.webkit.org/show_bug.cgi?id=141802
1531
1532         Reviewed by Andreas Kling.
1533
1534         Rolling back in with a fix for a crash seen while using GuardMalloc.
1535
1536         * bmalloc/VMHeap.cpp:
1537         (bmalloc::VMHeap::grow):
1538         * bmalloc/VMHeap.h:
1539         * bmalloc/Zone.cpp: Re-land the old patch.
1540
1541         (bmalloc::Zone::size): Be sure to implement the size() function since
1542         it's accessible indirectly via the malloc_zone_from_ptr public API --
1543         and GuardMalloc calls it all the time.
1544
1545         (bmalloc::Zone::Zone):
1546         * bmalloc/Zone.h: Re-land the old patch.
1547
1548 2015-02-19  Commit Queue  <commit-queue@webkit.org>
1549
1550         Unreviewed, rolling out r180363.
1551         https://bugs.webkit.org/show_bug.cgi?id=141814
1552
1553         Caused >50 crashes when running LayoutTests in GuardMalloc or
1554         ASAN modes. (Requested by jernoble on #webkit).
1555
1556         Reverted changeset:
1557
1558         "bmalloc should implement malloc introspection (to stop false-
1559         positive leaks when MallocStackLogging is off)"
1560         https://bugs.webkit.org/show_bug.cgi?id=141802
1561         http://trac.webkit.org/changeset/180363
1562
1563 2015-02-19  Geoffrey Garen  <ggaren@apple.com>
1564
1565         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
1566         https://bugs.webkit.org/show_bug.cgi?id=141802
1567
1568         Reviewed by Andreas Kling.
1569
1570         Fixed a last-minute type.
1571
1572         The macro is OS, not PLATFORM.
1573
1574         * bmalloc/VMHeap.cpp:
1575         (bmalloc::VMHeap::grow):
1576         * bmalloc/VMHeap.h:
1577         * bmalloc/Zone.h:
1578
1579 2015-02-19  Geoffrey Garen  <ggaren@apple.com>
1580
1581         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
1582         https://bugs.webkit.org/show_bug.cgi?id=141802
1583
1584         Reviewed by Andreas Kling.
1585
1586         This patch does the bare minimum to stop false positive leaks from
1587         being reported by the Darwin leaks tool. We register each super chunk
1588         as a single object, and then request that the leaks tool scan it.
1589
1590         * bmalloc.xcodeproj/project.pbxproj: Added an abstraction for the malloc
1591         zone introspection API.
1592
1593         * bmalloc/Algorithm.h: Missing #include.
1594
1595         * bmalloc/VMHeap.cpp:
1596         (bmalloc::VMHeap::grow):
1597         * bmalloc/VMHeap.h: Adopt the new abstraction.
1598
1599         * bmalloc/Zone.cpp: Added.
1600         (bmalloc::remoteRead): Helper for reading an object out of another process.
1601         (bmalloc::Zone::enumerator):
1602         (bmalloc::Zone::Zone): Register a malloc zone so that we will participate
1603         in introspection.
1604
1605         * bmalloc/Zone.h: Added.
1606         (bmalloc::Zone::superChunks):
1607         (bmalloc::Zone::addSuperChunk): Use a non-dynamically-allocated vector
1608         since our dynamic allocations will not be scanned by leaks since they
1609         will have the malloc VM tag.
1610
1611 2015-02-18  Geoffrey Garen  <ggaren@apple.com>
1612
1613         bmalloc: VMHeap should keep a record of all of its VM ranges (for malloc introspection)
1614         https://bugs.webkit.org/show_bug.cgi?id=141759
1615
1616         Reviewed by Andreas Kling.
1617
1618         * bmalloc.xcodeproj/project.pbxproj:
1619         * bmalloc/SuperChunk.h: Added.
1620         (bmalloc::SuperChunk::create):
1621         (bmalloc::SuperChunk::SuperChunk):
1622         (bmalloc::SuperChunk::smallChunk):
1623         (bmalloc::SuperChunk::mediumChunk):
1624         (bmalloc::SuperChunk::largeChunk): Factored out super chunk creation
1625         into a separate class, for clarity and type safety.
1626
1627         * bmalloc/VMHeap.cpp:
1628         (bmalloc::VMHeap::grow):
1629         (bmalloc::VMHeap::allocateSuperChunk): Renamed "allocateSuperChunk" to
1630         "grow" because Andreas found "allocateSuperChunk" to be unclear.
1631
1632         * bmalloc/VMHeap.h: Track all our VM ranges. We will use this information
1633         for malloc introspection.
1634
1635         (bmalloc::VMHeap::allocateSmallPage):
1636         (bmalloc::VMHeap::allocateMediumPage):
1637         (bmalloc::VMHeap::allocateLargeRange): Updated for renames.
1638
1639 2015-02-18  Zan Dobersek  <zdobersek@igalia.com>
1640
1641         Build bmalloc through CMake as a static library. It's then linked either
1642         into the WTF library (if built as a shared library) or into the JSC and
1643         WebKit2 libraries. There's no need to build it as a standalone shared library.
1644
1645         Rubber-stamped by Carlos Garcia Campos.
1646
1647         * CMakeLists.txt:
1648
1649 2015-02-13  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
1650
1651         [BMalloc] Add a FIXME comment for memory alignas
1652         https://bugs.webkit.org/show_bug.cgi?id=141556
1653
1654         Reviewed by Csaba Osztrogonác.
1655
1656         * bmalloc/Chunk.h: Add a FIXME comment.
1657         * bmalloc/LargeChunk.h: ditto.
1658
1659 2015-02-11  Csaba Osztrogonác  <ossy@webkit.org>
1660
1661         bmalloc buildfix on 32 bit Linux (x86/ARM)
1662         https://bugs.webkit.org/show_bug.cgi?id=141472
1663
1664         Reviewed by Gyuyoung Kim.
1665
1666         * bmalloc/Algorithm.h:
1667         (bmalloc::roundUpToMultipleOf):
1668         * bmalloc/FixedVector.h:
1669         (bmalloc::FixedVector::clear):
1670         * bmalloc/Sizes.h:
1671         (bmalloc::Sizes::sizeClass):
1672
1673 2015-02-11  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
1674
1675         [EFL][GTK] Use bmalloc instead of tcmalloc
1676         https://bugs.webkit.org/show_bug.cgi?id=140162
1677
1678         Reviewed by Carlos Garcia Campos.
1679
1680         Support to use bmalloc on EFL and GTK ports.
1681
1682         * CMakeLists.txt: Added.
1683         * bmalloc/Allocator.cpp:
1684         (bmalloc::Allocator::allocate):
1685             Fix unused return value caused by posix_memalign().
1686         * bmalloc/AsyncTask.h:
1687         * bmalloc/BoundaryTag.h:
1688         (bmalloc::BoundaryTag::clear):
1689         * bmalloc/Chunk.h:
1690             Change Traits::Page with Traits::PageType in order to fix
1691             -fpermitive build error on EFL and GTK port. 
1692         * bmalloc/EndTag.h:
1693         (bmalloc::EndTag::operator=):
1694         * bmalloc/Line.h: ditto.
1695         * bmalloc/MediumTraits.h:
1696         * bmalloc/Page.h: ditto.
1697         * bmalloc/PerThread.h:
1698             EFL port doesn't support __has_include definition yet.
1699             Define HAVE_PTHREAD_MACHDEP_H according to check if __has_include is supported.
1700         * bmalloc/SmallTraits.h: ditto.
1701         * bmalloc/VMAllocate.h:
1702         (bmalloc::vmDeallocatePhysicalPages):
1703         (bmalloc::vmAllocatePhysicalPages):
1704         * bmalloc/Vector.h:
1705         (bmalloc::Vector<T>::push):
1706         (bmalloc::Vector<T>::reallocateBuffer):
1707
1708 2015-01-31  Sam Weinig  <sam@webkit.org>
1709
1710         Remove even more Mountain Lion support
1711         https://bugs.webkit.org/show_bug.cgi?id=141124
1712
1713         Reviewed by Alexey Proskuryakov.
1714
1715         * Configurations/Base.xcconfig:
1716         * Configurations/DebugRelease.xcconfig:
1717
1718 2015-01-30  Geoffrey Garen  <ggaren@apple.com>
1719
1720         GC marking threads should clear malloc caches
1721         https://bugs.webkit.org/show_bug.cgi?id=141097
1722
1723         Reviewed by Andreas Kling.
1724
1725         Split the scavenging API into per-thread vs global, so that you can
1726         request to scavenge your own thread without scavenging the whole heap.
1727
1728         * bmalloc/Cache.cpp:
1729         (bmalloc::Cache::scavenge):
1730         * bmalloc/bmalloc.h:
1731         (bmalloc::api::scavengeThisThread):
1732         (bmalloc::api::scavenge):
1733
1734 2015-01-28  Dana Burkart  <dburkart@apple.com>
1735
1736         Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
1737         https://bugs.webkit.org/show_bug.cgi?id=136765
1738
1739         Reviewed by Alexey Proskuryakov.
1740
1741         * Configurations/Base.xcconfig:
1742         * Configurations/DebugRelease.xcconfig:
1743
1744 2015-01-21  Geoffrey Garen  <ggaren@apple.com>
1745
1746         bmalloc: support aligned allocation
1747         https://bugs.webkit.org/show_bug.cgi?id=140732
1748
1749         Reviewed by Andreas Kling.
1750
1751         * bmalloc/Allocator.cpp:
1752         (bmalloc::Allocator::allocate): New function for aligned allocation.
1753
1754         Small and medium requests just allocate and free until they find an
1755         aligned pointer. This is slightly inefficient in the worst case, but
1756         still constant-time with little-to-no space overhead.
1757
1758         Large requests use a new API that requires the client to specify both
1759         its ideal size and alignment, and the worst-case size you would have to
1760         allocate in order to produce some interior pointer of the requested size
1761         and alignment. We put the burden of this calculation on the client
1762         because it simplifies things if we guarantee that allocation won't fail.
1763
1764         XLarge requests are easy: we just forward them to vmAllocate, which
1765         already supported aligned requests.
1766
1767         * bmalloc/BoundaryTag.h:
1768         * bmalloc/BoundaryTagInlines.h:
1769         (bmalloc::BoundaryTag::mergeLeft):
1770         (bmalloc::BoundaryTag::mergeRight):
1771         (bmalloc::BoundaryTag::merge):
1772         (bmalloc::BoundaryTag::deallocate):
1773         (bmalloc::BoundaryTag::split):
1774         (bmalloc::BoundaryTag::allocate): No behavior change here. I just
1775         refactored the interface to remove some reference out parameters in
1776         order to clarify what changes and what doesn't.
1777
1778         * bmalloc/Heap.cpp:
1779         (bmalloc::Heap::allocateXLarge): Added an alignment API.
1780
1781         (bmalloc::Heap::allocateLarge):
1782         * bmalloc/Heap.h: Added an alignment API. I split out allocateLarge into
1783         a few variants, so aligned and unaligned allocation could share some code.
1784
1785         * bmalloc/SegregatedFreeList.cpp:
1786         (bmalloc::SegregatedFreeList::take):
1787         * bmalloc/SegregatedFreeList.h: Changed to use a separate, explicit API
1788         for aligned allocation. It turns out that the aligned path is pretty
1789         different, since it ends up searching for two potential ways to satisfy
1790         an allocation: either large enough and aligned, or large enough to split
1791         into something not aligned and something large enough and aligned.
1792
1793         * bmalloc/VMAllocate.h:
1794         (bmalloc::vmAllocate): Switched alignment to come before size because
1795         that's how the memalign API specifies it.
1796
1797         * bmalloc/VMHeap.h:
1798         (bmalloc::VMHeap::allocateLargeRange): Added an alignment API.
1799
1800 2015-01-20  Geoffrey Garen  <ggaren@apple.com>
1801
1802         bmalloc: a little bit of cleanup
1803         https://bugs.webkit.org/show_bug.cgi?id=140687
1804
1805         Reviewed by Anders Carlsson.
1806
1807         * bmalloc/Algorithm.h:
1808         (bmalloc::isPowerOfTwo): Added a check for 0, since 0 would break a lot
1809         of code.
1810
1811         * bmalloc/BoundaryTag.h:
1812         * bmalloc/BoundaryTagInlines.h:
1813         (bmalloc::BoundaryTag::mergeLeft):
1814         (bmalloc::BoundaryTag::mergeRight):
1815         (bmalloc::BoundaryTag::merge):
1816         (bmalloc::BoundaryTag::deallocate):
1817         (bmalloc::BoundaryTag::split):
1818         (bmalloc::BoundaryTag::allocate):
1819         (bmalloc::BoundaryTag::mergeLargeLeft): Deleted.
1820         (bmalloc::BoundaryTag::mergeLargeRight): Deleted.
1821         (bmalloc::BoundaryTag::mergeLarge): Deleted.
1822         (bmalloc::BoundaryTag::splitLarge): Deleted. Removed the word "Large"
1823         from all these functions, since boundary tags always pertain to large
1824         objects, and putting the word "Large" everywhere wasn't helping to
1825         explain that.
1826
1827         * bmalloc/Heap.cpp:
1828         (bmalloc::Heap::allocateXLarge):
1829         (bmalloc::Heap::findXLarge):
1830         (bmalloc::Heap::deallocateXLarge):
1831         * bmalloc/Heap.h:
1832         * bmalloc/VMHeap.h:
1833         (bmalloc::VMHeap::allocateXLarge): Deleted.
1834         (bmalloc::VMHeap::findXLarge): Deleted.
1835         (bmalloc::VMHeap::deallocateXLarge): Deleted. Moved XLarge allocation
1836         from VMHeap to Heap. Since the purpose of the VMHeap is to cache VM
1837         ranges, and the VMHeap never caches any XLarge ranges, it doesn't
1838         really make sense for the VMHeap to be involved.
1839
1840 2015-01-16  Geoffrey Garen  <ggaren@apple.com>
1841
1842         bmalloc: refactored XLarge allocation for better alignment
1843         https://bugs.webkit.org/show_bug.cgi?id=140582
1844
1845         Reviewed by Andreas Kling.
1846
1847         XLarge objects used to be Large objects with an extra bit of metadata
1848         that said "actually, I'm not large -- I'm extra large".
1849
1850         The metadata header in an XLarge allocation made it impossible for the
1851         XLarge object to honor a very large alignment request.
1852
1853         The solution is to stop using a metadata header for XLarge objects, and
1854         instead to store explicit metadata on the side.
1855
1856         This is a bit less astonishing, which is also nice.
1857
1858         Finding XLarge metadata is now a linear search. That's probably OK, since
1859         it was always so in TCMalloc, and the usual number of XLarge allocations
1860         in a process is 0.
1861
1862         This design makes it possible for the heap to cache XLarge allocations
1863         with and/or without physical pages. I haven't actually done that yet
1864         because the tradeoffs are subtle, so I don't want to do anything without
1865         a motivating test case.
1866
1867         * bmalloc.xcodeproj/project.pbxproj:
1868         * bmalloc/Allocator.cpp:
1869         (bmalloc::Allocator::reallocate): Removed the concept of an XLargeChunk,
1870         since an XLarge allocation is now just a naked buffer without a header.
1871
1872         (bmalloc::Allocator::allocateXLarge): Added an explicit qualifier for
1873         XLarge alignment, since XLargeChunk won't give this to us implicitly
1874         anymore.
1875
1876         * bmalloc/BoundaryTag.h:
1877         (bmalloc::BoundaryTag::setRange):
1878         (bmalloc::BoundaryTag::isXLarge): Deleted.
1879         (bmalloc::BoundaryTag::setXLarge): Deleted.
1880         * bmalloc/BoundaryTagInlines.h:
1881         (bmalloc::validate):
1882         (bmalloc::BoundaryTag::deallocate): Removed the XLarge hacks from Large allocations.
1883
1884         * bmalloc/Deallocator.cpp:
1885         (bmalloc::Deallocator::deallocateXLarge):
1886         (bmalloc::Deallocator::deallocateSlowCase):
1887         * bmalloc/Heap.cpp:
1888         (bmalloc::Heap::findXLarge):
1889         (bmalloc::Heap::allocateXLarge):
1890         (bmalloc::Heap::deallocateXLarge):
1891         * bmalloc/Heap.h: Updated for interface changes.
1892
1893         * bmalloc/ObjectType.cpp:
1894         (bmalloc::objectType):
1895         * bmalloc/ObjectType.h:
1896         (bmalloc::isXLarge): We can now tell if a pointer is XLarge just by
1897         examining its bit pattern -- just like we do for other kinds of
1898         allocations -- which is nice.
1899
1900         * bmalloc/Sizes.h:
1901         * bmalloc/VMHeap.h:
1902         (bmalloc::VMHeap::allocateXLarge):
1903         (bmalloc::VMHeap::findXLarge):
1904         (bmalloc::VMHeap::deallocateXLarge): Keep an explicit vector of metadata
1905         for XLarge allocations.
1906
1907         * bmalloc/XLargeChunk.h: Removed.
1908
1909 2015-01-16  Geoffrey Garen  <ggaren@apple.com>
1910
1911         bmalloc: added some infrastructure for aligned allocation
1912         https://bugs.webkit.org/show_bug.cgi?id=140572
1913
1914         Reviewed by Andreas Kling.
1915
1916         * bmalloc/Algorithm.h:
1917         (bmalloc::isPowerOfTwo):
1918         (bmalloc::roundUpToMultipleOf):
1919         (bmalloc::roundDownToMultipleOf): Refactored some duplicate code to use our
1920         isPowerOfTwo helper function.
1921
1922         * bmalloc/Allocator.cpp:
1923         (bmalloc::Allocator::allocate):
1924         * bmalloc/Allocator.h: Stubbed out an implementation of aligned allocation.
1925         Doesn't do anything yet, but does correctly forward to system malloc
1926         when bmalloc is disabled.
1927
1928         * bmalloc/Cache.cpp:
1929         (bmalloc::Cache::allocateSlowCaseNullCache):
1930         * bmalloc/Cache.h:
1931         (bmalloc::Cache::allocate):
1932         * bmalloc/bmalloc.h:
1933         (bmalloc::api::memalign):
1934         * bmalloc/mbmalloc.cpp: Stubbed out an API for aligned allocation.
1935
1936 2015-01-13  Geoffrey Garen  <ggaren@apple.com>
1937
1938         Consider alignment when allocating from a SegregatedFreeList
1939         https://bugs.webkit.org/show_bug.cgi?id=140408
1940
1941         Reviewed by Sam Weinig.
1942
1943         In preparation for supporting aligned allocation.
1944
1945         No performance change.
1946
1947         Since this is just one extra branch in an already expensive function,
1948         I decided not to duplicate the function just to avoid the branch in
1949         the un-aligned case.
1950
1951         * bmalloc/SegregatedFreeList.cpp:
1952         (bmalloc::SegregatedFreeList::take):
1953         * bmalloc/SegregatedFreeList.h:
1954
1955 2015-01-13  Geoffrey Garen  <ggaren@apple.com>
1956
1957         Renamed minimum to size in SegregatedFreeList
1958         https://bugs.webkit.org/show_bug.cgi?id=140406
1959
1960         Reviewed by Sam Weinig.
1961
1962         In preparation for supporting aligned allocation.
1963
1964         * bmalloc/SegregatedFreeList.cpp:
1965         (bmalloc::SegregatedFreeList::takeGreedy):
1966         (bmalloc::SegregatedFreeList::take): Every size passed to malloc is
1967         really just a minimum. Let's not imply that this value is special.
1968
1969 2015-01-11  Dan Bernstein  <mitz@apple.com>
1970
1971         Geoff is organized, but he is not an organization.
1972
1973         Rubber-stamped by Anders Carlsson.
1974
1975         * bmalloc.xcodeproj/project.pbxproj: Removed the ORGANIZATIONNAME project attribute.
1976
1977 2015-01-07  Geoffrey Garen  <ggaren@apple.com>
1978
1979         Make bmalloc work with ASan
1980         https://bugs.webkit.org/show_bug.cgi?id=140194
1981
1982         Reviewed by Mark Lam.
1983
1984         * bmalloc/BPlatform.h: Added a way to detect Darwin OSes, since we need
1985         an OS-specific API to test for loaded runtime libraries.
1986
1987         * bmalloc/Environment.cpp:
1988         (bmalloc::isASanEnabled):
1989         (bmalloc::Environment::computeIsBmallocEnabled): Disabled bmalloc if
1990         ASan is enabled, since system malloc has the Asan hooks we need.
1991
1992         You could check for the ASan compile-time flag instead, but doing this
1993         check at runtime prepares bmalloc for a world where it is a dynamic
1994         library that might be loaded into projects it did not compile with.
1995
1996 2015-01-05  Geoffrey Garen  <ggaren@apple.com>
1997
1998         Fix up bmalloc's PerThread for use on Linux
1999         https://bugs.webkit.org/show_bug.cgi?id=139804
2000
2001         Reviewed by Anders Carlsson.
2002
2003         The previous implementation was a bit slow.
2004
2005         * bmalloc/PerThread.h:
2006         (bmalloc::PerThreadStorage<Cache>::get):
2007         (bmalloc::PerThreadStorage::get):
2008         (bmalloc::PerThreadStorage::init): Added a catch-all cross-platform Unix
2009         way to do fast per-thread access without taking a lock every time. This
2010         probably works on all the platforms we care about, and it matches other
2011         techniques we use elsewhere in WebKit.
2012
2013         (bmalloc::PerThread<T>::getFastCase): Removed the conditional from
2014         this class because PerThreadStorage now encapsulates everything that
2015         needs to be conditional.
2016
2017         (bmalloc::PerThreadStorage::initSharedKeyIfNeeded): Deleted.
2018
2019 2014-12-26  Dan Bernstein  <mitz@apple.com>
2020
2021         <rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
2022         https://bugs.webkit.org/show_bug.cgi?id=139950
2023
2024         Reviewed by David Kilzer.
2025
2026         * Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
2027         in a manner that works with Xcode 5.1.1.
2028
2029 2014-12-15  Geoffrey Garen  <ggaren@apple.com>
2030
2031         Safari crashes when you set Malloc environment variables
2032         https://bugs.webkit.org/show_bug.cgi?id=139656
2033
2034         Reviewed by Michael Saboff.
2035
2036         I forgot to cover the realloc() case. Whoops. (OoPS?)
2037
2038         This time around, I ran the full MallocBench test suite in Malloc=1
2039         mode, and it passed.
2040
2041         * bmalloc/Allocator.cpp:
2042         (bmalloc::Allocator::reallocate):
2043         * bmalloc/Allocator.h: Pushed realloc() logic down into the allocator.
2044         It needs to be down there so that we can do the short-circuiting check
2045         for whether bmalloc is enabled first.
2046
2047         Also added the check.
2048
2049         * bmalloc/Cache.cpp:
2050         (bmalloc::Cache::scavenge):
2051         (bmalloc::Cache::Cache):
2052         (bmalloc::Cache::reallocateSlowCaseNullCache):
2053         * bmalloc/Cache.h:
2054         (bmalloc::Cache::deallocator):
2055         (bmalloc::Cache::reallocate): Ditto.
2056
2057         * bmalloc/bmalloc.h:
2058         (bmalloc::api::free):
2059         (bmalloc::api::realloc): Ditto.
2060
2061         (bmalloc::api::scavenge): Pushed this down into Cache to match the
2062         surrounding functions.
2063
2064 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
2065
2066         bmalloc should support system memory analysis tools (part 2)
2067         https://bugs.webkit.org/show_bug.cgi?id=139565
2068
2069         Reviewed by Mark Lam.
2070
2071         This patch actually queries the environment to see if memory analysis
2072         tools have been enabled.
2073
2074         * bmalloc/Deallocator.cpp:
2075         (bmalloc::Deallocator::scavenge): Don't process the object log if
2076         we've disabled bmalloc because it will be full of invalid nullptrs.
2077
2078         * bmalloc/Environment.cpp:
2079         (bmalloc::isMallocEnvironmentVariableSet): Test for the list of known
2080         Malloc debugging flags. I also added a plain "Malloc" catch-all for
2081         when you want to disable bmalloc without enabling any kind of funny
2082         business.
2083
2084         It would be slightly nicer just to iterate the list of environment
2085         variables and strstr them, but getenv is the more portable option,
2086         and performance here doesn't really matter.
2087
2088         (bmalloc::isLibgmallocEnabled): Test for the libgmalloc insertion
2089         environment variable.
2090
2091         (bmalloc::Environment::computeIsBmallocEnabled):
2092
2093 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
2094
2095         Try to fix the iOS simulator build.
2096
2097         #include the declaration of malloc / free.
2098
2099         * bmalloc/Allocator.cpp:
2100         * bmalloc/Deallocator.cpp:
2101
2102 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
2103
2104         Try to fix the build.
2105
2106         * bmalloc.xcodeproj/project.pbxproj: Marked a header exported.
2107
2108 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
2109
2110         bmalloc should support system memory analysis tools (part 1)
2111         https://bugs.webkit.org/show_bug.cgi?id=139559
2112
2113         Reviewed by Mark Lam.
2114
2115         This patch adds the hooks to disable bmalloc at runtime if certain
2116         environment variables are set, but doesn't actually read from the
2117         environment yet.
2118
2119         No performance change.
2120
2121         * bmalloc.xcodeproj/project.pbxproj: Added the Environment class, which
2122         we'll use to read environment variables and see if memory analysis tools
2123         have been enabled.
2124
2125         * bmalloc/Allocator.cpp:
2126         (bmalloc::Allocator::Allocator):
2127         (bmalloc::Allocator::allocateSlowCase): Added a hook to disable bmalloc
2128         on the allocation path. We cache the setting to make the check fast.
2129
2130         * bmalloc/Allocator.h: Interface changes.
2131
2132         * bmalloc/Cache.cpp:
2133         (bmalloc::Cache::Cache): Pass a heap pointer through to our allocator
2134         and deallocator. This main purpose is to enable them to query the
2135         environment for whether bmalloc is enabled; but this is also a slightly
2136         cleaner way to guarantee to them that the Heap has been pre-initialized.
2137
2138         * bmalloc/Deallocator.cpp:
2139         (bmalloc::Deallocator::Deallocator): If bmalloc is disable, artificially
2140         fill the object log to force us to take the slow path on all deallocations.
2141
2142         (bmalloc::Deallocator::deallocateSlowCase): Do the disabled check.
2143
2144         * bmalloc/Deallocator.h: Interface changes.
2145
2146         * bmalloc/Environment.cpp: Added.
2147         (bmalloc::Environment::Environment):
2148         (bmalloc::Environment::computeIsBmallocEnabled):
2149         * bmalloc/Environment.h: Added.
2150         (bmalloc::Environment::isBmallocEnabled): This is the class that will
2151         encapsulate looking for environment variables that turn on heap
2152         analysis tools.
2153
2154         * bmalloc/Heap.h:
2155         (bmalloc::Heap::environment):
2156
2157         * bmalloc/Mutex.h:
2158         (bmalloc::Mutex::Mutex):
2159         * bmalloc/StaticMutex.h: A little refactoring to clarify these comments,
2160         since I got super confused about them while writing this patch.
2161
2162         * bmalloc/VMHeap.cpp: Fixed an #include.
2163
2164 2014-12-09  David Kilzer  <ddkilzer@apple.com>
2165
2166         Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF
2167         <http://webkit.org/b/139212>
2168
2169         Reviewed by Joseph Pecoraro.
2170
2171         * Configurations/Base.xcconfig:
2172         - Only set GCC_ENABLE_OBJC_GC, GCC_MODEL_TUNING and TOOLCHAINS
2173           on OS X.
2174         * Configurations/DebugRelease.xcconfig:
2175         - Only set MACOSX_DEPLOYMENT_TARGET and SDKROOT on OS X.
2176
2177 2014-11-07  Geoffrey Garen  <ggaren@apple.com>
2178
2179         bmalloc uses 8X more virtual memory than necessary
2180         https://bugs.webkit.org/show_bug.cgi?id=138495
2181
2182         Reviewed by Mark Lam.
2183
2184         iOS has a per-process virtual memory cap around 1GB, so there's some
2185         value to not going totally ham with virtual memory.
2186
2187         We currently use about 8X the necessary amount:
2188             - 2X to align our VM allocation
2189             - 4X to reserve small / medium / (2) large chunk VM ranges per superchunk
2190
2191         We can cut that down:
2192             - Return the unaligned portion of our VM allocation (-2X)
2193             - Use all the chunks in a superchunk, instead of allocating one
2194               chunk per superchunk (-4X)
2195
2196         * bmalloc/Algorithm.h:
2197         (bmalloc::roundUpToMultipleOf): Added a non-constant version of this
2198         function so we can call it with getpagesize() at runtime.
2199
2200         * bmalloc/Chunk.h:
2201         * bmalloc/LargeChunk.h:
2202         (bmalloc::LargeChunk::create): Deleted. Instead of each chunk allocating
2203         its own VM, VMHeap allocates the superchunk and all the chunks in it at a time.
2204
2205         * bmalloc/VMAllocate.h:
2206         (bmalloc::vmValidate):
2207         (bmalloc::vmAllocate): ASSERT that mmap succeeds to make crashes clearer
2208         if it does not succeed. Allocate precisely, and give back the extra.
2209
2210         * bmalloc/VMHeap.cpp:
2211         (bmalloc::VMHeap::allocateSuperChunk):
2212         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
2213         (bmalloc::VMHeap::allocateMediumChunk): Deleted.
2214         (bmalloc::VMHeap::allocateLargeChunk): Deleted. Use all the chunks
2215         in a superchunk, instead of just one.
2216
2217         * bmalloc/VMHeap.h:
2218         (bmalloc::VMHeap::allocateSmallPage):
2219         (bmalloc::VMHeap::allocateMediumPage):
2220         (bmalloc::VMHeap::allocateLargeRange):
2221         * bmalloc/XLargeChunk.h:
2222         (bmalloc::XLargeChunk::create): Updated to match changes above.
2223
2224 2014-11-01  David Kilzer  <ddkilzer@apple.com>
2225
2226         JavaScriptCore is missing debug info for bmalloc because libbmalloc.a is stripped
2227         <https://webkit.org/b/138286>
2228         <rdar://problem/18847087>
2229
2230         Reviewed by Dan Bernstein.
2231
2232         * Configurations/bmalloc.xcconfig: Set STRIP_INSTALLED_PRODUCT
2233         to NO for the target that produces libbmalloc.a so that the
2234         debug symbols will be linked into JavaScriptCore and end up in
2235         its dSYM file.
2236
2237 2014-10-30  Dana Burkart  <dburkart@apple.com>
2238
2239         <rdar://problem/18821260> Prepare for the mysterious future
2240
2241         Reviewed by Lucas Forschler.
2242
2243         * Configurations/Base.xcconfig:
2244         * Configurations/DebugRelease.xcconfig:
2245
2246 2014-09-24  Geoffrey Garen  <ggaren@apple.com>
2247
2248         bmalloc: cleaned up fast path vs slow path
2249         https://bugs.webkit.org/show_bug.cgi?id=137081
2250
2251         Reviewed by Sam Weinig.
2252
2253         Might be a 1% speedup on MallocBench. Also cleans up the code a bit.
2254
2255         * bmalloc/Allocator.cpp:
2256         (bmalloc::Allocator::Allocator): Merged the small and medium range
2257         caches, just like the small and medium allocators. Ranges are abstract
2258         objects that don't really care whether they hold small or medium objects,
2259         so they don't need to be segregated.
2260
2261         (bmalloc::Allocator::scavenge): Ditto.
2262
2263         (bmalloc::Allocator::allocateBumpRangeSlowCase):
2264         (bmalloc::Allocator::allocateBumpRange): Same thing here, except that
2265         we do care a tiny bit, because we need to specify small vs medium when
2266         allocating new ranges from the heap, to ensure that the heap allocates
2267         from the right segment of VM.
2268
2269         (bmalloc::Allocator::allocateLarge):
2270         (bmalloc::Allocator::allocateXLarge): NO_INLINE because this was clouding
2271         up the fast path. Large allocation performance is dominated by allocation
2272         logic and initialization, so inlining it doesn't help.
2273
2274         (bmalloc::Allocator::allocateSlowCase): Slow path got a bit cleaner since
2275         it doesn't need to distinguish small vs medium objects.
2276
2277         (bmalloc::Allocator::allocateSmallBumpRange): Deleted.
2278         (bmalloc::Allocator::allocateMediumBumpRange): Deleted.
2279
2280         * bmalloc/Allocator.h:
2281         * bmalloc/BumpRange.h:
2282
2283         * bmalloc/Cache.cpp:
2284         (bmalloc::Cache::allocateSlowCase): Deleted.
2285         (bmalloc::Cache::deallocateSlowCase): Deleted.
2286         * bmalloc/Cache.h:
2287         (bmalloc::Cache::allocate):
2288         (bmalloc::Cache::deallocate):
2289         (bmalloc::Cache::allocateFastCase): Deleted.
2290         (bmalloc::Cache::deallocateFastCase): Deleted. Removed the Cache slow
2291         paths. The downside to this change is that the fast path branches to two
2292         distinct failure cases instead of one. The upside is that the slow path
2293         doesn't need to re-read the segment register, which is not as cheap as a
2294         normal register, and it doesn't need to do an extra level of function 
2295         call. Seems to be worth it.
2296
2297         * bmalloc/Deallocator.h:
2298         * bmalloc/Heap.cpp:
2299         (bmalloc::Heap::refillSmallBumpRangeCache):
2300         (bmalloc::Heap::refillMediumBumpRangeCache):
2301         * bmalloc/Heap.h: Updated for interface changes.
2302
2303         * bmalloc/Sizes.h: The most ranges a cache will hold is the number of
2304         small lines in a page / 2, since any other free lines will coalesce
2305         with their neighbors.
2306
2307 2014-09-23  Geoffrey Garen  <ggaren@apple.com>
2308
2309         Rolled out r173346.
2310
2311             bmalloc should honor the FastMalloc statistics API
2312             https://bugs.webkit.org/show_bug.cgi?id=136592
2313
2314         This didn't really work. Because we allow ranges with and without
2315         physical pages to merge, and we allow double-committing and
2316         double-decommitting, we can't rely on commit actions to track memory
2317         footprint.
2318
2319         * bmalloc/Heap.cpp:
2320         (bmalloc::Heap::size): Deleted.
2321         (bmalloc::Heap::capacity): Deleted.
2322         * bmalloc/Heap.h:
2323         * bmalloc/VMHeap.cpp:
2324         (bmalloc::VMHeap::VMHeap):
2325         (bmalloc::VMHeap::allocateSmallChunk):
2326         (bmalloc::VMHeap::allocateMediumChunk):
2327         (bmalloc::VMHeap::allocateLargeChunk):
2328         * bmalloc/VMHeap.h:
2329         (bmalloc::VMHeap::allocateSmallPage):
2330         (bmalloc::VMHeap::allocateMediumPage):
2331         (bmalloc::VMHeap::allocateLargeRange):
2332         (bmalloc::VMHeap::deallocateSmallPage):
2333         (bmalloc::VMHeap::deallocateMediumPage):
2334         (bmalloc::VMHeap::deallocateLargeRange):
2335         (bmalloc::VMHeap::size): Deleted.
2336         (bmalloc::VMHeap::capacity): Deleted.
2337         * bmalloc/bmalloc.h:
2338         (bmalloc::api::heapSize): Deleted.
2339         (bmalloc::api::heapCapacity): Deleted.
2340
2341 2014-09-23  Geoffrey Garen  <ggaren@apple.com>
2342
2343         bmalloc: Allocation should be more precise
2344         https://bugs.webkit.org/show_bug.cgi?id=136993
2345
2346         Reviewed by Gavin Barraclough.
2347
2348         13% reduction in heap size on the MallocBench *_memory_warning benchmarks.
2349
2350         This patch teaches the allocator to merge adjacent free lines into a
2351         single allocatable range. This allows us to shrink the size of an
2352         individual line without increasing fragmentation or the rate of allocator
2353         slow paths.
2354
2355         We'll only take more slow paths when available memory is sparse, which
2356         is exactly when it's worth it. When available memory is dense, we'll
2357         take fewer slow paths.
2358
2359         * bmalloc.xcodeproj/project.pbxproj:
2360         * bmalloc/Algorithm.h:
2361         (bmalloc::divideRoundingUp):
2362
2363         * bmalloc/Allocator.cpp:
2364         (bmalloc::Allocator::Allocator): Updated for interface changes.
2365
2366         (bmalloc::Allocator::scavenge): Scavenge by object instead of by line.
2367         Now that we merge lines, it's not convenient to scavenge by line.
2368
2369         (bmalloc::Allocator::allocateSmallBumpRange):
2370         (bmalloc::Allocator::allocateMediumBumpRange): Allocate whole ranges
2371         instead of individual lines.
2372
2373         (bmalloc::Allocator::allocateSlowCase):
2374         (bmalloc::Allocator::allocateSmallLine): Deleted.
2375         (bmalloc::Allocator::allocateMediumLine): Deleted.
2376         (bmalloc::Allocator::allocateMedium): Deleted.
2377         * bmalloc/Allocator.h:
2378         (bmalloc::Allocator::allocateFastCase): Folded medium allocations
2379         into the standard fast path with small allocations. Since a BumpAllocator
2380         just allocates out of an arbitrary range, it doesn't need to distinguish
2381         between small and medium lines.
2382
2383         * bmalloc/BumpAllocator.h:
2384         (bmalloc::BumpAllocator::size):
2385         (bmalloc::BumpAllocator::BumpAllocator):
2386         (bmalloc::BumpAllocator::init):
2387         (bmalloc::BumpAllocator::refill):
2388         (bmalloc::BumpAllocator::line): Deleted. No need to track line information
2389         anymore: the heap just gives us a pointer and a pre-computed number of
2390         objects, and we allocate them.
2391
2392         * bmalloc/Deallocator.cpp:
2393         (bmalloc::Deallocator::processObjectLog): Updated for interface changes.
2394
2395         * bmalloc/Heap.cpp:
2396         (bmalloc::Heap::Heap):
2397         (bmalloc::Heap::initializeLineMetadata): Pre-compute precise metadata
2398         detailing where all objects will lie in memory. After we merge two lines,
2399         we might allocate an object that spans from one line to the next. This
2400         metadata details which bits of memory overlap in that way, and how they
2401         overlap.
2402
2403         (bmalloc::Heap::refillSmallBumpRangeCache):
2404         (bmalloc::Heap::refillMediumBumpRangeCache): Scan a whole page at a time,
2405         and merge adjacent free lines into BumpRanges.
2406
2407         (bmalloc::Heap::allocateSmallPage):
2408         (bmalloc::Heap::allocateMediumPage):
2409         (bmalloc::Heap::deallocateSmallLine):
2410         (bmalloc::Heap::deallocateMediumLine): Track pages rather than lines,
2411         since we scan for free memory a page at a time.
2412
2413         (bmalloc::Heap::allocateSmallLineSlowCase): Deleted.
2414         (bmalloc::Heap::allocateMediumLineSlowCase): Deleted. Folded into the
2415         fast path.
2416
2417         * bmalloc/Heap.h:
2418         (bmalloc::Heap::derefSmallLine):
2419         (bmalloc::Heap::derefMediumLine):
2420         (bmalloc::Heap::deallocateSmallLine): Deleted.
2421         (bmalloc::Heap::allocateSmallLine): Deleted.
2422         (bmalloc::Heap::deallocateMediumLine): Deleted.
2423         (bmalloc::Heap::allocateMediumLine): Deleted. Updated for interface changes.
2424
2425         * bmalloc/Line.h:
2426         (bmalloc::Line<Traits>::ref):
2427         (bmalloc::Line<Traits>::deref):
2428         (bmalloc::Line<Traits>::concurrentRef): Deleted. We don't pass a derefCount
2429         anymore, since we only ever deref by 1 now.
2430
2431         * bmalloc/MediumAllocator.h:
2432         (bmalloc::MediumAllocator::isNull): Deleted.
2433         (bmalloc::MediumAllocator::MediumAllocator): Deleted.
2434         (bmalloc::MediumAllocator::line): Deleted.
2435         (bmalloc::MediumAllocator::allocate): Deleted.
2436         (bmalloc::MediumAllocator::derefCount): Deleted.
2437         (bmalloc::MediumAllocator::refill): Deleted.
2438         (bmalloc::MediumAllocator::clear): Deleted. Deleted some code that's
2439         been dead for a while, since it doesn't build anymore with this patch.
2440
2441         * bmalloc/Page.h:
2442         (bmalloc::Page::sizeClass):
2443         (bmalloc::Page::setSizeClass):
2444         (bmalloc::Page::smallSizeClass): Deleted.
2445         (bmalloc::Page::setSmallSizeClass): Deleted. Renamed setSmallSizeClass
2446         to sizeClass, since we use it for medium sizes too.
2447
2448         * bmalloc/Sizes.h:
2449         (bmalloc::Sizes::sizeClass):
2450         (bmalloc::Sizes::objectSize): Shrank line sizes to save memory.
2451
2452         (bmalloc::Sizes::smallSizeClassFor): Deleted.
2453         (bmalloc::Sizes::mediumSizeClassFor): Deleted.
2454
2455         * bmalloc/bmalloc.h:
2456         (bmalloc::api::realloc): Now that we have precise objects sizes, realloc
2457         can be a bit more precise. It also has to be, since we can't guarantee
2458         that an object ends at the end of a line anymore.
2459
2460 2014-09-19  Daniel Bates  <dabates@apple.com>
2461
2462         Always assume internal SDK when building configuration Production
2463         https://bugs.webkit.org/show_bug.cgi?id=136925
2464         <rdar://problem/18362399>
2465
2466         Reviewed by Dan Bernstein.
2467
2468         * Configurations/Base.xcconfig:
2469
2470 2014-09-16  Geoffrey Garen  <ggaren@apple.com>
2471
2472         bmalloc: moved line caches from the deallocator to the allocator
2473         https://bugs.webkit.org/show_bug.cgi?id=136868
2474
2475         Reviewed by Gavin Barraclough.
2476
2477         I did this mostly as a simplification, to make it easier to change the
2478         allocation strategy.
2479
2480         No throughput change on MallocBench. Saves about 50kB.
2481
2482         Since the deallocator needs to lock the heap when freeing lines anyway,
2483         there isn't much benefit to giving the deallocator a local cache of
2484         deallocated lines.
2485
2486         We still give the allocator a local cache of lines because that does
2487         reduce the frequency at which it needs to lock the heap in order to
2488         acquire more lines.
2489
2490         * bmalloc/Allocator.cpp:
2491         (bmalloc::Allocator::scavenge):
2492         (bmalloc::Allocator::allocateSmallLine):
2493         (bmalloc::Allocator::allocateMediumLine):
2494         (bmalloc::Allocator::allocateMedium):
2495         (bmalloc::Allocator::allocateSlowCase):
2496         * bmalloc/Allocator.h:
2497         * bmalloc/Deallocator.cpp:
2498         (bmalloc::Deallocator::Deallocator):
2499         (bmalloc::Deallocator::scavenge):
2500         (bmalloc::Deallocator::processObjectLog):
2501         (bmalloc::Deallocator::deallocateSmallLine): Deleted.
2502         (bmalloc::Deallocator::allocateSmallLine): Deleted.
2503         (bmalloc::Deallocator::deallocateMediumLine): Deleted.
2504         (bmalloc::Deallocator::allocateMediumLine): Deleted.
2505         * bmalloc/Deallocator.h:
2506
2507         * bmalloc/Sizes.h:
2508         * bmalloc/VMAllocate.h: Took the opportunity to make the line cache size
2509         exactly one page in size. That's about what we were shooting for anyway,
2510         and it may make it easier to switch to per-page allocation in future.
2511
2512 2014-09-15  Geoffrey Garen  <ggaren@apple.com>
2513
2514         bmalloc: allocate small and medium objects using the same bump pointer class
2515         https://bugs.webkit.org/show_bug.cgi?id=136843
2516
2517         Reviewed by Gavin Barraclough.
2518
2519         4% speedup on MallocBench.
2520
2521         Now that medium-sized objects have dedicated per-size allocators, they
2522         don't need to use an arbitrary bump pointer allocator. This means that
2523         every allocator knows how many objects it will allocate from the start,
2524         and we don't need a post-processing step to adjust refcounts based on
2525         real allocation count.
2526
2527         * bmalloc.xcodeproj/project.pbxproj: Renamed SmallAllocator to BumpAllocator
2528         since it's used for small and medium objects now.
2529
2530         * bmalloc/Allocator.cpp:
2531         (bmalloc::Allocator::Allocator): Updated to use new interface.
2532         (bmalloc::Allocator::scavenge): To "retire" an allocator, we just need
2533         to make sure that we finish allocating all the objects in it.
2534
2535         (bmalloc::Allocator::allocateMedium):
2536         (bmalloc::Allocator::allocateSlowCase):
2537         (bmalloc::Allocator::retire): Deleted.
2538         (bmalloc::Allocator::processSmallAllocatorLog): Deleted.
2539         (bmalloc::Allocator::processMediumAllocatorLog): Deleted.
2540         * bmalloc/Allocator.h:
2541         (bmalloc::Allocator::allocateFastCase): Removed abstractions and data
2542         used to post-process an allocator based on how many objects it allocated.
2543
2544         * bmalloc/BumpAllocator.h: Copied from Source/bmalloc/bmalloc/SmallAllocator.h.
2545         (bmalloc::BumpAllocator::BumpAllocator):
2546         (bmalloc::BumpAllocator::init):
2547         (bmalloc::BumpAllocator::line):
2548         (bmalloc::BumpAllocator::validate):
2549         (bmalloc::BumpAllocator::allocate):
2550         (bmalloc::BumpAllocator::refill):
2551         (bmalloc::BumpAllocator::clear): Updated these functions to be agnostic
2552         about the kinds of lines they allocate into. In some cases, the line
2553         type must be provided as a template parameter by the caller.
2554
2555         (bmalloc::SmallAllocator::SmallAllocator): Deleted.
2556         (bmalloc::SmallAllocator::line): Deleted.
2557         (bmalloc::SmallAllocator::allocate): Deleted.
2558         (bmalloc::SmallAllocator::objectCount): Deleted.
2559         (bmalloc::SmallAllocator::derefCount): Deleted.
2560         (bmalloc::SmallAllocator::refill): Deleted.
2561         (bmalloc::SmallAllocator::clear): Deleted.
2562
2563         * bmalloc/ObjectType.h:
2564         (bmalloc::isMedium):
2565
2566         * bmalloc/SmallAllocator.h:
2567         (bmalloc::SmallAllocator::isNull): Deleted.
2568         (bmalloc::SmallAllocator::canAllocate): Deleted.
2569         (bmalloc::SmallAllocator::SmallAllocator): Deleted.
2570         (bmalloc::SmallAllocator::line): Deleted.
2571         (bmalloc::SmallAllocator::allocate): Deleted.
2572         (bmalloc::SmallAllocator::objectCount): Deleted.
2573         (bmalloc::SmallAllocator::derefCount): Deleted.
2574         (bmalloc::SmallAllocator::refill): Deleted.
2575         (bmalloc::SmallAllocator::clear): Deleted.
2576
2577 2014-09-12  Geoffrey Garen  <ggaren@apple.com>
2578
2579         Fixed a goof in bmalloc Vector sizing
2580         https://bugs.webkit.org/show_bug.cgi?id=136795
2581
2582         Reviewed by Gavin Barraclough and Sam Weinig.
2583
2584         We want our minimum vector to be page-sized since the OS will give us
2585         a page no matter what -- but we want that many bytes, and not enough
2586         bytes to store that many elements.
2587
2588         * bmalloc/Vector.h: Math is hard.
2589
2590 2014-09-11  Geoffrey Garen  <ggaren@apple.com>
2591
2592         bmalloc should segregate medium-sized objects by line like it does for small-sized objects
2593         https://bugs.webkit.org/show_bug.cgi?id=136693
2594
2595         Reviewed by Gavin Barraclough.
2596
2597         4% reduction in heap size on the MallocBench *_memory_warning benchmarks.
2598
2599         No throughput change.
2600
2601         We keep an array of medium allocators, just like our array of small
2602         allocators.
2603
2604         In future, we can simplify the allocation fast path by merging the small
2605         and medium allocator arrays. For now, this is the simplest change that
2606         gets the win.
2607
2608         * bmalloc/Allocator.cpp:
2609         (bmalloc::Allocator::Allocator):
2610         (bmalloc::Allocator::scavenge):
2611         (bmalloc::Allocator::allocateMedium):
2612         * bmalloc/Allocator.h:
2613         * bmalloc/Sizes.h:
2614         (bmalloc::Sizes::mediumSizeClassFor):
2615
2616 2014-09-11  Geoffrey Garen  <ggaren@apple.com>
2617
2618         Reviewed by Sam Weinig.
2619
2620         Renamed log => retire for clarity.
2621
2622         * bmalloc/Allocator.cpp:
2623         (bmalloc::Allocator::scavenge):
2624         (bmalloc::Allocator::retire):
2625         (bmalloc::Allocator::allocateMedium):
2626         (bmalloc::Allocator::allocateSlowCase):
2627         (bmalloc::Allocator::log): Deleted.
2628         * bmalloc/Allocator.h:
2629
2630 2014-09-11  Geoffrey Garen  <ggaren@apple.com>
2631
2632         bmalloc: eager scavenge leaves behind a bogus allocator
2633         https://bugs.webkit.org/show_bug.cgi?id=136743
2634
2635         Reviewed by Sam Weinig.
2636
2637         Be sure to clear the allocator after logging it in the eager scavenge
2638         case, so that we don't later try to allocate out of the lines that we
2639         have thrown away.
2640
2641         We didn't need to do this previously because scavenge would only happen
2642         at thread exit time, after which no further allocation from the per-thread
2643         cache would take place.
2644
2645         * bmalloc/Allocator.cpp:
2646         (bmalloc::Allocator::scavenge):
2647         * bmalloc/MediumAllocator.h:
2648         (bmalloc::MediumAllocator::clear):
2649         * bmalloc/SmallAllocator.h:
2650         (bmalloc::SmallAllocator::clear):
2651
2652 2014-09-05  Geoffrey Garen  <ggaren@apple.com>
2653
2654         bmalloc should honor the FastMalloc statistics API
2655         https://bugs.webkit.org/show_bug.cgi?id=136592
2656
2657         Reviewed by Gavin Barraclough.
2658
2659         We do this by tracking "size" and "capacity" in the VM heap.
2660
2661         The VM heap's "capacity" is all the VM we ever allocated.
2662
2663         The VM heap's "size" the subset of VM currently held onto by the
2664         VM heap (and therefore not in use by the regular heap).
2665
2666         Somewhat ironically, reducing the process's memory footprint, increases
2667         the size of the VM heap, since the VM heap holds the pages that are
2668         purely virtual and not physical.
2669
2670         * bmalloc/Heap.cpp:
2671         (bmalloc::Heap::size):
2672         (bmalloc::Heap::capacity):
2673         * bmalloc/Heap.h:
2674         * bmalloc/VMHeap.cpp:
2675         (bmalloc::VMHeap::VMHeap):
2676         (bmalloc::VMHeap::allocateSmallChunk):
2677         (bmalloc::VMHeap::allocateMediumChunk):
2678         (bmalloc::VMHeap::allocateLargeChunk):
2679         * bmalloc/VMHeap.h:
2680         (bmalloc::VMHeap::size):
2681         (bmalloc::VMHeap::capacity):
2682         (bmalloc::VMHeap::allocateSmallPage):
2683         (bmalloc::VMHeap::allocateMediumPage):
2684         (bmalloc::VMHeap::allocateLargeRange):
2685         (bmalloc::VMHeap::deallocateSmallPage):
2686         (bmalloc::VMHeap::deallocateMediumPage):
2687         (bmalloc::VMHeap::deallocateLargeRange):
2688         * bmalloc/bmalloc.h:
2689         (bmalloc::api::heapSize):
2690         (bmalloc::api::heapCapacity):
2691
2692 2014-09-02  Geoffrey Garen  <ggaren@apple.com>
2693
2694         bmalloc crashes on the EWS bots (due to bad large object allocation)
2695         https://bugs.webkit.org/show_bug.cgi?id=136469
2696
2697         Reviewed by Andreas Kling.
2698
2699         It's possible to convince bmalloc to perform a bad large object allocation,
2700         through these steps:
2701
2702         (1) Insert object A into freelist F0.
2703
2704         (2) Split, merge and split again A's neighbors such that object B is
2705         inserted into freelist F0, with boundary tag and size equal to object A,
2706         but pointer not completely equal to object A. Put object B at the head of F0.
2707
2708         (3) Allocate some other object from F0, swapping its position in the
2709         freelist with object B, such that object A is now ahead of object B.
2710
2711         --> Now, the next allocation for size A/B will allocate object A, which
2712         has a slightly wrong idea about where the object actually begins.
2713         Immediately, you'll corrupt a little memory, and over time, you'll also
2714         corrupt boundary tag metadata.
2715
2716         The solution is to store the begin pointer in the boundary tag. Luckily,
2717         this doesn't make the tag any bigger, and it's not a noticeable slowdown
2718         on MallocBench.
2719
2720         * bmalloc/Algorithm.h:
2721         (bmalloc::rightShift):
2722         * bmalloc/BeginTag.h:
2723         (bmalloc::BeginTag::isInFreeList): This is the bug fix. Make sure to
2724         validate the start pointer when popping off the free list. Through a
2725         very uncommon set of steps, it is possible to have an item in the free
2726         list that is valid by all accounts except for its start pointer.
2727
2728         * bmalloc/BoundaryTag.h:
2729         (bmalloc::BoundaryTag::compactBegin):
2730         (bmalloc::BoundaryTag::setRange):
2731         (bmalloc::BoundaryTag::setSize): Deleted. Record a compact version of the
2732         start pointer. We don't need the whole pointer -- just the offset, in
2733         largeAlignment increments, into the relevant boundary tag bucket.
2734
2735         * bmalloc/BoundaryTagInlines.h:
2736         (bmalloc::validateNext):
2737         (bmalloc::BoundaryTag::init):
2738         (bmalloc::BoundaryTag::mergeLarge):
2739         (bmalloc::BoundaryTag::splitLarge):
2740         * bmalloc/SegregatedFreeList.cpp:
2741         (bmalloc::SegregatedFreeList::insert):
2742         (bmalloc::SegregatedFreeList::takeGreedy):
2743         (bmalloc::SegregatedFreeList::take): Provide the whole range instead of
2744         the size when establishing a boundary tag, as required by the new
2745         interface.
2746
2747         * bmalloc/Sizes.h:
2748
2749 2014-08-14  Geoffrey Garen  <ggaren@apple.com>
2750
2751         Fixed a bmalloc crash seen on the EWS bot
2752         https://bugs.webkit.org/show_bug.cgi?id=135955
2753
2754         Reviewed by Andreas Kling.
2755
2756         * bmalloc/Syscall.h: Some CG APIs vm_copy their input buffers. If the
2757         input buffer is a malloc region, that region will get marked Copy-On-Write
2758         by the kernel. Calls to madvise() for COW regions fail and return EINVAL
2759         on older OS X's. In 10.10, they still fail, but they do not return
2760         EINVAL.
2761
2762         So, we can only ASSERT that our syscalls succeed starting with 10.10.
2763
2764 2014-08-14  Geoffrey Garen  <ggaren@apple.com>
2765
2766         Fixed the bmalloc build
2767         https://bugs.webkit.org/show_bug.cgi?id=135953
2768
2769         Reviewed by Andreas Kling.
2770
2771         * bmalloc.xcodeproj/project.pbxproj: Marked a few headers as private.
2772         These headers are used, so they must be available outside the project.
2773
2774 2014-08-13  Daniel Bates  <dabates@apple.com>
2775
2776         Attempt to fix the build following <http://trac.webkit.org/changeset/172576>
2777         (https://bugs.webkit.org/show_bug.cgi?id=135895)
2778
2779         Substitute PerThreadStorage<T>::initSharedKeyIfNeeded() for initSharedKeyIfNeeded() in
2780         implementation of PerThread<T>::getFastCase().
2781
2782         * bmalloc/PerThread.h:
2783         (bmalloc::PerThread<T>::getFastCase):
2784
2785 2014-08-13  Daniel Bates  <dabates@apple.com>
2786
2787         Make bmalloc::PerThread work without C++ thread local storage
2788         https://bugs.webkit.org/show_bug.cgi?id=135895
2789
2790         Reviewed by Geoffrey Garen.
2791
2792         Implement support for building bmalloc without C++ thread local storage.
2793
2794         * bmalloc/BPlatform.h: Remove macro define BPLATFORM_IOS_SIMULATOR. Added macro function
2795         BCOMPILER_SUPPORTS() and macro define BCOMPILER_SUPPORTS_CXX_THREAD_LOCAL that can be used
2796         to determine whether the compiler supports C++ thread local storage.
2797         * bmalloc/PerThread.h:
2798         (bmalloc::PerThreadStorage::get): Modified to call pthread_getspecific() when building
2799         without C++ thread local storage.
2800         (bmalloc::PerThreadStorage::initSharedKeyIfNeeded): Added.
2801         (bmalloc::PerThreadStorage::init): Moved logic to initialize shared Pthread key from here to
2802         PerThreadStorage::initSharedKeyIfNeeded().
2803         (bmalloc::PerThread<T>::getFastCase): Modified to call PerThreadStorage::initSharedKeyIfNeeded()
2804         before querying PerThreadStorage::get() when building without C++ thread local storage so as to
2805         ensure that the shared key has been initialized.
2806         (_pthread_setspecific_direct): Deleted.
2807         (_pthread_getspecific_direct): Deleted.
2808
2809 2014-08-13  Daniel Bates  <dabates@apple.com>
2810
2811         [iOS] Make JavaScriptCore and bmalloc build with the public SDK
2812         https://bugs.webkit.org/show_bug.cgi?id=135848
2813
2814         Reviewed by Geoffrey Garen.
2815
2816         * bmalloc/BPlatform.h: Added macro BPLATFORM_IOS_SIMULATOR, which evaluates to true
2817         when building for the iOS Simulator.
2818         * bmalloc/PerThread.h: Use pthread_machdep.h code path when building for iOS Simulator
2819         using the public SDK.
2820         (_pthread_setspecific_direct): Added; only defined when building for the iOS Simulator
2821         using the public SDK.
2822         (_pthread_getspecific_direct): Added; only defined when building for the iOS Simulator
2823         using the public SDK.
2824
2825 2014-08-12  Daniel Bates  <dabates@apple.com>
2826
2827         BPLATFORM(IOS) always evaluates to false
2828         https://bugs.webkit.org/show_bug.cgi?id=135843
2829
2830         Reviewed by Geoffrey Garen.
2831
2832         Fix typo in definition of BPLATFORM() and include system header TargetConditionals.h
2833         (when building on an Apple platform) so that BPLATFORM(X) evaluates to true when
2834         building for platform X. In particular, so that BPLATFORM(IOS) evaluates to true when
2835         building for iOS.
2836
2837         As a side effect of this change, the change made in <http://trac.webkit.org/changeset/167289>
2838         will be honored and iOS will assume a VM page size of 16kB (again) instead of 4kB.
2839
2840         * bmalloc/BPlatform.h:
2841
2842 2014-08-11  Andy Estes  <aestes@apple.com>
2843
2844         [iOS] Get rid of iOS.xcconfig
2845         https://bugs.webkit.org/show_bug.cgi?id=135809
2846
2847         Reviewed by Joseph Pecoraro.
2848
2849         All iOS.xcconfig did was include AspenFamily.xcconfig, so there's no need for the indirection.
2850
2851         * Configurations/Base.xcconfig:
2852         * Configurations/iOS.xcconfig: Removed.
2853         * bmalloc.xcodeproj/project.pbxproj:
2854
2855 2014-05-01  Dan Bernstein  <mitz@apple.com>
2856
2857         Fixed production builds for the iOS Simulator.
2858         <rdar://problem/16792221>
2859
2860         * Configurations/bmalloc.xcconfig: Include INSTALL_PATH_PREFIX in
2861         PRIVATE_HEADERS_FOLDER_PATH when installing.
2862
2863 2014-04-20  Geoffrey Garen  <ggaren@apple.com>
2864
2865         bmalloc: Segregate pages by objects size
2866         https://bugs.webkit.org/show_bug.cgi?id=131909
2867
2868         Reviewed by Andreas Kling.
2869
2870         2% reduction in memory-at-end on the Membuster memory_warning benchmarks.
2871
2872         * bmalloc/Allocator.cpp:
2873         (bmalloc::Allocator::allocateSlowCase):
2874         * bmalloc/Allocator.h:
2875         (bmalloc::Allocator::allocateFastCase):
2876         (bmalloc::Allocator::smallAllocatorFor): Use the new shared helper
2877         function for size class calculation.
2878
2879         * bmalloc/Deallocator.cpp:
2880         (bmalloc::Deallocator::Deallocator):
2881         (bmalloc::Deallocator::scavenge):
2882         (bmalloc::Deallocator::deallocateSmallLine):
2883         (bmalloc::Deallocator::allocateSmallLine):
2884         * bmalloc/Deallocator.h: Keep a cache for every size class, since the
2885         cache can't be shared anymore.
2886
2887         * bmalloc/Heap.cpp:
2888         (bmalloc::Heap::allocateSmallLineSlowCase):
2889         * bmalloc/Heap.h:
2890         (bmalloc::Heap::deallocateSmallLine): Ditto.
2891
2892         (bmalloc::Heap::allocateSmallLine): Check size class in addition to
2893         page refcount when allocating a line because we might have deallocated
2894         the page and the recycled it for another size class.
2895
2896         (bmalloc::Heap::deallocateMediumLine):
2897         (bmalloc::Heap::allocateMediumLine):
2898         * bmalloc/Line.h:
2899         (bmalloc::Line::refCount):
2900         * bmalloc/Page.h:
2901         (bmalloc::Page::refCount):
2902         (bmalloc::Page::smallSizeClass):
2903         (bmalloc::Page::setSmallSizeClass):
2904         (bmalloc::Page<Traits>::refCount): Deleted.
2905         * bmalloc/Sizes.h:
2906         (bmalloc::Sizes::smallSizeClassFor): New shared API for computing
2907         an index into an array from a size.
2908
2909 2014-04-19  Geoffrey Garen  <ggaren@apple.com>
2910
2911         bmalloc: Improved alignment in LargeChunk
2912         https://bugs.webkit.org/show_bug.cgi?id=131895
2913
2914         Reviewed by Andreas Kling.
2915
2916         * bmalloc/Chunk.h:
2917         * bmalloc/LargeChunk.h: Align to vmPageSize just like Chunk does.
2918         Technically, the previous alignment was harmless, but I would prefer,
2919         dear reader, not to have to explain the interlocking set of
2920         circumstances that made it so.
2921
2922 2014-04-19  Geoffrey Garen  <ggaren@apple.com>
2923
2924         Rolled out r167502 because it caused a crash on the facebook benchmark.
2925
2926         Unreviewed.
2927
2928             bmalloc: Added an XSmall line size
2929             https://bugs.webkit.org/show_bug.cgi?id=131851
2930
2931             Reviewed by Sam Weinig.
2932
2933 2014-04-19  Geoffrey Garen  <ggaren@apple.com>
2934
2935         bmalloc: Mutex should be harder to use wrong
2936         https://bugs.webkit.org/show_bug.cgi?id=131879
2937
2938         Reviewed by Andreas Kling.
2939
2940         Mutex now has a proper constructor, so you can't deadlock by forgetting
2941         to initialize it.
2942
2943         * bmalloc.xcodeproj/project.pbxproj:
2944         * bmalloc/Allocator.cpp:
2945         (bmalloc::Allocator::processXSmallAllocatorLog):
2946         (bmalloc::Allocator::processSmallAllocatorLog):
2947         (bmalloc::Allocator::processMediumAllocatorLog):
2948         (bmalloc::Allocator::allocateLarge):
2949         (bmalloc::Allocator::allocateXLarge): Global replace Mutex => StaticMutex,
2950         since the Heap mutex is a static.
2951
2952         * bmalloc/AsyncTask.h:
2953         (bmalloc::Function>::AsyncTask): Use Mutex, since we're not static. No
2954         need for explicit initialization anymore.
2955
2956         * bmalloc/Deallocator.cpp:
2957         (bmalloc::Deallocator::scavenge):
2958         (bmalloc::Deallocator::deallocateLarge):
2959         (bmalloc::Deallocator::deallocateXLarge):
2960         (bmalloc::Deallocator::processObjectLog):
2961         (bmalloc::Deallocator::deallocateSmallLine):
2962         (bmalloc::Deallocator::deallocateXSmallLine):
2963         (bmalloc::Deallocator::allocateSmallLine):
2964         (bmalloc::Deallocator::allocateXSmallLine):
2965         (bmalloc::Deallocator::deallocateMediumLine):
2966         (bmalloc::Deallocator::allocateMediumLine):
2967         * bmalloc/Deallocator.h:
2968         * bmalloc/Heap.cpp:
2969         (bmalloc::sleep):
2970         (bmalloc::Heap::Heap):
2971         (bmalloc::Heap::concurrentScavenge):
2972         (bmalloc::Heap::scavenge):
2973         (bmalloc::Heap::scavengeSmallPages):
2974         (bmalloc::Heap::scavengeXSmallPages):
2975         (bmalloc::Heap::scavengeMediumPages):
2976         (bmalloc::Heap::scavengeLargeRanges):
2977         (bmalloc::Heap::allocateXSmallLineSlowCase):
2978         (bmalloc::Heap::allocateSmallLineSlowCase):
2979         (bmalloc::Heap::allocateMediumLineSlowCase):
2980         (bmalloc::Heap::allocateXLarge):
2981         (bmalloc::Heap::deallocateXLarge):
2982         (bmalloc::Heap::allocateLarge):
2983         (bmalloc::Heap::deallocateLarge):
2984         * bmalloc/Heap.h:
2985         (bmalloc::Heap::deallocateXSmallLine):
2986         (bmalloc::Heap::allocateXSmallLine):
2987         (bmalloc::Heap::deallocateSmallLine):
2988         (bmalloc::Heap::allocateSmallLine):
2989         (bmalloc::Heap::deallocateMediumLine):
2990         (bmalloc::Heap::allocateMediumLine):
2991         * bmalloc/Line.h:
2992         (bmalloc::Line<Traits>::deref):
2993         * bmalloc/Mutex.cpp: Removed.
2994         * bmalloc/Mutex.h:
2995         (bmalloc::Mutex::Mutex):
2996         (bmalloc::Mutex::init): Deleted.
2997         (bmalloc::Mutex::try_lock): Deleted.
2998         (bmalloc::Mutex::lock): Deleted.
2999         (bmalloc::Mutex::unlock): Deleted.
3000         * bmalloc/Page.h:
3001         (bmalloc::Page<Traits>::ref):
3002         (bmalloc::Page<Traits>::deref):
3003         (bmalloc::Page<Traits>::refCount):
3004         * bmalloc/PerProcess.h:
3005         (bmalloc::PerProcess::mutex):
3006         (bmalloc::PerProcess<T>::getSlowCase):
3007         * bmalloc/StaticMutex.cpp: Added.
3008         (bmalloc::StaticMutex::lockSlowCase):
3009         * bmalloc/StaticMutex.h: Added.
3010         (bmalloc::StaticMutex::init):
3011         (bmalloc::StaticMutex::try_lock):
3012         (bmalloc::StaticMutex::lock):
3013         (bmalloc::StaticMutex::unlock):
3014         * bmalloc/VMHeap.h:
3015         (bmalloc::VMHeap::deallocateXSmallPage):
3016         (bmalloc::VMHeap::deallocateSmallPage):
3017         (bmalloc::VMHeap::deallocateMediumPage):
3018         (bmalloc::VMHeap::deallocateLargeRange):
3019         * bmalloc/bmalloc.h:
3020         (bmalloc::api::scavenge): Global replace Mutex => StaticMutex,
3021         since the Heap mutex is a static.
3022
3023 2014-04-18  Geoffrey Garen  <ggaren@apple.com>
3024
3025         bmalloc: AsyncTask should use Mutex instead of std::mutex
3026         https://bugs.webkit.org/show_bug.cgi?id=131865
3027
3028         Reviewed by Gavin Barraclough.
3029
3030         std::mutex is so slow that it makes parallelizing simple tasks through
3031         AsyncTask a net regression. Mutex fixes this.
3032
3033         * bmalloc/AsyncTask.h:
3034         (bmalloc::Function>::AsyncTask):
3035         (bmalloc::Function>::join):
3036         (bmalloc::Function>::runSlowCase):
3037         (bmalloc::Function>::entryPoint):
3038         * bmalloc/Mutex.h:
3039         (bmalloc::Mutex::init):
3040
3041 2014-04-18  Geoffrey Garen  <ggaren@apple.com>
3042
3043         bmalloc: Added an XSmall line size
3044         https://bugs.webkit.org/show_bug.cgi?id=131851
3045
3046         Reviewed by Sam Weinig.
3047
3048         Reduces malloc footprint on Membuster recordings by 10%.
3049
3050         This is a throughput regression, but we're still way ahead of TCMalloc.
3051         I have some ideas for how to recover the regression -- but I wanted to
3052         get this win in first.
3053
3054         Full set of benchmark results:
3055
3056                 bmalloc> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks --measure-heap nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
3057                                                                                                 
3058                                                                nopatch                      patch                                Δ
3059                 Peak Memory:
3060                     reddit_memory_warning                      7,896kB                    7,532kB                  ^ 1.05x smaller
3061                     flickr_memory_warning                     12,968kB                   12,324kB                  ^ 1.05x smaller
3062                     theverge_memory_warning                   16,672kB                   15,200kB                   ^ 1.1x smaller
3063
3064                     <geometric mean>                          11,952kB                   11,216kB                  ^ 1.07x smaller
3065                     <arithmetic mean>                         12,512kB                   11,685kB                  ^ 1.07x smaller
3066                     <harmonic mean>                           11,375kB                   10,726kB                  ^ 1.06x smaller
3067
3068                 Memory at End:
3069                     reddit_memory_warning                      7,320kB                    6,856kB                  ^ 1.07x smaller
3070                     flickr_memory_warning                     10,848kB                    9,692kB                  ^ 1.12x smaller
3071                     theverge_memory_warning                   16,380kB                   14,872kB                   ^ 1.1x smaller
3072
3073                     <geometric mean>                          10,916kB                    9,961kB                   ^ 1.1x smaller
3074                     <arithmetic mean>                         11,516kB                   10,473kB                   ^ 1.1x smaller
3075                     <harmonic mean>                           10,350kB                    9,485kB                  ^ 1.09x smaller
3076
3077                 MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
3078                                                                                                 
3079                                                    nopatch                patch                         Δ
3080                 Execution Time:
3081                     churn                            127ms                151ms            ! 1.19x slower
3082                     list_allocate                    130ms                164ms            ! 1.26x slower
3083                     tree_allocate                    109ms                127ms            ! 1.17x slower
3084                     tree_churn                       115ms                120ms            ! 1.04x slower
3085                     facebook                         240ms                259ms            ! 1.08x slower
3086                     fragment                          91ms                131ms            ! 1.44x slower
3087                     fragment_iterate                 105ms                106ms            ! 1.01x slower
3088                     message_one                      260ms                259ms             ^ 1.0x faster
3089                     message_many                     149ms                154ms            ! 1.03x slower
3090                     medium                           194ms                248ms            ! 1.28x slower
3091                     big                              157ms                160ms            ! 1.02x slower
3092
3093                     <geometric mean>                 144ms                163ms            ! 1.13x slower
3094                     <arithmetic mean>                152ms                171ms            ! 1.12x slower
3095                     <harmonic mean>                  137ms                156ms            ! 1.14x slower
3096
3097                 MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks nopatch:~/scratch/Build-nopatch/Release/ patch:~/webkit/WebKitBuild/Release/
3098                                                                                                 
3099                                                                        nopatch                          patch                                     Δ
3100                 Execution Time:
3101                     churn                                                126ms                          148ms                        ! 1.17x slower
3102                     churn --parallel                                      62ms                           76ms                        ! 1.23x slower
3103                     list_allocate                                        130ms                          164ms                        ! 1.26x slower
3104                     list_allocate --parallel                             120ms                          175ms                        ! 1.46x slower
3105                     tree_allocate                                        111ms                          127ms                        ! 1.14x slower
3106                     tree_allocate --parallel                              95ms                          135ms                        ! 1.42x slower
3107                     tree_churn                                           115ms                          124ms                        ! 1.08x slower
3108                     tree_churn --parallel                                107ms                          126ms                        ! 1.18x slower
3109                     facebook                                             240ms                          276ms                        ! 1.15x slower
3110                     facebook --parallel                                  802ms                        1,088ms                        ! 1.36x slower
3111                     fragment                                              92ms                          130ms                        ! 1.41x slower
3112                     fragment --parallel                                   66ms                          124ms                        ! 1.88x slower
3113                     fragment_iterate                                     109ms                          127ms                        ! 1.17x slower
3114                     fragment_iterate --parallel                           55ms                           64ms                        ! 1.16x slower
3115                     message_one                                          260ms                          260ms                                      
3116                     message_many                                         170ms                          238ms                         ! 1.4x slower
3117                     medium                                               185ms                          250ms                        ! 1.35x slower
3118                     medium --parallel                                    210ms                          334ms                        ! 1.59x slower
3119                     big                                                  150ms                          169ms                        ! 1.13x slower
3120                     big --parallel                                       138ms                          144ms                        ! 1.04x slower
3121
3122                     <geometric mean>                                     135ms                          170ms                        ! 1.26x slower
3123                     <arithmetic mean>                                    167ms                          214ms                        ! 1.28x slower
3124                     <harmonic mean>                                      117ms                          148ms                        ! 1.26x slower
3125
3126                 MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks TC:~/scratch/Build-TCMalloc/Release/ patch:~/webkit/WebKitBuild/Release/
3127
3128                                                                     TC                      patch                                Δ
3129                 Peak Memory:
3130                     reddit_memory_warning                     13,836kB                   13,436kB                  ^ 1.03x smaller
3131                     flickr_memory_warning                     24,868kB                   25,188kB                   ! 1.01x bigger
3132                     theverge_memory_warning                   24,504kB                   26,636kB                   ! 1.09x bigger
3133
3134                     <geometric mean>                          20,353kB                   20,812kB                   ! 1.02x bigger
3135                     <arithmetic mean>                         21,069kB                   21,753kB                   ! 1.03x bigger
3136                     <harmonic mean>                           19,570kB                   19,780kB                   ! 1.01x bigger
3137
3138                 Memory at End:
3139                     reddit_memory_warning                      8,656kB                   10,016kB                   ! 1.16x bigger
3140                     flickr_memory_warning                     11,844kB                   13,784kB                   ! 1.16x bigger
3141                     theverge_memory_warning                   18,516kB                   22,748kB                   ! 1.23x bigger
3142
3143                     <geometric mean>                          12,382kB                   14,644kB                   ! 1.18x bigger
3144                     <arithmetic mean>                         13,005kB                   15,516kB                   ! 1.19x bigger
3145                     <harmonic mean>                           11,813kB                   13,867kB                   ! 1.17x bigger
3146
3147                 MallocBench> ~/webkit/PerformanceTests/MallocBench/run-malloc-benchmarks TC:~/scratch/Build-TCMalloc/Release/ patch:~/webkit/WebKitBuild/Release/
3148                                                                                                 
3149                                                         TC                patch                         Δ
3150                 Execution Time:
3151                     churn                            416ms                148ms            ^ 2.81x faster
3152                     list_allocate                    463ms                164ms            ^ 2.82x faster
3153                     tree_allocate                    292ms                127ms             ^ 2.3x faster
3154                     tree_churn                       157ms                120ms            ^ 1.31x faster
3155                     facebook                         327ms                276ms            ^ 1.18x faster
3156                     fragment                         335ms                129ms             ^ 2.6x faster
3157                     fragment_iterate                 344ms                108ms            ^ 3.19x faster
3158                     message_one                      386ms                258ms             ^ 1.5x faster
3159                     message_many                     410ms                154ms            ^ 2.66x faster
3160                     medium                           391ms                245ms             ^ 1.6x faster
3161                     big                              261ms                167ms            ^ 1.56x faster
3162
3163                     <geometric mean>                 332ms                164ms            ^ 2.02x faster
3164                     <arithmetic mean>                344ms                172ms            ^ 1.99x faster
3165                     <harmonic mean>                  317ms                157ms            ^ 2.02x faster
3166
3167         * bmalloc.xcodeproj/project.pbxproj:
3168         * bmalloc/Allocator.cpp:
3169         (bmalloc::Allocator::Allocator): Don't assume that each allocator's
3170         index corresponds with its size. Instead, use the size selection function
3171         explicitly. Now that we have XSmall, some small allocator entries are
3172         unused.
3173
3174         (bmalloc::Allocator::scavenge):
3175         (bmalloc::Allocator::log):
3176         (bmalloc::Allocator::processXSmallAllocatorLog):
3177         (bmalloc::Allocator::allocateSlowCase):
3178         * bmalloc/Allocator.h:
3179         (bmalloc::Allocator::xSmallAllocatorFor):
3180         (bmalloc::Allocator::allocateFastCase):
3181         * bmalloc/Chunk.h:
3182         * bmalloc/Deallocator.cpp:
3183         (bmalloc::Deallocator::scavenge):
3184         (bmalloc::Deallocator::processObjectLog):
3185         (bmalloc::Deallocator::deallocateSlowCase):
3186         (bmalloc::Deallocator::deallocateXSmallLine):
3187         (bmalloc::Deallocator::allocateXSmallLine):
3188         * bmalloc/Deallocator.h:
3189         (bmalloc::Deallocator::deallocateFastCase):
3190         * bmalloc/Heap.cpp:
3191         (bmalloc::Heap::scavenge):
3192         (bmalloc::Heap::scavengeXSmallPages):
3193         (bmalloc::Heap::allocateXSmallLineSlowCase):
3194         * bmalloc/Heap.h:
3195         (bmalloc::Heap::deallocateXSmallLine):
3196         (bmalloc::Heap::allocateXSmallLine):
3197         * bmalloc/LargeChunk.h:
3198         (bmalloc::LargeChunk::get):
3199         (bmalloc::LargeChunk::endTag):
3200         * bmalloc/Line.h:
3201         * bmalloc/MediumAllocator.h:
3202         (bmalloc::MediumAllocator::allocate):
3203         (bmalloc::MediumAllocator::refill):
3204         * bmalloc/ObjectType.cpp:
3205         (bmalloc::objectType):
3206         * bmalloc/ObjectType.h:
3207         (bmalloc::isXSmall):
3208         (bmalloc::isSmall):
3209         (bmalloc::isMedium):
3210         (bmalloc::isLarge):
3211         (bmalloc::isSmallOrMedium): Deleted.
3212         * bmalloc/SegregatedFreeList.h: I boiler-plate copied existing code for
3213         handling small objects. There's probably a reasonable way to share this
3214         code in the future -- I'll look into that once it's stopped changing.
3215
3216         * bmalloc/Sizes.h: Tweaked size classes to make Membuster happy. This
3217         is the main reason things got slower.
3218
3219         * bmalloc/SmallAllocator.h:
3220         (bmalloc::SmallAllocator::allocate):
3221         * bmalloc/SmallTraits.h:
3222         * bmalloc/VMHeap.cpp:
3223         (bmalloc::VMHeap::allocateXSmallChunk):
3224         * bmalloc/VMHeap.h:
3225         (bmalloc::VMHeap::allocateXSmallPage):
3226         (bmalloc::VMHeap::deallocateXSmallPage):
3227         * bmalloc/XSmallAllocator.h: Added.
3228         (bmalloc::XSmallAllocator::isNull):
3229         (bmalloc::XSmallAllocator::canAllocate):
3230         (bmalloc::XSmallAllocator::XSmallAllocator):
3231         (bmalloc::XSmallAllocator::line):
3232         (bmalloc::XSmallAllocator::allocate):
3233         (bmalloc::XSmallAllocator::objectCount):
3234         (bmalloc::XSmallAllocator::derefCount):
3235         (bmalloc::XSmallAllocator::refill):
3236         * bmalloc/XSmallChunk.h: Added.
3237         * bmalloc/XSmallLine.h: Added.
3238         * bmalloc/XSmallPage.h: Added.
3239         * bmalloc/XSmallTraits.h: Added.
3240         * bmalloc/bmalloc.h:
3241         (bmalloc::api::realloc): Boiler-plate copy, as above.
3242
3243 2014-04-14  Geoffrey Garen  <ggaren@apple.com>
3244
3245         MallocBench should scavenge explicitly instead of waiting
3246         https://bugs.webkit.org/show_bug.cgi?id=131661
3247
3248         Reviewed by Andreas Kling.
3249
3250         Added explicit scavenge support to bmalloc. This isn't a memory win,
3251         since bmalloc's per-thread cache is so small. But it makes testing
3252         simpler.
3253
3254         * bmalloc/Allocator.cpp:
3255         (bmalloc::Allocator::~Allocator):
3256         (bmalloc::Allocator::scavenge):
3257         * bmalloc/Allocator.h:
3258         * bmalloc/Cache.cpp:
3259         (bmalloc::Cache::operator new):
3260         (bmalloc::Cache::operator delete):
3261         (bmalloc::Cache::Cache):
3262         (bmalloc::Cache::scavenge):
3263         * bmalloc/Cache.h:
3264         * bmalloc/Deallocator.cpp:
3265         (bmalloc::Deallocator::~Deallocator):
3266         (bmalloc::Deallocator::scavenge):
3267         * bmalloc/Deallocator.h: Factored existing scavenging code into helper
3268         functions, for reuse.
3269
3270         * bmalloc/Heap.cpp:
3271         (bmalloc::sleep):
3272         (bmalloc::Heap::concurrentScavenge):
3273         (bmalloc::Heap::scavenge):
3274         (bmalloc::Heap::scavengeSmallPages):
3275         (bmalloc::Heap::scavengeMediumPages):
3276         (bmalloc::Heap::scavengeLargeRanges):
3277         * bmalloc/Heap.h: Made scavenge sleep duration a parameter. Forced
3278         scavenging -- in response to a benchmark or a low memory warning --
3279         wants to complete as soon as possible, so its sleep duration is 0.
3280
3281         * bmalloc/bmalloc.h:
3282         (bmalloc::api::scavenge):
3283         * bmalloc/mbmalloc.cpp: Exported the scavenge API for MallocBench's use.
3284
3285 2014-04-14  Geoffrey Garen  <ggaren@apple.com>
3286
3287         Use 4kB pages on Mac
3288         https://bugs.webkit.org/show_bug.cgi?id=131658
3289
3290         Reviewed by Sam Weinig.
3291
3292         This reduces memory use a lot on Membuster:
3293
3294                                                                   base                      patch                                Δ
3295                 Execution Time:
3296                     reddit_memory_warning                         18ms                       17ms                   ^ 1.06x faster
3297                     flickr_memory_warning                         34ms                       36ms                   ! 1.06x slower
3298                     theverge_memory_warning                       39ms                       41ms                   ! 1.05x slower
3299
3300                     <geometric mean>                              29ms                       29ms                   ! 1.02x slower
3301                     <arithmetic mean>                             30ms                       31ms                   ! 1.03x slower
3302                     <harmonic mean>                               27ms                       27ms                    ^ 1.0x faster
3303
3304                 Peak Memory:
3305                     reddit_memory_warning                     16,412kB                   16,436kB                    ! 1.0x bigger
3306                     flickr_memory_warning                     30,120kB                   30,184kB                    ! 1.0x bigger
3307                     theverge_memory_warning                   33,408kB                   33,420kB                    ! 1.0x bigger
3308
3309                     <geometric mean>                          25,466kB                   25,499kB                    ! 1.0x bigger
3310                     <arithmetic mean>                         26,647kB                   26,680kB                    ! 1.0x bigger
3311                     <harmonic mean>                           24,181kB                   24,214kB                    ! 1.0x bigger
3312
3313                 Memory at End:
3314                     reddit_memory_warning                      2,404kB                    1,920kB                  ^ 1.25x smaller
3315                     flickr_memory_warning                      3,764kB                    3,072kB                  ^ 1.23x smaller
3316                     theverge_memory_warning                    3,648kB                    3,132kB                  ^ 1.16x smaller
3317
3318                     <geometric mean>                           3,208kB                    2,644kB                  ^ 1.21x smaller
3319                     <arithmetic mean>                          3,272kB                    2,708kB                  ^ 1.21x smaller
3320                     <harmonic mean>                            3,139kB                    2,574kB                  ^ 1.22x smaller
3321
3322
3323         * bmalloc.xcodeproj/project.pbxproj:
3324         * bmalloc/BPlatform.h: Added.
3325         * bmalloc/VMAllocate.h: Only use 16kB pages on iOS because the page size
3326         is 4kB on Mac.
3327
3328 2014-04-14  Alexey Proskuryakov  <ap@apple.com>
3329
3330         Fixed svn:ignore on bmalloc.xcodeproj, it had erroneous leading spaces.
3331
3332         * bmalloc.xcodeproj:&n