1da64a742c86014a8af121fd7bc794af1422b009
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2016-07-11  Geoffrey Garen  <ggaren@apple.com>
2
3         Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
4         https://bugs.webkit.org/show_bug.cgi?id=159655
5
6         Reviewed by Sam Weinig.
7
8         It's not entirely clear what was happening in these crashes, but our
9         use of detach() was 100% forward-looking, so we can just remove it for
10         now.
11
12         This patch removes the ability for the scavenger owner to die before
13         the scavenger thread dies (which was unused) and also removes the
14         ability for the scavenger thread to exit (which was used, but we
15         messed up and did thread joining lazily, so we never got any benefit
16         from thread exit.)
17
18         We can add these features back when we need them, and make them work then.
19
20         * bmalloc/AsyncTask.h:
21         (bmalloc::Function>::AsyncTask): We start out in the running state now
22         because we know that starting our thread will run it.
23
24         (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
25
26         (bmalloc::Function>::runSlowCase): I removed the Exited state.
27
28         (bmalloc::Function>::threadRunLoop): I removed the Exited and
29         ExitRequested states.
30
31         * bmalloc/Heap.h:
32
33         * bmalloc/VMHeap.h:
34
35 2016-06-12  David Kilzer  <ddkilzer@apple.com>
36
37         Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
38         <https://webkit.org/b/158660>
39         <rdar://problem/25652686>
40
41         Reviewed by Darin Adler.
42
43         * bmalloc/Logging.cpp: Switch to use
44         BSOFT_LINK_PRIVATE_FRAMEWORK() to link
45         CrashReporterSupport.framework.
46         * bmalloc/darwin/BSoftLinking.h:
47         (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
48         Switch to use /System/Library/PrivateFrameworks/.
49
50 2016-06-11  David Kilzer  <ddkilzer@apple.com>
51
52         Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
53         <http://webkit.org/b/155992>
54
55         Reviewed by Geoff Garen.
56
57         * bmalloc/BAssert.h:
58         (BLOG_ERROR): Add method to always log error messages.
59         (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
60         logging in Debug builds.
61         * bmalloc/BPlatform.h:
62         (BPLATFORM_MAC): Add.
63         (BUSE): Add BUSE() macro.
64         (BATTRIBUTE_PRINTF): Add.
65         (BUSE_OS_LOG): Add.
66         * bmalloc/Logging.cpp:
67         (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
68         stderr.
69         * bmalloc/Logging.h:
70         (bmalloc::reportAssertionFailureWithMessage): Add declaration.
71
72 2016-06-07  Pranjal Jumde  <pjumde@apple.com>
73
74         Prevents integer overflow in Vector.h
75         https://bugs.webkit.org/show_bug.cgi?id=158455
76         <rdar://problem/20235469>
77
78         Reviewed by Mark Lam.
79
80         * bmalloc/Vector.h:
81         (bmalloc::Vector<T>::reallocateBuffer):
82
83 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
84
85         [cmake] Deduplicated bmalloc/Zone.cpp handling.
86         https://bugs.webkit.org/show_bug.cgi?id=158154
87
88         Reviewed by Alex Christensen.
89
90         File bmalloc/Zone.cpp is required on Darwin irrespectively from what
91         port is being built.
92
93         Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
94         unlikely that bmalloc will ever need port-specific customizations (as
95         opposed to OS-specific customizations which should be done in
96         CMakeLists.txt).
97
98         * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
99         * PlatformGTK.cmake: Removed.
100         * PlatformMac.cmake: Removed.
101
102 2016-05-22  Brady Eidson  <beidson@apple.com>
103
104         Move to C++14.
105         https://bugs.webkit.org/show_bug.cgi?id=157948
106
107         Reviewed by Michael Catanzaro.
108
109         * Configurations/Base.xcconfig:
110
111 2016-05-17  Geoffrey Garen  <ggaren@apple.com>
112
113         REGRESSION: JetStream crashes on some iPhones
114         https://bugs.webkit.org/show_bug.cgi?id=157814
115
116         Reviewed by Michael Saboff.
117
118         * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
119
120         Previous justification for 64kB was:
121
122             * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
123             reasonable, since sizes between 16kB and 32kB share page sizes. I went
124             all the way up to 64kB because the GC uses 64kB blocks, and also just
125             for extra padding to ensure that large allocations are indeed rare.
126
127         It turns out that the bump to 64kB substantially increases our memory
128         high water mark on JetStream, leading to jetsam crashes. Also, there
129         doesn't seem to be a practical performance problem to putting objects in
130         the (32kB - 64kB) range in the large allocator.
131
132 2016-05-16  Geoffrey Garen  <ggaren@apple.com>
133
134         REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
135         https://bugs.webkit.org/show_bug.cgi?id=157764
136
137         Reviewed by Gavin Barraclough.
138
139         We need to allow for guard pages and only report unguarded pages to the
140         leaks tool -- otherwise, it will try to remote map our guarded pages,
141         and crash.
142
143         * bmalloc/VMHeap.cpp:
144         (bmalloc::VMHeap::tryAllocateLargeChunk):
145         (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
146         a range instead of a Chunk*, and report the unguarded range.
147
148         This also fixes a separate bug -- very large allocations would not
149         fully participate in pointer scanning because they would only report 2MB
150         (chunkSize) in size. This could cause false-positive leak reports.
151
152         * bmalloc/Zone.cpp:
153         (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
154         Chunk pointers.
155
156         * bmalloc/Zone.h:
157         (bmalloc::Zone::ranges):
158         (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
159         pointers because our VM ranges have variable sizes -- both due to guard
160         pages and due to large allocations.
161
162         (bmalloc::Zone::chunks): Deleted.
163         (bmalloc::Zone::addChunk): Deleted.
164
165 2016-05-10  David Kilzer  <ddkilzer@apple.com>
166
167         bmalloc should automatically disable itself when ThreadSanitizer is used
168         <https://webkit.org/b/157527>
169
170         Reviewed by Michael Catanzaro.
171
172         * bmalloc/Environment.cpp:
173         (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
174         (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
175         support for detecting ThreadSanitizer.
176         (bmalloc::Environment::computeIsBmallocEnabled): Switch from
177         isASanEnabled to isSanitizerEnabled.
178
179 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
180
181         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
182         https://bugs.webkit.org/show_bug.cgi?id=157047
183
184         Reviewed by Filip Pizlo.
185
186         Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
187
188         * bmalloc/Algorithm.h:
189         (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
190         (bmalloc::roundUpToMultipleOfSloppy): Deleted.
191         * bmalloc/VMHeap.cpp:
192         (bmalloc::VMHeap::allocateSmallChunk):
193
194 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
195
196         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
197         https://bugs.webkit.org/show_bug.cgi?id=157047
198
199         Reviewed by Filip Pizlo.
200
201         The previous fix aligned the guard page sizes correctly but forgot to
202         align the guard page start address correctly.
203
204         * bmalloc/Algorithm.h:
205         (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
206         up when not working with a power of two, instead of writing out the
207         math by hand.
208
209         * bmalloc/VMHeap.cpp:
210         (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
211         page start address in addition to its size. Assert at the very end to
212         try to catch more bugs.
213
214 2016-04-27  Geoffrey Garen  <ggaren@apple.com>
215
216         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
217         https://bugs.webkit.org/show_bug.cgi?id=157047
218
219         Reviewed by Darin Adler.
220
221         * bmalloc/Chunk.h:
222         (bmalloc::Chunk::Chunk):
223         (bmalloc::Chunk::get):
224         (bmalloc::Chunk::offset):
225         (bmalloc::Chunk::address):
226         (bmalloc::Object::Object):
227         (bmalloc::Object::address):
228         (bmalloc::Object::line):
229         (bmalloc::Chunk::object): Deleted.
230         (bmalloc::Object::begin): Deleted.
231         * bmalloc/Heap.cpp:
232         (bmalloc::Heap::allocateSmallBumpRangesByObject):
233         * bmalloc/Object.h:
234         (bmalloc::Object::chunk):
235         (bmalloc::Object::offset): Renamed begin() to address() because this is
236         not an iterator.
237
238         * bmalloc/VMHeap.cpp:
239         (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
240         multiple because pageSize might be smaller than vmPageSize, but we
241         think the VM system requires vmPageSize-aligned values.
242
243 2016-04-25  Geoffrey Garen  <ggaren@apple.com>
244
245         bmalloc: vm allocations should plant guard pages
246         https://bugs.webkit.org/show_bug.cgi?id=156937
247
248         Rolling back in r199936 with a fix for the memory regression.
249
250 2016-04-23  Gavin Barraclough  <barraclough@apple.com>
251
252         bmalloc: vm allocations should plant guard pages
253         https://bugs.webkit.org/show_bug.cgi?id=156937
254
255         Rolling out - looks like this is memory regression.
256
257         * bmalloc/Object.h:
258         (bmalloc::Object::operator+):
259         (bmalloc::Object::operator<=):
260         (bmalloc::Object::operator-): Deleted.
261         * bmalloc/VMAllocate.h:
262         (bmalloc::vmDeallocate):
263         (bmalloc::vmRevokePermissions): Deleted.
264         * bmalloc/VMHeap.cpp:
265         (bmalloc::VMHeap::allocateSmallChunk):
266
267 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
268
269         bmalloc: vm allocations should plant guard pages
270         https://bugs.webkit.org/show_bug.cgi?id=156937
271
272         Reviewed by Michael Saboff.
273
274         * bmalloc/Object.h:
275         (bmalloc::Object::operator-): Added a - helper.
276
277         * bmalloc/VMAllocate.h:
278         (bmalloc::vmRevokePermissions): Added a helper to revoke permissions on
279         a VM region. We use this for guard pages.
280
281         * bmalloc/VMHeap.cpp:
282         (bmalloc::VMHeap::allocateSmallChunk): Add guard pages to the start and
283         end of the chunk.
284
285         Note that we don't guard large chunks becuase we need to be able to merge
286         them. Otherwise, we will run out of virtual addresses.
287
288 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
289
290         bmalloc: Constify introspect function pointer table
291         https://bugs.webkit.org/show_bug.cgi?id=156936
292
293         Reviewed by Michael Saboff.
294
295         * bmalloc/Zone.cpp:
296         (bmalloc::Zone::Zone): Declaring this function pointer table const puts
297         it in the read-only section of the binary, providing a little hardening
298         against overwriting the function pointers at runtime. (We have to
299         const_cast when assigning because the API declares a pointer to non-const,
300         but we happen to know it will never try to write through that pointer.
301         This is not my favorite API.)
302
303 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
304
305         bmalloc: fix up overflow checks
306         https://bugs.webkit.org/show_bug.cgi?id=156780
307
308         Reviewed by Mark Lam.
309
310         We used to try to avoid overflow in large object math by setting a very
311         high limit on the largest large object. But that's a bit error-prone
312         since the check is far away from the math that might overflow -- and
313         we were missing some cases.
314
315         This patch removes the limit and instead checks at each math site.
316
317         * bmalloc/Allocator.cpp:
318         (bmalloc::Allocator::tryAllocate):
319         (bmalloc::Allocator::allocate):
320         (bmalloc::Allocator::reallocate):
321         (bmalloc::Allocator::allocateSlowCase): Remove the limit. tryAllocateLarge
322         will check for overflow for us.
323
324         * bmalloc/Chunk.h: This ASSERT was just totally wrong.
325
326         * bmalloc/Heap.cpp:
327         (bmalloc::Heap::tryAllocateLarge): Check for overflow when adding.
328
329         * bmalloc/Sizes.h:
330
331         * bmalloc/VMAllocate.h:
332         (bmalloc::tryVMAllocate): Check for overflow when adding.
333
334         * bmalloc/VMHeap.cpp:
335         (bmalloc::VMHeap::tryAllocateLargeChunk): Check for overflow when adding.
336
337 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
338
339         Unreviewed, try to fix an ASSERT seen on the bots.
340
341         * bmalloc/Heap.cpp:
342         (bmalloc::Heap::tryAllocateLarge): This ASSERT is supposed to be about
343         alignment, not size. Oops.
344
345 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
346
347         bmalloc: Merge the large and xlarge allocators
348         https://bugs.webkit.org/show_bug.cgi?id=156734
349
350         Reviewed by Andreas Kling.
351
352         This give us better defense against worst case memory usage:
353
354                                               Baseline                Patch                    Δ
355             Peak Memory:
356                 nimlang                      198,132kB            181,468kB      ^ 1.09x smaller
357
358         It also eliminates inline metadata for large objects, fixing the
359         regression introduced in r198675, and more:
360
361             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
362
363                                                                   Baseline                          Patch                              Δ
364             Memory at End:
365                 big                                               10,880kB                        3,328kB                ^ 3.27x smaller
366                 facebook                                           3,112kB                        2,868kB                ^ 1.09x smaller
367                 fragment --parallel                                1,848kB                          760kB                ^ 2.43x smaller
368                 fragment_iterate --parallel                        4,908kB                          776kB                ^ 6.32x smaller
369                 big --parallel                                    48,076kB                       11,892kB                ^ 4.04x smaller
370
371         Overall memory use looks OK:
372
373             run-malloc-benchmarks --memory_warning Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
374
375                                                         Baseline                               Patch                                   Δ
376             Memory at End:
377                 <arithmetic mean>                       13,992kB                            13,987kB                      ^ 1.0x smaller
378
379         Overall throughput looks OK:
380
381             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
382
383                                                                   Baseline                          Patch                              Δ
384             Execution Time:
385                 <arithmetic mean>                                    103ms                          104ms                 ! 1.01x slower
386
387         We're a bit slower on the "all-out large allocations on all cores"
388         benchmark, but I think that's an OK price to pay:
389
390                                                                   Baseline                          Patch                              Δ
391             Execution Time:
392                 big --parallel                                       125ms                          136ms                 ! 1.09x slower
393
394         This patch net removes 1.5k lines of code. It turns out that large
395         allocations are rare, and free memory fragments are also rare, so the
396         combination is super rare, and a simple O(n) algorithm that ensures good
397         memory behavior is the best option.
398
399         Fun fact: In practice, the odds that the old code would save memory
400         were *worse* than the odds that it would contain a bug that wasted
401         memory. :)
402
403         * bmalloc.xcodeproj/project.pbxproj:
404
405         * bmalloc/Allocator.cpp:
406         (bmalloc::Allocator::tryAllocate): largeMax is the new xLargeMax since
407         xLargeMax is gone now.
408
409         (bmalloc::Allocator::allocate): I moved the rounding code into allocateLarge,
410         so we don't have to do it here.
411
412         (bmalloc::Allocator::reallocate):
413         (bmalloc::Allocator::allocateSlowCase):
414         (bmalloc::Allocator::allocateXLarge): Deleted. No more XLarge case.
415
416         * bmalloc/Allocator.h:
417
418         * bmalloc/BeginTag.h: Removed.
419         * bmalloc/BoundaryTag.h: Removed.
420
421         * bmalloc/Chunk.h:
422         (bmalloc::ChunkHash::hash): Added a hash function. The best hash function
423         is a unique and monotonically increasing integer, and that's exactly what
424         we typically get from the high bits of a Chunk, since the OS allocates
425         Chunks at unique and increasing addresses.
426         (bmalloc::Chunk::boundaryTags): Deleted.
427         (bmalloc::Chunk::objectType): Deleted.
428         (bmalloc::Chunk::beginTag): Deleted.
429         (bmalloc::Chunk::endTag): Deleted.
430
431         * bmalloc/Deallocator.cpp:
432         (bmalloc::Deallocator::deallocateSlowCase): We no longer know for sure,
433         by looking at its bit pattern, whether a pointer is small or large.
434         Instead, any pointer with large alignment *might* be large, and when
435         we occasionally encounter such an object, we have to consult a hash
436         table in the Heap to find out for sure. This turns out to be just as
437         cheap in practice.
438
439         We don't deallocate large objects on the fast path anymore. We can't,
440         because large objects have out-of-line metadata now.
441
442         (bmalloc::Deallocator::deallocateXLarge): Deleted.
443
444         * bmalloc/Deallocator.h:
445         (bmalloc::Deallocator::deallocateFastCase): See deallocateSlowCase.
446
447         * bmalloc/EndTag.h: Removed.
448         * bmalloc/FreeList.cpp: Removed.
449         * bmalloc/FreeList.h: Removed.
450
451         * bmalloc/Heap.cpp:
452         (bmalloc::Heap::allocateSmallPage): Be sure to track each chunk in
453         the object type map, so we can distinguish small vs large objects.
454
455         (bmalloc::Heap::deallocateSmallLine): No need to check object type
456         because we know object type now by virtue of being on the small object
457         path.
458
459         (bmalloc::Heap::splitAndAllocate): Be sure to track each chunk in
460         the object type map, so we can distinguish small vs large objects. Large
461         objects can split across chunks, so we need to add each large object's
462         chunk as it is allocated.
463
464         (bmalloc::Heap::tryAllocateLarge):
465         (bmalloc::Heap::allocateLarge):
466         (bmalloc::Heap::isLarge):
467         (bmalloc::Heap::largeSize):
468         (bmalloc::Heap::shrinkLarge):
469         (bmalloc::Heap::deallocateLarge): Merged in existing XLarge logic for
470         large objects.
471
472         (bmalloc::Heap::scavengeXLargeObjects): Deleted.
473         (bmalloc::Heap::allocateXLarge): Deleted.
474         (bmalloc::Heap::tryAllocateXLarge): Deleted.
475         (bmalloc::Heap::xLargeSize): Deleted.
476         (bmalloc::Heap::shrinkXLarge): Deleted.
477         (bmalloc::Heap::deallocateXLarge): Deleted.
478
479         * bmalloc/Heap.h:
480         (bmalloc::Heap::LargeObjectHash::hash):
481
482         * bmalloc/LargeObject.h: Removed.
483
484         * bmalloc/Map.h: Added.
485         (bmalloc::Map::size):
486         (bmalloc::Map::capacity):
487         (bmalloc::Map::get):
488         (bmalloc::Map::set):
489         (bmalloc::Map::remove):
490         (bmalloc::Map::shouldGrow):
491         (bmalloc::Map::shouldShrink):
492         (bmalloc::Map::find):
493         (bmalloc::Hash>::rehash): Simple hash table.
494
495         * bmalloc/Object.h:
496
497         * bmalloc/ObjectType.cpp:
498         (bmalloc::objectType):
499         * bmalloc/ObjectType.h:
500         (bmalloc::mightBeLarge): See deallocateSlowCase.
501         (bmalloc::isXLarge): Deleted.
502
503         * bmalloc/SegregatedFreeList.cpp: Removed.
504         * bmalloc/SegregatedFreeList.h: Removed.
505
506         * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
507         reasonable, since sizes between 16kB and 32kB share page sizes. I went
508         all the way up to 64kB because the GC uses 64kB blocks, and also just
509         for extra padding to ensure that large allocations are indeed rare.
510
511         * bmalloc/SortedVector.h: Removed.
512
513         * bmalloc/VMHeap.cpp:
514         (bmalloc::VMHeap::tryAllocateLargeChunk):
515         (bmalloc::VMHeap::allocateSmallChunk):
516         (bmalloc::VMHeap::VMHeap): Deleted.
517         (bmalloc::VMHeap::allocateChunk): Deleted.
518         * bmalloc/VMHeap.h:
519         (bmalloc::VMHeap::deallocateSmallPage):
520         (bmalloc::VMHeap::allocateLargeObject): Deleted.
521         (bmalloc::VMHeap::deallocateLargeObject): Deleted. Nixed all the boundary
522         tag logic since metadata is out of line now.
523
524         * bmalloc/VMState.h: Removed. Instead of an abstract state, we track
525         the precise amount of committed physical pages at the head of a VM
526         range. This allows us to merge aggressively without triggering an madvise
527         storm most of the time.
528
529         * bmalloc/Vector.h:
530         (bmalloc::Vector<T>::Vector):
531         (bmalloc::Vector<T>::insert):
532         (bmalloc::Vector<T>::remove):
533         (bmalloc::Vector<T>::resize): Filled out some missing helpers.
534
535         * bmalloc/XLargeMap.cpp:
536         (bmalloc::XLargeMap::remove):
537         (bmalloc::XLargeMap::add):
538         (bmalloc::XLargeMap::removePhysical):
539         (bmalloc::XLargeMap::takeFree): Deleted.
540         (bmalloc::XLargeMap::addFree): Deleted.
541         (bmalloc::XLargeMap::addAllocated): Deleted.
542         (bmalloc::XLargeMap::getAllocated): Deleted.
543         (bmalloc::XLargeMap::takeAllocated): Deleted.
544         (bmalloc::XLargeMap::shrinkToFit): Deleted.
545         (bmalloc::XLargeMap::takePhysical): Deleted.
546         (bmalloc::XLargeMap::addVirtual): Deleted.
547         * bmalloc/XLargeMap.h:
548         (bmalloc::XLargeMap::Allocation::operator<): Deleted. We don't track
549         object sizes anymore -- just free space. (The Heap tracks object sizes.)
550         We use plain old linear search for free space. (See intro.)
551
552         * bmalloc/XLargeRange.h:
553         (bmalloc::XLargeRange::physicalSize):
554         (bmalloc::XLargeRange::setPhysicalSize):
555         (bmalloc::merge):
556         (bmalloc::XLargeRange::split):
557         (bmalloc::XLargeRange::vmState): Deleted.
558         (bmalloc::XLargeRange::setVMState): Deleted. See VMState.h.
559
560 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
561
562         [CMake] Make FOLDER property INHERITED
563         https://bugs.webkit.org/show_bug.cgi?id=156460
564
565         Reviewed by Brent Fulgham.
566
567         * CMakeLists.txt:
568         Set FOLDER property as a directory property not a target property
569
570 2016-04-08  Geoffrey Garen  <ggaren@apple.com>
571
572         bmalloc: stress_aligned test fails if you increase smallMax
573         https://bugs.webkit.org/show_bug.cgi?id=156414
574
575         Reviewed by Oliver Hunt.
576
577         When size exceeds alignment and is a multiple of alignment and is not
578         a power of two, such as 24kB with 8kB alignment, the small allocator
579         did not always guarantee alignment. Let's fix that.
580
581         * bmalloc/Algorithm.h:
582         (bmalloc::divideRoundingUp): Math is hard.
583
584         * bmalloc/Allocator.cpp:
585         (bmalloc::Allocator::allocate): Align to the page size unconditionally.
586         Even if the page size is not a power of two, it might be a multiple of
587         a power of two, and we want alignment to that smaller power of two to
588         be guaranteed.
589
590 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
591
592         bmalloc: handle aligned allocations on the fast path
593         https://bugs.webkit.org/show_bug.cgi?id=156302
594
595         Reviewed by Michael Saboff.
596
597         This helps keep the JavaScriptCore GC on the fast path, and it also
598         helps avoid fragmentation on our website stress test:
599
600             nimlang                      209,584kB            198,076kB      ^ 1.06x smaller
601
602         * bmalloc/Allocator.cpp:
603         (bmalloc::Allocator::allocate): Because we arrange for power-of-two size
604         classes to allocate at power-of-two alignments, we can allocate any
605         small aligned request on the small path.
606
607         * bmalloc/Chunk.h:
608         (bmalloc::Chunk::bytes):
609         (bmalloc::Chunk::lines):
610         (bmalloc::Chunk::pages):
611         (bmalloc::Chunk::boundaryTags):
612         (bmalloc::Chunk::objectType): Moved some code around to provide better
613         API.
614
615         (bmalloc::Chunk::Chunk): Moved this code to VMHeap.
616
617         (bmalloc::Chunk::offset):
618         (bmalloc::Chunk::object): Use our new bytes() helper function.
619
620         * bmalloc/VMHeap.cpp:
621         (bmalloc::VMHeap::allocateChunk): Moved code here from Chunk.
622
623         (bmalloc::VMHeap::allocateSmallChunk): Ensure that power-of-two page
624         sizes always begin allocation at the same alignment. Power-of-two object
625         sizes always request power-of-two page sizes (since that's the least
626         wasteful option), so if we also ensure that power-of-two page sizes get
627         power-of-two alignment, then everything is aligned for all small objects.
628
629 2016-04-03  Geoffrey Garen  <ggaren@apple.com>
630
631         bmalloc: segregate small and large objects again, and allocate more objects on the small path
632         https://bugs.webkit.org/show_bug.cgi?id=156152
633
634         Reviewed by Sam Weinig.
635
636         Microbenchmark data suggested that it was a good idea for small and large
637         objects to share memory. But r198675 did not improve memory use in
638         full browser benchmarks.
639
640         This patch reverts to segregating small and large objects -- but without
641         going back to doubled VM usage -- in order to capture a few benefits:
642
643         (*) Small pages fragment the large heap. Separating them out saves a lot
644         of memory in our worst case fragmentation recording:
645
646             nimlang                                          276,076kB                      209,636kB                ^ 1.32x smaller
647
648         (*) Small objects are common enough that even their slow paths benefit 
649         from simpler code:
650
651         Execution Time:
652             ...
653             facebook                                             234ms                          216ms                 ^ 1.08x faster
654             reddit                                               114ms                          108ms                 ^ 1.06x faster
655             flickr                                               118ms                          111ms                 ^ 1.06x faster
656             theverge                                             146ms                          140ms                 ^ 1.04x faster
657             ...
658             <arithmetic mean>                                    107ms                          102ms                 ^ 1.04x faster
659
660         (*) We can use less metadata:
661
662         Memory at End:
663             ...
664             list_allocate                                        460kB                          384kB                 ^ 1.2x smaller
665             tree_allocate                                        492kB                          424kB                ^ 1.16x smaller
666             tree_churn                                           480kB                          404kB                ^ 1.19x smaller
667             fragment                                             532kB                          452kB                ^ 1.18x smaller
668             fragment_iterate                                     712kB                          588kB                ^ 1.21x smaller
669             medium                                            15,152kB                       11,796kB                ^ 1.28x smaller
670             big                                               15,044kB                       10,976kB                ^ 1.37x smaller
671             ...
672             <arithmetic mean>                                  7,724kB                        7,190kB                ^ 1.07x smaller
673
674         This patch also takes advantage of our support for varying the page size
675         at runtime by allocating more objects on the small object path:
676
677             medium                                               178ms                          150ms                 ^ 1.19x faster
678
679         Some microbenchmarks report memory use increases from this change -- like
680         they reported memory use decreases from r198675 -- but I'm ignoring them
681         for now because I expect our full browser memory benchmarks to confirm
682         that this patch is fine.
683
684         * bmalloc/BumpAllocator.h:
685         (bmalloc::BumpAllocator::BumpAllocator): Use a full unsigned because we
686         can allocate objects larger than 16kB - 1, and a full unsigned does not
687         make BumpAllocator any larger on 64bit systems.
688
689         * bmalloc/Chunk.h:
690         (bmalloc::Chunk::begin):
691         (bmalloc::Chunk::end):
692         (bmalloc::Chunk::size):
693         (bmalloc::Chunk::objectType): Store ObjectType in the Chunk, since it only
694         varies by Chunk now, and not from page to page within a Chunk. Also,
695         union together small and large object metadata, since we will only use
696         one or the other. This saves memory.
697
698         (bmalloc::Chunk::Chunk): Conditionalize initialization based on object
699         type, since only one kind of metadata or the other can be used at runtime.
700
701         (bmalloc::Object::Object):
702         (bmalloc::Object::begin):
703         (bmalloc::SmallPage::end): Deleted.
704
705         * bmalloc/Heap.cpp:
706         (bmalloc::Heap::Heap):
707         (bmalloc::Heap::initializeLineMetadata): Save a little space, since we
708         know that lines are only 256 bytes long.
709
710         (bmalloc::Heap::initializePageMetadata): Store a dynamic page size for
711         each size class. We used to use only one page size (the system page size)
712         but that limited our ability to allocate objects larger than 1kB on the
713         small object path. Now we can handle any object size we want by storing
714         objects of that size in a custom page size.
715
716         (bmalloc::Heap::concurrentScavenge):
717         (bmalloc::Heap::scavenge):
718         (bmalloc::Heap::scavengeSmallPages): Revert to our old linked list
719         strategy for storing small pages.
720
721         (bmalloc::Heap::splitAndAllocate): Object type is per Chunk now.
722
723         (bmalloc::Heap::allocateLarge): Don't nuke the small page list when
724         allocating a large object because the two don't share memory anymore.
725
726         (bmalloc::Heap::allocateSmallPage): Revert to our old linked list
727         strategy for storing small pages.
728
729         (bmalloc::Heap::deallocateSmallLine): Don't return early in the case
730         where this is the first free object in the page. In the case of large-ish
731         objects, the first free object might also be the last free object,
732         since there's one object per page.
733
734         (bmalloc::Heap::allocateSmallBumpRangesByMetadata): Split out some helper
735         lambdas to make this code clearer.
736
737         (bmalloc::Heap::allocateSmallBumpRangesByObject): Added a fast scan
738         for objects larger than the line size. When multiple objects fit in
739         a single line, it's an optimization to scan a line at a time. But when
740         it's one object per line, or one object per 64 lines, it's better just
741         to scan an object at a time.
742
743         * bmalloc/Heap.h:
744         (bmalloc::Heap::allocateSmallBumpRanges):
745         (bmalloc::Heap::derefSmallLine): Match the changes above.
746
747         * bmalloc/LineMetadata.h: We weren't using all those bits.
748
749         * bmalloc/List.h:
750         (bmalloc::List::remove): Put a removed Node fully back into the default
751         (empty) state it was in before it entered the list. This change is not
752         observable, but it makes things clearer when you're debugging.
753
754         * bmalloc/Object.h:
755         (bmalloc::Object::Object):
756         (bmalloc::Object::chunk):
757         (bmalloc::Object::offset):
758         (bmalloc::Object::operator+):
759         (bmalloc::Object::operator<=): Added some helpers for iterating by object.
760
761         * bmalloc/ObjectType.cpp:
762         (bmalloc::objectType): Updated for API change.
763
764         * bmalloc/Sizes.h:
765         (bmalloc::Sizes::maskObjectSize):
766         (bmalloc::Sizes::objectSize):
767         (bmalloc::Sizes::pageSize): Support more page sizes.
768
769         * bmalloc/SmallPage.h:
770         (bmalloc::SmallPage::SmallPage):
771         (bmalloc::SmallPage::objectType): Deleted.
772         (bmalloc::SmallPage::setObjectType): Deleted.
773         (bmalloc::SmallPage::smallPageCount): Deleted.
774         (bmalloc::SmallPage::setSmallPageCount): Deleted. Object type is per
775         Chunk now, and we can infer page count from size class.
776
777         * bmalloc/VMHeap.cpp:
778         (bmalloc::VMHeap::allocateChunk):
779         (bmalloc::VMHeap::allocateSmallChunk):
780         * bmalloc/VMHeap.h:
781         (bmalloc::VMHeap::allocateSmallPage):
782         (bmalloc::VMHeap::deallocateSmallPage):
783         (bmalloc::VMHeap::allocateLargeObject): Support our old behavior of
784         storing free pages in linked lists.
785
786 2016-03-29  Geoffrey Garen  <ggaren@apple.com>
787
788         bmalloc: support physical page sizes that don't match the virtual page size (take 2)
789         https://bugs.webkit.org/show_bug.cgi?id=156003
790
791         Reviewed by Andreas Kling.
792
793         This is a memory savings on iOS devices where the virtual page size
794         is 16kB but the physical page size is 4kB.
795
796         Take 1 was a memory regression on 16kB virtual / 16kB physical systems
797         because it used a 4kB page size within a 16kB page size, allowing up to
798         4 different object types to mix within a physical page. Because objects
799         of the same type tend to deallocate at the same time, mixing objects of
800         different types made pages less likely to become completely empty.
801
802         (Take 1 also had a bug where it used a platform #ifdef that didn't exist.
803         Oops.)
804
805         Take 2 allocates units of SmallPages equal to the physical page size.
806
807         * bmalloc/Heap.cpp:
808         (bmalloc::Heap::Heap):
809         (bmalloc::Heap::initializeLineMetadata):
810         (bmalloc::Heap::allocateSmallBumpRanges):
811         (bmalloc::Heap::allocateSmallPage):
812         (bmalloc::Heap::allocateLarge):
813         (bmalloc::Heap::splitAndAllocate):
814         (bmalloc::Heap::tryAllocateXLarge):
815         (bmalloc::Heap::shrinkXLarge):
816         * bmalloc/Heap.h: Use the physical page size for our VM operations because
817         we're only concerned with returning physical pages to the OS.
818
819         * bmalloc/VMAllocate.h:
820         (bmalloc::vmPageSize):
821         (bmalloc::vmPageShift):
822         (bmalloc::vmSize):
823         (bmalloc::vmValidate):
824         (bmalloc::vmPageSizePhysical):
825         (bmalloc::vmValidatePhysical):
826         (bmalloc::tryVMAllocate):
827         (bmalloc::vmDeallocatePhysicalPages):
828         (bmalloc::vmAllocatePhysicalPages):
829         (bmalloc::vmDeallocatePhysicalPagesSloppy):
830         (bmalloc::vmAllocatePhysicalPagesSloppy): Use the physical page size.
831
832 2016-03-29  Geoffrey Garen  <ggaren@apple.com>
833
834         bmalloc: page size should be configurable at runtime
835         https://bugs.webkit.org/show_bug.cgi?id=155993
836
837         Reviewed by Andreas Kling.
838
839         This is a memory win on 32bit iOS devices, since their page sizes are
840         4kB and not 16kB.
841
842         It's also a step toward supporting 64bit iOS devices that have a
843         16kB/4kB virtual/physical page size split.
844
845         * bmalloc/Chunk.h: Align to largeAlignment since 2 * smallMax isn't
846         required by the boundary tag allocator.
847
848         (bmalloc::Chunk::page): Account for the slide when accessing a page.
849         Each SmallPage hashes 4kB of memory. When we want to allocate a region
850         of memory larger than 4kB, we store our metadata in the first SmallPage
851         in the region and we assign a slide to the remaining SmallPages, so
852         they forward to that first SmallPage when accessed.
853
854         NOTE: We could use a less flexible technique that just hashed by
855         vmPageSize() instead of 4kB at runtime, with no slide, but I think we'll
856         be able to use this slide technique to make even more page sizes
857         dynamically at runtime, which should save some memory and simplify
858         the allocator.
859
860         (bmalloc::SmallPage::begin): It's invalid to access a SmallPage with
861         a slide, since such SmallPages do not contain meaningful data.
862
863         (bmalloc::SmallPage::end): Account for smallPageCount when computing
864         the size of a page.
865
866         (bmalloc::Chunk::pageBegin): Deleted.
867         (bmalloc::Chunk::pageEnd): Deleted.
868         (bmalloc::Object::pageBegin): Deleted.
869
870         * bmalloc/Heap.cpp:
871         (bmalloc::Heap::Heap): Cache vmPageSize because computing it might require
872         a syscall.
873
874         (bmalloc::Heap::initializeLineMetadata): Line metadata is a vector instead
875         of a 2D array because we don't know how much metadata we'll need until
876         we know the page size.
877
878         (bmalloc::Heap::scavengeSmallPage): Be sure to revert the slide when
879         deallocating a page. Otherwise, the next attempt to allocate the page
880         will slide when initializing it, sliding to nowhere.
881
882         (bmalloc::Heap::allocateSmallBumpRanges): Account for vector change to
883         line metadata.
884
885         (bmalloc::Heap::allocateSmallPage): Initialize slide and smallPageCount
886         since they aren't constant anymore.
887
888         (bmalloc::Heap::allocateLarge):
889         (bmalloc::Heap::splitAndAllocate):
890         (bmalloc::Heap::tryAllocateXLarge):
891         (bmalloc::Heap::shrinkXLarge): Adopt dynamic page size.
892
893         * bmalloc/Heap.h:
894
895         * bmalloc/Sizes.h: smallPageSize is no longer equal to the VM page
896         size -- it's just the smallest VM page size we're interested in supporting.
897
898         * bmalloc/SmallPage.h:
899         (bmalloc::SmallPage::slide):
900         (bmalloc::SmallPage::setSlide):
901         (bmalloc::SmallPage::smallPageCount):
902         (bmalloc::SmallPage::setSmallPageCount):
903         (bmalloc::SmallPage::ref):
904         (bmalloc::SmallPage::deref): Support slide and small page count as
905         dynamic values. This doesn't increase metadata size since sizeof(SmallPage)
906         rounds up to alignment anyway.
907
908         * bmalloc/VMAllocate.h:
909         (bmalloc::vmPageSize):
910         (bmalloc::vmPageShift):
911         (bmalloc::vmSize):
912         (bmalloc::vmValidate):
913         (bmalloc::tryVMAllocate):
914         (bmalloc::vmDeallocatePhysicalPagesSloppy):
915         (bmalloc::vmAllocatePhysicalPagesSloppy): Treat page size as a variable.
916
917         * bmalloc/Vector.h:
918         (bmalloc::Vector::initialCapacity):
919         (bmalloc::Vector<T>::insert):
920         (bmalloc::Vector<T>::grow):
921         (bmalloc::Vector<T>::shrink):
922         (bmalloc::Vector<T>::shrinkCapacity):
923         (bmalloc::Vector<T>::growCapacity): Treat page size as a variable.
924
925 2016-03-29  David Kilzer  <ddkilzer@apple.com>
926
927         bmalloc: add logging for mmap() failures
928         <http://webkit.org/b/155409>
929         <rdar://problem/24568515>
930
931         Reviewed by Saam Barati.
932
933         This patch causes additional logging to be generated on internal
934         iOS builds when mmap() fails.  We are trying to track down an
935         issue where the WebContent process runs out of VM address space
936         before it is killed by jetsam.
937
938         * CMakeLists.txt: Add Logging.cpp.
939         * bmalloc.xcodeproj/project.pbxproj: Add new files.
940
941         * bmalloc/BAssert.h:
942         (RELEASE_BASSERT_WITH_MESSAGE): Add macro.
943         * bmalloc/Logging.cpp: Added.
944         (bmalloc::logVMFailure): Implementation.
945         * bmalloc/Logging.h: Added.
946         (bmalloc::logVMFailure): Declaration.
947         * bmalloc/VMAllocate.h:
948         (bmalloc::tryVMAllocate): Call logVMFailure() on mmap() failure.
949         * bmalloc/darwin/BSoftLinking.h: Copied from Source/WebCore/platform/mac/SoftLinking.h.
950
951 2016-03-26  Geoffrey Garen  <ggaren@apple.com>
952
953         Unreviewed, rolling out r198702, r198704.
954
955         Caused a memory regression on PLUM.
956
957         Reverted changeset:
958
959         bmalloc: fix an ASSERT on iOS
960         https://bugs.webkit.org/show_bug.cgi?id=155911
961         http://trac.webkit.org/changeset/198704
962
963         bmalloc: support physical page sizes that don't match the virtual page size
964         https://bugs.webkit.org/show_bug.cgi?id=155898
965         http://trac.webkit.org/changeset/198702
966
967 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
968
969         bmalloc: fix an ASSERT on iOS
970         https://bugs.webkit.org/show_bug.cgi?id=155911
971
972         Reviewed by Gavin Barraclough.
973
974         * bmalloc/VMAllocate.h:
975         (bmalloc::vmValidatePhysical): Call through to vmValidatePhysical because
976         the vmValidate function validates virtual sizes rather than physical
977         sizes.
978
979 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
980
981         bmalloc: support physical page sizes that don't match the virtual page size
982         https://bugs.webkit.org/show_bug.cgi?id=155898
983
984         Reviewed by Gavin Barraclough.
985
986         This is a memory savings on iOS devices where the virtual page size
987         is 16kB but the physical page size is 4kB.
988
989         * bmalloc/Chunk.h:
990         (bmalloc::Chunk::Chunk): smallPageSize is now unrelated to the OS's
991         page size -- it just reflects the optimal unit of memory to recycle
992         between small objects.
993
994         We only need to round up to largeAlignment because small objects allocate
995         as subsets of large objects now.
996
997         (bmalloc::Chunk::page):
998         (bmalloc::Object::pageBegin):
999         (bmalloc::Object::line): Adopt smallPageSize.
1000
1001         * bmalloc/Heap.cpp:
1002         (bmalloc::Heap::initializeLineMetadata):
1003         (bmalloc::Heap::allocateSmallPage):
1004         (bmalloc::Heap::allocateLarge): Adopt smallPageSize.
1005
1006         (bmalloc::Heap::splitAndAllocate):
1007         (bmalloc::Heap::tryAllocateXLarge):
1008         (bmalloc::Heap::shrinkXLarge): Adopt vmPageSizePhysical(). We want the
1009         physical page size because that's the unit at which the hardware MMU
1010         will recycle memory.
1011
1012         * bmalloc/Sizes.h: Adopt smallPageSize.
1013
1014         * bmalloc/VMAllocate.h:
1015         (bmalloc::vmPageSizePhysical):
1016         (bmalloc::vmPageSize): Distinguish between page size, which is the virtual
1017         memory page size advertised by the OS, and physical page size, which the
1018         true hardware page size.
1019
1020         (bmalloc::vmSize):
1021         (bmalloc::vmValidate):
1022         (bmalloc::vmValidatePhysical):
1023         (bmalloc::tryVMAllocate):
1024         (bmalloc::vmDeallocatePhysicalPages):
1025         (bmalloc::vmAllocatePhysicalPages):
1026         (bmalloc::vmDeallocatePhysicalPagesSloppy):
1027         (bmalloc::vmAllocatePhysicalPagesSloppy): Adopt vmPageSize() and
1028         vmPageSizePhyiscal().
1029
1030         * bmalloc/Vector.h:
1031         (bmalloc::Vector::initialCapacity):
1032         (bmalloc::Vector<T>::shrink):
1033         (bmalloc::Vector<T>::shrinkCapacity):
1034         (bmalloc::Vector<T>::growCapacity): Adopt vmPageSize(). We'd prefer to
1035         use vmPageSizePhysical() but mmap() doesn't support it.
1036
1037         * bmalloc/XLargeMap.cpp: #include.
1038
1039 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
1040
1041         Unreviewed, rolling in r198679.
1042
1043         r198679 was just a rename. The regression was caused by r198675 and then
1044         fixed in r198693.
1045
1046         Restored changeset:
1047
1048         "bmalloc: Renamed LargeChunk => Chunk"
1049         https://bugs.webkit.org/show_bug.cgi?id=155894
1050         http://trac.webkit.org/changeset/198679
1051
1052 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
1053
1054         Unreviewed, try to fix a crash seen on the bots.
1055
1056         * bmalloc/Allocator.cpp:
1057         (bmalloc::Allocator::reallocate): We have to take the lock even if we're
1058         only reading our own data becuse LargeObject contains validation code
1059         that will read our neighbors' data as well.
1060
1061 2016-03-25  Ryan Haddad  <ryanhaddad@apple.com>
1062
1063         Unreviewed, rolling out r198679.
1064
1065         This change caused flaky LayoutTest crashes
1066
1067         Reverted changeset:
1068
1069         "bmalloc: Renamed LargeChunk => Chunk"
1070         https://bugs.webkit.org/show_bug.cgi?id=155894
1071         http://trac.webkit.org/changeset/198679
1072
1073 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
1074
1075         bmalloc: stress_aligned fails when allocating a zero-sized object with XLarge alignment
1076         https://bugs.webkit.org/show_bug.cgi?id=155896
1077
1078         Reviewed by Andreas Kling.
1079
1080         We normally filter zero-sized allocations into small allocations, but
1081         a zero-sized allocation can sneak through if it requires sufficiently
1082         large alignment.
1083
1084         * bmalloc/Heap.cpp:
1085         (bmalloc::Heap::tryAllocateXLarge): Set a floor on allocation size to
1086         catch zero-sized allocations.
1087
1088 2016-03-25  Geoffrey Garen  <ggaren@apple.com>
1089
1090         bmalloc: Renamed LargeChunk => Chunk
1091         https://bugs.webkit.org/show_bug.cgi?id=155894
1092
1093         Reviewed by Michael Saboff.
1094
1095         A Chunk can contain both small and large objects now.
1096
1097         * bmalloc.xcodeproj/project.pbxproj:
1098         * bmalloc/Allocator.cpp:
1099         (bmalloc::Allocator::allocate):
1100         * bmalloc/BoundaryTag.h:
1101         (bmalloc::BoundaryTag::isFree):
1102         * bmalloc/Chunk.h: Copied from Source/bmalloc/bmalloc/LargeChunk.h.
1103         (bmalloc::Chunk::pages):
1104         (bmalloc::Chunk::begin):
1105         (bmalloc::Chunk::end):
1106         (bmalloc::Chunk::Chunk):
1107         (bmalloc::Chunk::get):
1108         (bmalloc::Chunk::beginTag):
1109         (bmalloc::Chunk::endTag):
1110         (bmalloc::Chunk::offset):
1111         (bmalloc::Chunk::object):
1112         (bmalloc::Chunk::page):
1113         (bmalloc::Chunk::line):
1114         (bmalloc::SmallLine::begin):
1115         (bmalloc::SmallPage::begin):
1116         (bmalloc::SmallPage::end):
1117         (bmalloc::Object::Object):
1118         (bmalloc::Object::begin):
1119         (bmalloc::LargeChunk::pages): Deleted.
1120         (bmalloc::LargeChunk::begin): Deleted.
1121         (bmalloc::LargeChunk::end): Deleted.
1122         (bmalloc::LargeChunk::LargeChunk): Deleted.
1123         (bmalloc::LargeChunk::get): Deleted.
1124         (bmalloc::LargeChunk::beginTag): Deleted.
1125         (bmalloc::LargeChunk::endTag): Deleted.
1126         (bmalloc::LargeChunk::offset): Deleted.
1127         (bmalloc::LargeChunk::object): Deleted.
1128         (bmalloc::LargeChunk::page): Deleted.
1129         (bmalloc::LargeChunk::line): Deleted.
1130         * bmalloc/Deallocator.cpp:
1131         * bmalloc/FreeList.cpp:
1132         * bmalloc/Heap.cpp:
1133         (bmalloc::Heap::allocateLarge):
1134         * bmalloc/LargeChunk.h: Removed.
1135         * bmalloc/LargeObject.h:
1136         (bmalloc::LargeObject::LargeObject):
1137         (bmalloc::LargeObject::merge):
1138         (bmalloc::LargeObject::split):
1139         * bmalloc/Object.h:
1140         (bmalloc::Object::chunk):
1141         * bmalloc/ObjectType.cpp:
1142         * bmalloc/Sizes.h:
1143         * bmalloc/SmallAllocator.h: Removed.
1144         * bmalloc/VMHeap.cpp:
1145         (bmalloc::VMHeap::VMHeap):
1146         (bmalloc::VMHeap::allocateChunk):
1147         (bmalloc::VMHeap::allocateLargeChunk): Deleted.
1148         * bmalloc/VMHeap.h:
1149         (bmalloc::VMHeap::allocateLargeObject):
1150         (bmalloc::VMHeap::deallocateLargeObject):
1151         * bmalloc/Zone.cpp:
1152         (bmalloc::enumerator):
1153         * bmalloc/Zone.h:
1154         (bmalloc::Zone::chunks):
1155         (bmalloc::Zone::addChunk):
1156         (bmalloc::Zone::largeChunks): Deleted.
1157         (bmalloc::Zone::addLargeChunk): Deleted.
1158
1159 2016-03-24  Geoffrey Garen  <ggaren@apple.com>
1160
1161         bmalloc: small and large objects should share memory
1162         https://bugs.webkit.org/show_bug.cgi?id=155866
1163
1164         Reviewed by Andreas Kling.
1165
1166         This patch cuts our VM footprint in half. (VM footprint usually doesn't
1167         matter, but on iOS there's an artificial VM limit around 700MB, and if
1168         you hit it you jetsam / crash.)
1169
1170         It's also a step toward honoring the hardware page size at runtime,
1171         which will reduce memory usage on iOS.
1172
1173         This patch is a small improvement in peak memory usage because it allows
1174         small and large objects to recycle each other's memory. The tradeoff is
1175         that we require more metadata, which causes more memory usage after
1176         shrinking down from peak memory usage. In the end, we have some memory
1177         wins and some losses, and a small win in the mean on our standard memory
1178         benchmarks.
1179
1180         * bmalloc.xcodeproj/project.pbxproj: Removed SuperChunk.
1181
1182         * bmalloc/Allocator.cpp:
1183         (bmalloc::Allocator::reallocate): Adopt a new Heap API for shrinking
1184         large objects because it's a little more complicated than it used to be.
1185
1186         Don't check for equality in the XLarge case because we don't do it in
1187         other cases, and it's unlikely that we'll be called for no reason.
1188
1189         * bmalloc/BumpAllocator.h:
1190         (bmalloc::BumpAllocator::allocate): Don't ASSERT isSmall because that's
1191         an old concept from when small and large objects were in distinct memory
1192         regions.
1193
1194         * bmalloc/Deallocator.cpp:
1195         (bmalloc::Deallocator::deallocateSlowCase): Large objects are not
1196         segregated anymore.
1197
1198         (bmalloc::Deallocator::deallocateLarge): Deleted.
1199
1200         * bmalloc/Deallocator.h:
1201         (bmalloc::Deallocator::deallocateFastCase): Don't ASSERT isSmall(). See
1202         above.
1203
1204         * bmalloc/Heap.cpp:
1205         (bmalloc::Heap::scavenge):
1206         (bmalloc::Heap::scavengeSmallPage):
1207         (bmalloc::Heap::scavengeSmallPages): New helpers for returning cached
1208         small pages to the large object heap.
1209
1210         (bmalloc::Heap::allocateSmallPage): Allocate small pages from the large
1211         object heap. This is how we accomplish sharing.
1212
1213         (bmalloc::Heap::deallocateSmallLine): Handle large objects since we can
1214         encounter them on this code path now.
1215
1216         (bmalloc::Heap::splitAndAllocate): Fixed a bug where we would sometimes
1217         not split even though we could.
1218
1219         Allocating a large object also requires ref'ing its small line so that
1220         we can alias memory between small and large objects.
1221
1222         (bmalloc::Heap::allocateLarge): Return cached small pages before
1223         allocating a large object that would fit in a cached small page. This
1224         allows some large allocations to reuse small object memory.
1225
1226         (bmalloc::Heap::shrinkLarge): New helper.
1227
1228         (bmalloc::Heap::deallocateLarge): Deleted.
1229
1230         * bmalloc/Heap.h:
1231
1232         * bmalloc/LargeChunk.h:
1233         (bmalloc::LargeChunk::pageBegin):
1234         (bmalloc::LargeChunk::pageEnd):
1235         (bmalloc::LargeChunk::lines):
1236         (bmalloc::LargeChunk::pages):
1237         (bmalloc::LargeChunk::begin):
1238         (bmalloc::LargeChunk::end):
1239         (bmalloc::LargeChunk::LargeChunk):
1240         (bmalloc::LargeChunk::get):
1241         (bmalloc::LargeChunk::endTag):
1242         (bmalloc::LargeChunk::offset):
1243         (bmalloc::LargeChunk::object):
1244         (bmalloc::LargeChunk::page):
1245         (bmalloc::LargeChunk::line):
1246         (bmalloc::SmallLine::begin):
1247         (bmalloc::SmallLine::end):
1248         (bmalloc::SmallPage::begin):
1249         (bmalloc::SmallPage::end):
1250         (bmalloc::Object::Object):
1251         (bmalloc::Object::begin):
1252         (bmalloc::Object::pageBegin):
1253         (bmalloc::Object::line):
1254         (bmalloc::Object::page): I merged all the SmallChunk metadata and code
1255         into LargeChunk. Now we use a single class to track both small and large
1256         metadata, so we can share memory between small and large objects.
1257
1258         I'm going to rename this class to Chunk in a follow-up patch.
1259
1260         * bmalloc/Object.h:
1261         (bmalloc::Object::chunk): Updated for LargeChunk transition.
1262
1263         * bmalloc/ObjectType.cpp:
1264         (bmalloc::objectType):
1265         * bmalloc/ObjectType.h:
1266         (bmalloc::isXLarge):
1267         (bmalloc::isSmall): Deleted. The difference between small and large
1268         objects is now stored in metadata and is not a property of their
1269         virtual address range.
1270
1271         * bmalloc/SegregatedFreeList.h: One more entry because we cover all of
1272         what used to be the super chunk in a large chunk now.
1273
1274         * bmalloc/Sizes.h: Removed bit masking helpers because we don't use
1275         address masks to distinguish small vs large object type anymore.
1276
1277         * bmalloc/SmallChunk.h: Removed.
1278
1279         * bmalloc/SmallPage.h:
1280         (bmalloc::SmallPage::SmallPage): Store object type per page because any
1281         given page can be used for large objects or small objects.
1282
1283         * bmalloc/SuperChunk.h: Removed.
1284
1285         * bmalloc/VMHeap.cpp:
1286         (bmalloc::VMHeap::VMHeap):
1287         (bmalloc::VMHeap::allocateLargeChunk):
1288         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
1289         (bmalloc::VMHeap::allocateSuperChunk): Deleted.
1290         * bmalloc/VMHeap.h:
1291         (bmalloc::VMHeap::allocateLargeObject):
1292         (bmalloc::VMHeap::deallocateLargeObject):
1293         (bmalloc::VMHeap::allocateSmallPage): Deleted.
1294         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Removed super chunk and
1295         small chunk support.
1296
1297         * bmalloc/Zone.cpp:
1298         (bmalloc::enumerator):
1299         * bmalloc/Zone.h:
1300         (bmalloc::Zone::largeChunks):
1301         (bmalloc::Zone::addLargeChunk):
1302         (bmalloc::Zone::superChunks): Deleted.
1303         (bmalloc::Zone::addSuperChunk): Deleted. Removed super chunk and
1304         small chunk support.
1305
1306 2016-03-23  Geoffrey Garen  <ggaren@apple.com>
1307
1308         bmalloc: Added an Object helper class
1309         https://bugs.webkit.org/show_bug.cgi?id=155818
1310
1311         Reviewed by Gavin Barraclough.
1312
1313         Object is an abstraction that breaks out a void* into its component
1314         metadata pointers.
1315
1316         This is slightly faster than recomputing them, and it enables a future
1317         patch in which Object will tell us whether it is small or large.
1318
1319         * bmalloc.xcodeproj/project.pbxproj: Added to the project.
1320
1321         * bmalloc/Allocator.cpp:
1322         (bmalloc::Allocator::reallocate): Use Object to compute size.
1323
1324         * bmalloc/Deallocator.cpp:
1325         (bmalloc::Deallocator::processObjectLog):
1326         * bmalloc/Heap.cpp:
1327         (bmalloc::Heap::allocateSmallPage):
1328         (bmalloc::Heap::deallocateSmallLine):
1329         * bmalloc/Heap.h:
1330         (bmalloc::Heap::derefSmallLine): Use Object to deallocate.
1331
1332         * bmalloc/Object.h: Added.
1333         (bmalloc::Object::Object):
1334         (bmalloc::Object::chunk):
1335         (bmalloc::Object::line):
1336         (bmalloc::Object::page): Helper class to break out a void* into its
1337         component metadata pointers.
1338
1339         * bmalloc/SmallChunk.h:
1340         (bmalloc::SmallChunk::SmallChunk): SmallPage::get doesn't exist anymore
1341         so we use our new helper functions instead.
1342
1343         (bmalloc::SmallChunk::offset):
1344         (bmalloc::SmallChunk::object):
1345         (bmalloc::SmallChunk::page):
1346         (bmalloc::SmallChunk::line):
1347         (bmalloc::SmallLine::begin):
1348         (bmalloc::SmallLine::end):
1349         (bmalloc::SmallPage::begin): New helpers that operate on the data
1350         stored in Object.
1351
1352         (bmalloc::SmallLine::get): Deleted.
1353         (bmalloc::SmallPage::get): Deleted.
1354
1355         * bmalloc/SmallLine.h:
1356         (bmalloc::SmallLine::refCount): Added a default ref value for convenience.
1357
1358         * bmalloc/SmallPage.h:
1359         (bmalloc::SmallPage::SmallPage):
1360
1361 2016-03-23  Geoffrey Garen  <ggaren@apple.com>
1362
1363         bmalloc: process the object log before asking for new memory
1364         https://bugs.webkit.org/show_bug.cgi?id=155801
1365
1366         Reviewed by Gavin Barraclough.
1367
1368         This is a step toward merging large and small objects: In future, if we
1369         have large objects in the log, we need to process them right away to
1370         avoid pushing up peak memory use.
1371
1372         But it also appears to be a speedup and memory use improvement now.
1373
1374         * bmalloc/Allocator.cpp:
1375         (bmalloc::Allocator::allocate):
1376         (bmalloc::Allocator::refillAllocatorSlowCase):
1377         (bmalloc::Allocator::allocateLarge): Process the log before asking for
1378         more memory.
1379
1380         * bmalloc/Deallocator.cpp:
1381         (bmalloc::Deallocator::processObjectLog):
1382         (bmalloc::Deallocator::deallocateSlowCase):
1383         * bmalloc/Deallocator.h: Provide a public API for processing the object log.
1384
1385         * bmalloc/Heap.cpp:
1386         (bmalloc::Heap::allocateSmallPage): Pop fragmented pages from the front
1387         instead of from the back. This resolves a regression on tree_churn
1388         --parallel. Popping from the front gives us the oldest pages. The oldest
1389         pages have had the most time to accumulate free lines. They are therefore
1390         the least fragmented on average.
1391
1392         * bmalloc/List.h:
1393         (bmalloc::List::popFront):
1394         (bmalloc::List::insertAfter): New API to pop from front.
1395
1396 2016-03-22  Geoffrey Garen  <ggaren@apple.com>
1397
1398         bmalloc: use a log scale for large-ish size classes
1399         https://bugs.webkit.org/show_bug.cgi?id=155770
1400
1401         Reviewed by Michael Saboff.
1402
1403         At larger sizes, precise allocation sizes don't save much memory -- and
1404         they can cost memory when objects of distinct size classes can't
1405         allocate together.
1406
1407         This is a small savings up to our current allocation limits, and it may
1408         enable changing those limits in the long term.
1409
1410         * bmalloc/Algorithm.h:
1411         (bmalloc::log2): We use this to compute large-ish size classes.
1412
1413         * bmalloc/Allocator.cpp:
1414         (bmalloc::Allocator::Allocator): Iterate by size class instead of by
1415         object size so we can change object size limits without breaking stuff.
1416
1417         (bmalloc::Allocator::scavenge): Ditto.
1418
1419         (bmalloc::Allocator::allocateLogSizeClass): New helper function for
1420         allocating based on log size classes.
1421
1422         (bmalloc::Allocator::allocateSlowCase): Account for extra size class
1423         possibilities.
1424
1425         * bmalloc/Allocator.h:
1426         (bmalloc::Allocator::allocateFastCase): We only handle up to 512b on
1427         the fastest fast path now.
1428
1429         * bmalloc/BumpAllocator.h:
1430         (bmalloc::BumpAllocator::validate): Deleted. I noticed that this function
1431         had been refactored not to do anything anymore.
1432
1433         * bmalloc/Heap.cpp:
1434         (bmalloc::Heap::initializeLineMetadata): Iterate by size class. (See
1435         Allocator::Allocator.)
1436
1437         * bmalloc/Heap.h: Use the sizeClassCount constant instead of hard coding
1438         things.
1439
1440         * bmalloc/Sizes.h:
1441         (bmalloc::Sizes::maskSizeClass):
1442         (bmalloc::Sizes::maskObjectSize):
1443         (bmalloc::Sizes::logSizeClass):
1444         (bmalloc::Sizes::logObjectSize):
1445         (bmalloc::Sizes::sizeClass):
1446         (bmalloc::Sizes::objectSize): Separate size class calculation between
1447         simple size classes that can be computed with a mask and are 8-byte-precise
1448         and complex size classes that require more math and are less precise.
1449
1450         * bmalloc/SmallLine.h:
1451         (bmalloc::SmallLine::ref):
1452         * bmalloc/SmallPage.h:
1453         (bmalloc::SmallPage::SmallPage):
1454         (bmalloc::SmallPage::ref):
1455         (bmalloc::SmallPage::deref): Cleaned up some ASSERTs that triggered
1456         while working on this patch.
1457
1458         * bmalloc/Zone.cpp:
1459         (bmalloc::statistics):
1460         (bmalloc::zoneSize):
1461         (bmalloc::Zone::Zone):
1462         (bmalloc::size): Deleted. Renamed these symbols to work around an lldb
1463         bug that makes it impossible to print out variables named 'size' -- which
1464         can be a problem when working on malloc.
1465
1466 2016-03-22  Geoffrey Garen  <ggaren@apple.com>
1467
1468         bmalloc: shrink largeMax
1469         https://bugs.webkit.org/show_bug.cgi?id=155759
1470
1471         Reviewed by Michael Saboff.
1472
1473         If a largeChunk contains N bytes and we allocate objects of size
1474         N / 2 + 8 bytes, then we waste 50% of physical memory at peak.
1475
1476         This patch sets largeMax to N / 2, reducing maximum waste to 25%.
1477
1478         * bmalloc/BoundaryTag.h:
1479         * bmalloc/LargeChunk.h:
1480         (bmalloc::LargeChunk::LargeChunk):
1481         * bmalloc/SegregatedFreeList.cpp:
1482         (bmalloc::SegregatedFreeList::SegregatedFreeList):
1483         (bmalloc::SegregatedFreeList::insert): Honor largeMax vs largeObjectMax.
1484
1485         * bmalloc/Sizes.h: Distinguish between the largest thing we can store
1486         in a free list (largeObjectMax) and the largest thing we're willing to
1487         allocate (largeMax).
1488
1489 2016-03-20  Dan Bernstein  <mitz@apple.com>
1490
1491         [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
1492         https://bugs.webkit.org/show_bug.cgi?id=155707
1493         <rdar://problem/24980691>
1494
1495         Reviewed by Darin Adler.
1496
1497         * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
1498           component of MACOSX_DEPLOYMENT_TARGET.
1499         * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
1500           TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.
1501
1502 2016-03-20  Dan Bernstein  <mitz@apple.com>
1503
1504         Update build settings
1505
1506         Rubber-stamped by Andy Estes.
1507
1508         * Configurations/DebugRelease.xcconfig:
1509
1510 2016-03-14  Geoffrey Garen  <ggaren@apple.com>
1511
1512         Unreviewed, rolling out r197955.
1513
1514         I decided to go in another direction
1515
1516         Reverted changeset:
1517
1518         "bmalloc: Rename SmallPage to SmallRun"
1519         https://bugs.webkit.org/show_bug.cgi?id=155320
1520         http://trac.webkit.org/changeset/197955
1521
1522 2016-03-10  Geoffrey Garen  <ggaren@apple.com>
1523
1524         bmalloc: Rename SmallPage to SmallRun
1525         https://bugs.webkit.org/show_bug.cgi?id=155320
1526
1527         Reviewed by Alex Christensen.
1528
1529         A page is a fixed-size set of lines.
1530
1531         A run is an variable-sized set of lines.
1532
1533         We want to start using runs because:
1534
1535             (a) we want to support varying the hardware page size by OS;
1536
1537             (b) we want to support allocations larger than our current page size.
1538
1539         * bmalloc.xcodeproj/project.pbxproj:
1540         * bmalloc/Allocator.cpp:
1541         (bmalloc::Allocator::reallocate):
1542         * bmalloc/Heap.cpp:
1543         (bmalloc::Heap::Heap):
1544         (bmalloc::Heap::initializeSmallRunMetadata):
1545         (bmalloc::Heap::scavenge):
1546         (bmalloc::Heap::scavengeSmallRuns):
1547         (bmalloc::Heap::allocateSmallBumpRanges):
1548         (bmalloc::Heap::allocateSmallRun):
1549         (bmalloc::Heap::deallocateSmallLine):
1550         (bmalloc::Heap::initializeLineMetadata): Deleted.
1551         (bmalloc::Heap::scavengeSmallPages): Deleted.
1552         (bmalloc::Heap::allocateSmallPage): Deleted.
1553         * bmalloc/Heap.h:
1554         * bmalloc/LineMetadata.h:
1555         * bmalloc/SmallChunk.h:
1556         (bmalloc::SmallChunk::begin):
1557         (bmalloc::SmallChunk::end):
1558         (bmalloc::SmallChunk::lines):
1559         (bmalloc::SmallChunk::runs):
1560         (bmalloc::SmallChunk::SmallChunk):
1561         (bmalloc::SmallLine::end):
1562         (bmalloc::SmallRun::get):
1563         (bmalloc::SmallRun::begin):
1564         (bmalloc::SmallRun::end):
1565         (bmalloc::SmallChunk::pages): Deleted.
1566         (bmalloc::SmallPage::get): Deleted.
1567         (bmalloc::SmallPage::begin): Deleted.
1568         (bmalloc::SmallPage::end): Deleted.
1569         * bmalloc/SmallPage.h: Removed.
1570         * bmalloc/SmallRun.h: Copied from Source/bmalloc/bmalloc/SmallPage.h.
1571         (bmalloc::SmallRun::SmallRun):
1572         (bmalloc::SmallRun::ref):
1573         (bmalloc::SmallRun::deref):
1574         (bmalloc::SmallPage::SmallPage): Deleted.
1575         (bmalloc::SmallPage::ref): Deleted.
1576         (bmalloc::SmallPage::deref): Deleted.
1577         * bmalloc/VMHeap.cpp:
1578         (bmalloc::VMHeap::allocateSmallChunk):
1579         (bmalloc::VMHeap::allocateLargeChunk):
1580         * bmalloc/VMHeap.h:
1581         (bmalloc::VMHeap::allocateSmallRun):
1582         (bmalloc::VMHeap::allocateLargeObject):
1583         (bmalloc::VMHeap::deallocateSmallRun):
1584         (bmalloc::VMHeap::deallocateLargeObject):
1585         (bmalloc::VMHeap::allocateSmallPage): Deleted.
1586         (bmalloc::VMHeap::deallocateSmallPage): Deleted.
1587
1588 2016-03-08  Geoffrey Garen  <ggaren@apple.com>
1589
1590         Unreviewed, rolling in r197722.
1591         https://bugs.webkit.org/show_bug.cgi?id=155171
1592
1593         The right calculation for our static_assert is actually:
1594
1595             sizeof(SmallChunk) % vmPageSize + 2 * smallMax <= vmPageSize
1596
1597         instead of:
1598
1599             sizeof(SmallChunk) % vmPageSize + smallMax <= vmPageSize
1600
1601         smallMax is not enough because line metadata might require us to begin
1602         allocation at an offset as large as smallMax, so we need 2 * smallMax.
1603
1604         Once correct, this static_assert fires, and we fix it by increasing
1605         the alignment of SmallChunk.
1606
1607         Restored changeset:
1608
1609         "bmalloc: Use List<T> instead of Vector<T> in some places"
1610         https://bugs.webkit.org/show_bug.cgi?id=155150
1611         http://trac.webkit.org/changeset/197722
1612
1613 2016-03-08  Commit Queue  <commit-queue@webkit.org>
1614
1615         Unreviewed, rolling out r197722.
1616         https://bugs.webkit.org/show_bug.cgi?id=155171
1617
1618         This change caused 800+ JSC test failures (Requested by
1619         ryanhaddad on #webkit).
1620
1621         Reverted changeset:
1622
1623         "bmalloc: Use List<T> instead of Vector<T> in some places"
1624         https://bugs.webkit.org/show_bug.cgi?id=155150
1625         http://trac.webkit.org/changeset/197722
1626
1627 2016-03-07  Geoffrey Garen  <ggaren@apple.com>
1628
1629         bmalloc: Use List<T> instead of Vector<T> in some places
1630         https://bugs.webkit.org/show_bug.cgi?id=155150
1631
1632         Reviewed by Andreas Kling.
1633
1634         Vector<T> is expensive when you want a lot of them because our minimum
1635         allocation size is the system page size.
1636
1637         * bmalloc.xcodeproj/project.pbxproj: Added a List<T> class.
1638
1639         * bmalloc/Heap.cpp:
1640         (bmalloc::Heap::scavengeSmallPages):
1641         (bmalloc::Heap::allocateSmallPage): Use the List<T> API. No need to check
1642         for stale entries anymore because List<T> supports O(1) eager removal
1643         and we remove eagerly now.
1644
1645         (bmalloc::Heap::deallocateSmallLine): Remove eagerly. This simplifies
1646         the allocation code and it is also required for correctness since we
1647         only have enough metadata to be in one list at a time.
1648
1649         * bmalloc/Heap.h: List!
1650
1651         * bmalloc/SmallChunk.h: Made this assert a little more precise since this
1652         patch triggered the old version in a benign way.
1653
1654         (bmalloc::SmallChunk::SmallChunk): This code moved to the SmallPage
1655         constructor.
1656
1657         * bmalloc/SmallPage.h:
1658         (bmalloc::SmallPage::SmallPage): Accomodate the List<T> data structure.
1659         This is a net memory savings on Mac for heaps smaller than ~128MB and on
1660         iOS for heaps smaller than ~512MB. The maximum memory saved is 512kB on
1661         Mac and 2MB on iOS. For larger heaps, there's a memory cost of 0.4% on
1662         Mac and 0.1% on iOS.
1663
1664         * bmalloc/VMHeap.h:
1665         (bmalloc::VMHeap::allocateSmallPage): Use List<T> API.
1666
1667 2016-03-03  Geoffrey Garen  <ggaren@apple.com>
1668
1669         Unreviewed, rolling in r197174.
1670         https://bugs.webkit.org/show_bug.cgi?id=154762
1671
1672         The right calculation for alignment is actually:
1673
1674             vmAlignment - getpagesize() + vmSize
1675
1676         instead of:
1677
1678             vmAlignment - vmPageSize + vmSize
1679
1680         The vmPageSize might be larger than getpagesize().
1681
1682         Restored changeset:
1683
1684         "bmalloc: Added a fast XLarge allocator"
1685         https://bugs.webkit.org/show_bug.cgi?id=154720
1686         http://trac.webkit.org/changeset/197174
1687
1688 2016-02-26  Commit Queue  <commit-queue@webkit.org>
1689
1690         Unreviewed, rolling out r197174.
1691         https://bugs.webkit.org/show_bug.cgi?id=154762
1692
1693         This change caused LayoutTests to crash on iOS simulator
1694         (Requested by ryanhaddad on #webkit).
1695
1696         Reverted changeset:
1697
1698         "bmalloc: Added a fast XLarge allocator"
1699         https://bugs.webkit.org/show_bug.cgi?id=154720
1700         http://trac.webkit.org/changeset/197174
1701
1702 2016-02-25  Geoffrey Garen  <ggaren@apple.com>
1703
1704         bmalloc: Added a fast XLarge allocator
1705         https://bugs.webkit.org/show_bug.cgi?id=154720
1706
1707         Reviewed by Andreas Kling.
1708
1709         This is a big speedup for XLarge allocations because it avoids mmap
1710         and page fault churn. It also enables future design changes to handle
1711         a smaller size range on the fast path.
1712
1713         * bmalloc.xcodeproj/project.pbxproj:
1714
1715         * bmalloc/Algorithm.h:
1716         (bmalloc::roundUpToMultipleOf):
1717         (bmalloc::roundDownToMultipleOf): Added a non-constant round down.
1718
1719         * bmalloc/Allocator.cpp:
1720         (bmalloc::Allocator::tryAllocate): XLarge no longer requires the caller
1721         to align things.
1722
1723         (bmalloc::Allocator::allocate): Tweaked the alignment calculation for
1724         clarity. When alignment and largeAlignment are equal, no adjustment
1725         is necessary since all allocations guarantee largeAlignment.
1726
1727         (bmalloc::Allocator::reallocate): Updated for interface change.
1728
1729         Note that the new interface fixes some concurrency bugs. The old code
1730         kept an iterator into the XLarge allocator across lock drop and acquisition,
1731         which is not cool.
1732
1733         (bmalloc::Allocator::allocateXLarge): XLarge no longer requires the caller
1734         to align things.
1735
1736         * bmalloc/Heap.cpp:
1737         (bmalloc::Heap::scavengeXLargeObjects): Added scavenging for XLarge.
1738
1739         (bmalloc::Heap::allocateXLarge):
1740
1741         (bmalloc::Heap::splitAndAllocate): Split XLarge objects to xLargeAlignment.
1742
1743         (bmalloc::Heap::tryAllocateXLarge):
1744         (bmalloc::Heap::xLargeSize):
1745         (bmalloc::Heap::shrinkXLarge):
1746         (bmalloc::Heap::deallocateXLarge): Allocate from our map before going
1747         to the OS.
1748
1749         (bmalloc::Heap::findXLarge): Deleted.
1750
1751         * bmalloc/Heap.h:
1752
1753         * bmalloc/LargeObject.h:
1754         (bmalloc::LargeObject::split):
1755
1756         * bmalloc/ObjectType.h:
1757         (bmalloc::isXLarge): Give XLarge objects an explicit alignment for clarity.
1758
1759         * bmalloc/Range.h:
1760         (bmalloc::Range::size):
1761         (bmalloc::Range::operator!):
1762         (bmalloc::Range::operator bool):
1763         (bmalloc::Range::operator<):
1764         (bmalloc::canMerge):
1765         (bmalloc::merge): Some helpers that were useful in writing this patch.
1766
1767         * bmalloc/Sizes.h:
1768
1769         * bmalloc/SortedVector.h: Added.
1770         (bmalloc::SortedVector::Bucket::Bucket):
1771         (bmalloc::SortedVector::Bucket::operator<):
1772         (bmalloc::SortedVector::iterator::iterator):
1773         (bmalloc::SortedVector::iterator::operator++):
1774         (bmalloc::SortedVector::iterator::operator!=):
1775         (bmalloc::SortedVector::iterator::operator*):
1776         (bmalloc::SortedVector::iterator::operator->):
1777         (bmalloc::SortedVector::iterator::skipDeletedBuckets):
1778         (bmalloc::SortedVector::begin):
1779         (bmalloc::SortedVector::end):
1780         (bmalloc::SortedVector<T>::insert):
1781         (bmalloc::SortedVector<T>::find):
1782         (bmalloc::SortedVector<T>::get):
1783         (bmalloc::SortedVector<T>::take):
1784         (bmalloc::SortedVector<T>::shrinkToFit): A simple abstraction for keeping
1785         a sorted vector. Insertion is average amortized log(n) because we keep
1786         deleted buckets that we can reuse.
1787
1788         This is better than a tree because we get better locality, less memory
1789         use, and simpler code. Also, trees require a node memory allocator, and
1790         implementing a memory allocator in a memory allocator is no fun.
1791
1792         Arguably we should use a hash table instead. But that's more code, and
1793         sorted vector has other nice properties that we might want to take
1794         adavantage of in the future.
1795
1796         * bmalloc/VMAllocate.h:
1797         (bmalloc::tryVMAllocate): Fixed an inaccuracy in the alignment calculation
1798         here. This code was sort of trying to enforce the alignment that the
1799         XLarge allocator enforces -- but it's better to enforce that alignment
1800         there.
1801
1802         The right calculation is:
1803
1804             vmAlignment - vmPageSize + vmSize
1805
1806         because the worst case is when you are aligned to 0 + vmPageSize, and
1807         you must walk forward vmAlignment - vmPageSize to reach the next
1808         vmAlignment.
1809
1810         (bmalloc::tryVMExtend): Deleted. No need to go back to the OS for VM
1811         since we manage our own.
1812
1813         * bmalloc/VMHeap.cpp:
1814         (bmalloc::VMHeap::allocateLargeChunk): Updated for clarity. When we
1815         grow the large heap we know that grown region is where the next allocation
1816         will take place, so we return it directly instead of pushing it to the
1817         free list.
1818
1819         This fixes a subtle bug where an overly conservative aligned allocation
1820         algorithm can fail to allocate at all when it grows the heap.
1821
1822         * bmalloc/VMHeap.h:
1823         (bmalloc::VMHeap::allocateLargeObject): Ditto.
1824         (bmalloc::VMHeap::allocateLargeObject): Ditto.
1825
1826         * bmalloc/VMState.h:
1827         (bmalloc::merge): Added a helper.
1828
1829         * bmalloc/Vector.h:
1830         (bmalloc::Vector::begin):
1831         (bmalloc::Vector::end):
1832         (bmalloc::Vector::size):
1833         (bmalloc::Vector::capacity):
1834         (bmalloc::Vector::last):
1835         (bmalloc::Vector::pop):
1836         (bmalloc::Vector<T>::push):
1837         (bmalloc::Vector<T>::pop):
1838         (bmalloc::Vector<T>::shrink): Use a proper iterator API to play nice
1839         with std algorithms.
1840
1841         (bmalloc::Vector<T>::insert): New function required by SortedVector.
1842
1843         (bmalloc::Vector<T>::reallocateBuffer):
1844         (bmalloc::Vector<T>::shrinkCapacity): Allow for shrinking back all the way
1845         to 0 because that's what shrinkToFit wants.
1846         (bmalloc::Vector<T>::growCapacity):
1847         (bmalloc::Vector<T>::shrinkToFit):
1848
1849         * bmalloc/XLargeMap.cpp: Added. Helper data structure for managing XLarge
1850         objects. We have enough granularity in our metadata to represent any
1851         kind of address range.
1852
1853         We store free ranges in a flat vector because most programs have very
1854         few individual free XLarge ranges. (They usually merge.)
1855
1856         We store allocated ranges in a sorted vector because programs might
1857         allocate lots of XLarge ranges. For example, if the XLarge minimum is
1858         128kB, and you have a 1GB process, that's 8192 ranges. Linear scan would
1859         examine 8192 items but binary search only 13.
1860
1861         Empirically, this is 1.5X faster than our current large allocator if you
1862         modify MallocBench/big to allocate XLarge objects and not to initialize
1863         objects and you allocate 128kB-256kB objects in a 1GB address space.
1864
1865         (bmalloc::XLargeMap::takeFree): Be careful about overflow in this function
1866         because we support super huge pointers, alignments, and sizes.
1867
1868         (bmalloc::XLargeMap::addFree): Merge eagerly on free because the cost
1869         of missing an XLarge opportunity is catastrophic. Also, I discovered
1870         by experiment that any allocator that doesn't merge eagerly can create
1871         lots of subtle opportunities for snowballing fragmentation, as
1872         fragmentation in range A forces you to chop up range B, and so on.
1873
1874         We allocate "first fit" (allocating the lowest address) because someone
1875         wrote a paper once that said that it's the best algorithm to combat
1876         fragmentation (even though worst case fragmentation is unavoidable
1877         regardless of algorithm).
1878
1879         (bmalloc::XLargeMap::addAllocated):
1880         (bmalloc::XLargeMap::getAllocated):
1881         (bmalloc::XLargeMap::takeAllocated):
1882         (bmalloc::XLargeMap::shrinkToFit):
1883         (bmalloc::XLargeMap::takePhysical):
1884         (bmalloc::XLargeMap::addVirtual):
1885         * bmalloc/XLargeMap.h: Added.
1886         (bmalloc::XLargeMap::Allocation::operator<):
1887
1888         * bmalloc/XLargeRange.h: Added.
1889         (bmalloc::XLargeRange::XLargeRange):
1890         (bmalloc::XLargeRange::vmState):
1891         (bmalloc::XLargeRange::setVMState):
1892         (bmalloc::canMerge):
1893         (bmalloc::merge):
1894         (bmalloc::XLargeRange::split): Helper for tracking VMState in a range.
1895
1896 2016-02-23  Dan Bernstein  <mitz@apple.com>
1897
1898         [Xcode] Linker errors display mangled names, but no longer should
1899         https://bugs.webkit.org/show_bug.cgi?id=154632
1900
1901         Reviewed by Sam Weinig.
1902
1903         * Configurations/Base.xcconfig: Stop setting LINKER_DISPLAYS_MANGLED_NAMES to YES.
1904
1905 2016-02-22  Konstantin Tokarev  <annulen@yandex.ru>
1906
1907         Fixed compilation of bmalloc with GCC 4.8 after r196873.
1908         https://bugs.webkit.org/show_bug.cgi?id=154534
1909
1910         Reviewed by Mark Lam.
1911
1912         See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382.
1913
1914         * bmalloc/LargeChunk.h:
1915         * bmalloc/SmallChunk.h:
1916
1917 2016-02-21  Geoffrey Garen  <ggaren@apple.com>
1918
1919         bmalloc: Don't use a whole page for metadata
1920         https://bugs.webkit.org/show_bug.cgi?id=154510
1921
1922         Reviewed by Andreas Kling.
1923
1924         (1) Don't round up metadata to a page boundary. This saves 1.5% dirty
1925         memory on iOS and 0.2% on Mac. It also enables a future patch to allocate
1926         smaller chunks without wasting memory.
1927
1928         (2) Initialize metadata lazily. This saves dirty memory when the program
1929         allocates primarily small or large objects (but not both), leaving some
1930         metadata uninitialized.
1931
1932         * bmalloc.xcodeproj/project.pbxproj: Medium objects are gone now.
1933
1934         * bmalloc/BumpAllocator.h:
1935         (bmalloc::BumpAllocator::refill): Added an ASSERT to help debug a bug
1936         I cause while working on this patch.
1937
1938         * bmalloc/Heap.cpp:
1939         (bmalloc::Heap::allocateSmallBumpRanges): Ditto.
1940
1941         (bmalloc::Heap::splitAndAllocate):
1942         (bmalloc::Heap::allocateLarge): Updated for interface change.
1943
1944         * bmalloc/LargeChunk.h: Changed the boundaryTagCount calculation to
1945         a static_assert.
1946
1947         Don't round up to page boundary. (See above.)
1948
1949         (bmalloc::LargeChunk::LargeChunk): Moved code here from LargeChunk::init.
1950         A constructor is a more natural / automatic way to do this initialization.
1951
1952         * bmalloc/LargeObject.h:
1953         (bmalloc::LargeObject::init): Deleted. Moved to LargeChunk.
1954
1955         * bmalloc/Sizes.h: Chagned largeChunkMetadataSize to a simpler constant
1956         because metadata size no longer varies by page size.
1957
1958         * bmalloc/SmallChunk.h:
1959         (bmalloc::SmallChunk::begin):
1960         (bmalloc::SmallChunk::end):
1961         (bmalloc::SmallChunk::lines):
1962         (bmalloc::SmallChunk::pages): Use std::array to make begin/end
1963         calculations easier.
1964
1965         (bmalloc::SmallChunk::SmallChunk): Treat our metadata like a series
1966         of allocated objects. We used to avoid trampling our metadata by
1967         starting object memory at the next page. Now we share the first page
1968         between metadata and objects, and we account for metadata explicitly.
1969
1970         * bmalloc/SuperChunk.h:
1971         (bmalloc::SuperChunk::SuperChunk):
1972         (bmalloc::SuperChunk::smallChunk):
1973         (bmalloc::SuperChunk::largeChunk):
1974         (bmalloc::SuperChunk::create): Deleted. Don't eagerly run the SmallChunk
1975         and LargeChunk constructors. We'll run them lazily as needed.
1976
1977         * bmalloc/VMHeap.cpp:
1978         (bmalloc::VMHeap::VMHeap):
1979         (bmalloc::VMHeap::allocateSmallChunk):
1980         (bmalloc::VMHeap::allocateLargeChunk):
1981         (bmalloc::VMHeap::allocateSuperChunk):
1982         (bmalloc::VMHeap::grow): Deleted. Track small and large chunks explicitly
1983         so we can initialize them lazily.
1984
1985         * bmalloc/VMHeap.h:
1986         (bmalloc::VMHeap::allocateSmallPage):
1987         (bmalloc::VMHeap::allocateLargeObject): Specify whether we're allocating
1988         a small or large chunk since we don't allocate both at once anymore.
1989
1990 2016-02-20  Mark Lam  <mark.lam@apple.com>
1991
1992         Use of inlined asm statements causes problems for -std=c99 builds.
1993         https://bugs.webkit.org/show_bug.cgi?id=154507
1994
1995         Reviewed by Dan Bernstein.
1996
1997         * bmalloc/BAssert.h:
1998
1999 2016-02-19  Joonghun Park  <jh718.park@samsung.com>
2000
2001         Unreviewed. Fix debug build error since r196847
2002
2003         Fix gcc build warning appeared as below
2004         by removing BASSERT(refCount <= maxRefCount).
2005         error: comparison is always true due to limited range of data type
2006         [-Werror=type-limits]
2007
2008         * bmalloc/SmallLine.h:
2009         (bmalloc::SmallLine::ref): Deleted.
2010
2011 2016-02-19  Geoffrey Garen  <ggaren@apple.com>
2012
2013         bmalloc: Chunk, Page, and Line don't need to be class templates
2014         https://bugs.webkit.org/show_bug.cgi?id=154480
2015
2016         Reviewed by Gavin Barraclough.
2017
2018         We needed class templates to distinguish between small and medium,
2019         but medium is gone now.
2020
2021         * bmalloc.xcodeproj/project.pbxproj:
2022         * bmalloc/Chunk.h: Removed.
2023         * bmalloc/Heap.cpp:
2024         (bmalloc::Heap::initializeLineMetadata):
2025         (bmalloc::Heap::allocateSmallBumpRanges):
2026         * bmalloc/Heap.h:
2027         * bmalloc/Line.h: Removed.
2028         * bmalloc/Page.h: Removed.
2029         * bmalloc/Sizes.h:
2030         * bmalloc/SmallChunk.h: Replaced with Source/bmalloc/bmalloc/Chunk.h.
2031         (bmalloc::SmallChunk::begin):
2032         (bmalloc::SmallChunk::end):
2033         (bmalloc::SmallChunk::lines):
2034         (bmalloc::SmallChunk::pages):
2035         (bmalloc::SmallChunk::get):
2036         (bmalloc::SmallLine::get):
2037         (bmalloc::SmallLine::begin):
2038         (bmalloc::SmallLine::end):
2039         (bmalloc::SmallPage::get):
2040         (bmalloc::SmallPage::begin):
2041         (bmalloc::SmallPage::end):
2042         (bmalloc::Chunk::begin): Deleted.
2043         (bmalloc::Chunk::end): Deleted.
2044         (bmalloc::Chunk::lines): Deleted.
2045         (bmalloc::Chunk::pages): Deleted.
2046         * bmalloc/SmallLine.h: Replaced with Source/bmalloc/bmalloc/Line.h.
2047         (bmalloc::SmallLine::ref):
2048         (bmalloc::SmallLine::deref):
2049         (bmalloc::Line<Traits>::begin): Deleted.
2050         (bmalloc::Line<Traits>::end): Deleted.
2051         (bmalloc::Line<Traits>::ref): Deleted.
2052         (bmalloc::Line<Traits>::deref): Deleted.
2053         * bmalloc/SmallPage.h: Replaced with Source/bmalloc/bmalloc/Page.h.
2054         (bmalloc::SmallPage::hasFreeLines):
2055         (bmalloc::SmallPage::setHasFreeLines):
2056         (bmalloc::SmallPage::ref):
2057         (bmalloc::SmallPage::deref):
2058         (bmalloc::Page::hasFreeLines): Deleted.
2059         (bmalloc::Page::setHasFreeLines): Deleted.
2060         (bmalloc::Page<Traits>::ref): Deleted.
2061         (bmalloc::Page<Traits>::deref): Deleted.
2062         * bmalloc/SmallTraits.h: Removed.
2063
2064 2016-02-18  Geoffrey Garen  <ggaren@apple.com>
2065
2066         bmalloc: Remove the concept of medium objects
2067         https://bugs.webkit.org/show_bug.cgi?id=154436
2068
2069         Reviewed by Sam Weinig.
2070
2071         There's no need to distinguish medium objects from small: Small object
2072         metadata works naturally for both as long as we allow an object to
2073         span more than two small lines. (We already allow an object to span
2074         more than one small line.)
2075
2076         This change reduces memory use because it eliminates the 1kB line size,
2077         so we don't have to hold down 1kB lines for individual 264+ byte objects.
2078
2079         1kB lines were always a bit of a compromise. The main point of bump
2080         allocation is to take advantage of cache lines. Cache lines are usually
2081         64 bytes, so line sizes above 256 bytes are a bit of a stretch.
2082
2083         This change speeds up small object benchmarks because it eliminates the
2084         branch to detect medium objects in deallocation log processing.
2085
2086         This change reduces virtual memory use from worst cast 4X to worst case
2087         2X because the medium chunk is gone. iOS cares about virtual memory use
2088         and terminates apps above ~1GB, so this change gives us more breathing room.
2089
2090         This change slows down medium benchmarks a bit because we end up doing
2091         more work to recycle fragmented medium objects. Overall, the tradeoff
2092         seems justified, since we have a net speedup and a memory use savings.
2093
2094         * bmalloc.xcodeproj/project.pbxproj: Removed all the medium files. We
2095         can simplify even further in a follow-up patch, removing the base class
2096         templates for Chunk, Page, and Line as well.
2097
2098         * bmalloc/Allocator.cpp:
2099         (bmalloc::Allocator::Allocator):
2100         (bmalloc::Allocator::allocate):
2101         (bmalloc::Allocator::reallocate):
2102         (bmalloc::Allocator::scavenge):
2103         (bmalloc::Allocator::refillAllocatorSlowCase):
2104         (bmalloc::Allocator::refillAllocator):
2105         (bmalloc::Allocator::allocateSlowCase): Medium is gone. Small max is the
2106         new medium max.
2107
2108         * bmalloc/Allocator.h:
2109         (bmalloc::Allocator::allocateFastCase): Ditto.
2110
2111         * bmalloc/BumpAllocator.h:
2112         (bmalloc::BumpAllocator::validate):
2113         (bmalloc::BumpAllocator::allocate): No more medium.
2114
2115         * bmalloc/Chunk.h: No more medium.
2116
2117         * bmalloc/Deallocator.cpp:
2118         (bmalloc::Deallocator::processObjectLog): No check for medium. This is
2119         a speedup.
2120
2121         (bmalloc::Deallocator::deallocateSlowCase): No more medium.
2122
2123         * bmalloc/Deallocator.h:
2124         (bmalloc::Deallocator::deallocateFastCase): Ditto.
2125
2126         * bmalloc/Heap.cpp:
2127         (bmalloc::Heap::initializeLineMetadata): The algorithm here changed from
2128         iterating each line to iterating each object. This helps us accomodate
2129         objects that might span more than two lines -- i.e., all objects between
2130         (512 bytes, 1024 bytes].
2131
2132         (bmalloc::Heap::scavenge):
2133         (bmalloc::Heap::scavengeSmallPages):
2134         (bmalloc::Heap::scavengeLargeObjects): Medium is gone.
2135
2136         (bmalloc::Heap::allocateSmallBumpRanges): Allow for lines that allocate
2137         zero objects. This happens when an object spans more than two lines --
2138         the middle lines allocate zero objects.
2139
2140         Also set the "has free lines" bit to false if we consume the last free
2141         line. This needs to be a bit now because not all pages agree on their
2142         maximum refcount anymore, so we need an explicit signal for the transition
2143         from maximum to maximum - 1.
2144
2145         (bmalloc::Heap::allocateSmallPage): This code didn't change; I just removed
2146         the medium code.
2147
2148         (bmalloc::Heap::deallocateSmallLine): Changed the algorithm to check
2149         hasFreeLines. See allocateSmallBumpRanges.
2150
2151         (bmalloc::Heap::scavengeMediumPages): Deleted.
2152         (bmalloc::Heap::allocateMediumBumpRanges): Deleted.
2153         (bmalloc::Heap::allocateMediumPage): Deleted.
2154         (bmalloc::Heap::deallocateMediumLine): Deleted.
2155         * bmalloc/Heap.h:
2156         (bmalloc::Heap::derefMediumLine): Deleted.
2157
2158         * bmalloc/LargeChunk.h:
2159         (bmalloc::LargeChunk::get):
2160         (bmalloc::LargeChunk::endTag):
2161         * bmalloc/Line.h: No more medium.
2162
2163         * bmalloc/MediumChunk.h: Removed.
2164         * bmalloc/MediumLine.h: Removed.
2165         * bmalloc/MediumPage.h: Removed.
2166         * bmalloc/MediumTraits.h: Removed.
2167
2168         * bmalloc/ObjectType.cpp:
2169         (bmalloc::objectType):
2170         * bmalloc/ObjectType.h:
2171         (bmalloc::isSmall):
2172         (bmalloc::isXLarge):
2173         (bmalloc::isSmallOrMedium): Deleted.
2174         (bmalloc::isMedium): Deleted. No more medium.
2175
2176         * bmalloc/Page.h:
2177         (bmalloc::Page::sizeClass):
2178         (bmalloc::Page::setSizeClass):
2179         (bmalloc::Page::hasFreeLines):
2180         (bmalloc::Page::setHasFreeLines): Add the free lines bit. You get better
2181         codegen if you make it the low bit, since ref / deref can then add / sub
2182         2. So do that.
2183
2184         * bmalloc/Sizes.h:
2185         (bmalloc::Sizes::sizeClass): Expand the small size class to include the
2186         medium size class.
2187
2188         * bmalloc/SuperChunk.h:
2189         (bmalloc::SuperChunk::SuperChunk):
2190         (bmalloc::SuperChunk::smallChunk):
2191         (bmalloc::SuperChunk::largeChunk):
2192         (bmalloc::SuperChunk::mediumChunk): Deleted. No more medium.
2193
2194         * bmalloc/VMHeap.cpp:
2195         (bmalloc::VMHeap::grow):
2196         * bmalloc/VMHeap.h:
2197         (bmalloc::VMHeap::allocateSmallPage): Set the has free lines bit before
2198         returning a Page to the Heap since this is the correct default state
2199         when we first allocate a page.
2200
2201         (bmalloc::VMHeap::allocateMediumPage): Deleted.
2202         (bmalloc::VMHeap::deallocateMediumPage): Deleted.
2203
2204 2016-02-19  Michael Saboff  <msaboff@apple.com>
2205
2206         bmalloc: Unify VMHeap and Heap LargeObjects free lists to reduce fragmentation
2207         https://bugs.webkit.org/show_bug.cgi?id=154192
2208
2209         Reviewed by Geoffrey Garen.
2210
2211         Change the operation of Heap and VMHeap LargeObject free lists.
2212         Renamed Owner to VMState to track the state of each LargeObject.
2213             Physical - The pages have been allocated.
2214             Virtual - The pages have not been allocated.
2215             Mixed - The object contains a mixture of Physical and Virtual pages.
2216         VMState uses one bit each for Physical and Virtual to simplify merging states
2217         when merging two adjacent blocks.  This change enforces the rule that objects in
2218         the Heap free list must have have the Physical bit set in their VMState while objects
2219         in the VMHeap free list must have the Physical bit clear.  Thie means that the Heap
2220         can have LargeObjects in Physical or Mixed VMState, but the VMHeap's free list can
2221         only contain Virtual LargeObjects.
2222         
2223         In both Heap::allocateLarge(), we now allocate physical pages if the LargeObject we
2224         pull from the free list has any Virtual pages before we possilby split the 
2225         object.  When we merge objects, the result might be made up of Mixed page allocations.
2226         When allocating a Mixed LargeObject, we need to allocate memory for them as well.
2227         The scavenger deallocates both Physical and Mixed LargeObjects, placing them back into
2228         the VMHeap's free list.
2229
2230         When we allocate or deallocate Mixed LargeObjects, there are pages that within these
2231         objects that will be redundantly modified.  It would require additional metadata to
2232         eliminate this redundancy.
2233
2234         * bmalloc.xcodeproj/project.pbxproj:
2235         * bmalloc/BoundaryTag.h:
2236         (bmalloc::BoundaryTag::vmState): New helper.
2237         (bmalloc::BoundaryTag::setVMState): New helper.
2238         (bmalloc::BoundaryTag::owner): Deleted.
2239         (bmalloc::BoundaryTag::setOwner): Deleted.
2240         * bmalloc/Heap.h:
2241         (bmalloc::Heap::splitAndAllocate): New helpers.
2242         * bmalloc/LargeObject.h:
2243         (bmalloc::LargeObject::vmState): New helper.
2244         (bmalloc::LargeObject::setVMState): New helper.
2245
2246         * bmalloc/Heap.cpp:
2247         (bmalloc::Heap::splitAndAllocate): New helpers.
2248         (bmalloc::Heap::allocateLarge): 
2249         (bmalloc::Heap::deallocatePhysicalPages): Refactored from VMHeap::deallocateLargeObjectMemory.
2250
2251         * bmalloc/FreeList.cpp:
2252         (bmalloc::FreeList::takeGreedy):
2253         (bmalloc::FreeList::take):
2254         (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
2255         * bmalloc/FreeList.h:
2256         (bmalloc::FreeList::FreeList):
2257         (bmalloc::FreeList::push):
2258         * bmalloc/Heap.cpp:
2259         (bmalloc::Heap::Heap):
2260         (bmalloc::Heap::scavengeLargeObjects):
2261         * bmalloc/LargeObject.h:
2262         (bmalloc::LargeObject::isValidAndFree):
2263         (bmalloc::LargeObject::validateSelf):
2264         * bmalloc/SegregatedFreeList.cpp:
2265         (bmalloc::SegregatedFreeList::SegregatedFreeList): Changed to initialize our required Physical state.
2266         * bmalloc/SegregatedFreeList.h:
2267         (bmalloc::SegregatedFreeList::SegregatedFreeList):
2268         (bmalloc::SegregatedFreeList::insert):
2269         (bmalloc::SegregatedFreeList::takeGreedy):
2270         (bmalloc::SegregatedFreeList::take):
2271         Replaced Owner parameters and checks with VMState::HasPhysical.
2272
2273         * bmalloc/LargeObject.h:
2274         (bmalloc::LargeObject::prevCanMerge): Removed owner from tests.
2275         (bmalloc::LargeObject::nextCanMerge): Removed owner from tests.
2276         (bmalloc::LargeObject::merge): Removed owner from tests.  Updated to merge VMStates andset the
2277         VMState after the merge.
2278
2279         * bmalloc/LargeObject.h:
2280         (bmalloc::LargeObject::owner): Deleted.
2281         (bmalloc::LargeObject::setOwner): Deleted.
2282
2283         * bmalloc/Owner.h: Removed.
2284
2285         * bmalloc/VMAllocate.h:
2286         (bmalloc::vmAllocatePhysicalPagesSloppy): Changed to round begin down to eliminate the left to right
2287         allocation constraint.
2288
2289         * bmalloc/VMHeap.cpp:
2290         (bmalloc::VMHeap::grow): Large space managed like small or medium as a vector of LargeChunks.
2291         (bmalloc::VMHeap::VMHeap): Changed to initialize our required Physical state.
2292
2293         * bmalloc/VMHeap.h:
2294         (bmalloc::VMHeap::allocateLargeObject): These no longer allocate memory.
2295         (bmalloc::VMHeap::deallocateLargeObject): Removed setOwner.  Now we set the VMState after any merges.
2296
2297         * bmalloc/VMState.h: Copied from Source/bmalloc/bmalloc/Owner.h.
2298         (bmalloc::VMState::VMState):
2299         (bmalloc::VMState::hasPhysical):
2300         (bmalloc::VMState::hasVirtual):
2301         (bmalloc::VMState::merge):
2302         (bmalloc::VMState::operator ==):
2303         (bmalloc::VMState::operator unsigned):
2304         New class with various helpers.
2305
2306 2016-02-12  Michael Saboff  <msaboff@apple.com>
2307
2308         BASSERTs added in r196421 are causing debug test failures
2309         https://bugs.webkit.org/show_bug.cgi?id=154113
2310
2311         Reviewed by Geoffrey Garen.
2312
2313         In VMHeap::deallocateLargeObject(), we drop the lock to deallocate the physical pages.
2314         If the scavenger thread is running at the same time a synchronous call to scavenge()
2315         comes in, we could call VMHeap::deallocateLargeObject() for an adjacent object while the
2316         lock in the other thread is dropped.  We fix this by checking for adjacent objects we
2317         can merge with and loop if we have one.
2318
2319         * bmalloc/FreeList.h:
2320         (bmalloc::FreeList::push): Added BASSERT to catch adding unmerged free objects
2321         * bmalloc/Heap.cpp:
2322         (bmalloc::Heap::allocateLarge): Changed to use nextCanMerge().
2323         * bmalloc/LargeObject.h:
2324         (bmalloc::LargeObject::prevCanMerge): Repurposed prevIsAllocated.
2325         (bmalloc::LargeObject::nextCanMerge): Repurposed nextIsAllocated.
2326         (bmalloc::LargeObject::prevIsAllocated): Deleted.
2327         (bmalloc::LargeObject::nextIsAllocated): Deleted.
2328         * bmalloc/VMHeap.h:
2329         (bmalloc::VMHeap::allocateLargeObject): Moved adding the extra object back to the free list
2330         to after we set the object we'll return as being allocated.
2331         (bmalloc::VMHeap::deallocateLargeObject):
2332
2333 2016-02-12  Mark Lam  <mark.lam@apple.com>
2334
2335         Make BCRASH() use breakpoint traps too for non-debug OS(DARWIN).
2336         https://bugs.webkit.org/show_bug.cgi?id=154184
2337
2338         Reviewed by Saam Barati.
2339
2340         This makes it behave consistently with WTFCrash().
2341
2342         * bmalloc/BAssert.h:
2343         * bmalloc/BPlatform.h:
2344
2345 2016-02-11  Michael Saboff  <msaboff@apple.com>
2346
2347         Unreviewed build fix after r196421.
2348
2349         Removed BASSERTs that are firing to eliminate Debug build crashes.  I'll debug locally and
2350         enable or alter after the issue is understood.
2351
2352         * bmalloc/LargeObject.h:
2353         (bmalloc::LargeObject::merge): Removed BASSERTs that are firing.
2354
2355 2016-02-11  Michael Saboff  <msaboff@apple.com>
2356
2357         bmalloc: large aligned allocations will put 1 or 2 free object on free list without merging with free neighbors
2358         https://bugs.webkit.org/show_bug.cgi?id=154091
2359
2360         Reviewed by Geoffrey Garen.
2361
2362         If we split off any unused free object in the aligned version of Heap::allocateLarge(), we merge them with
2363         free neighbors before putting them back on the free list.  Added helpers to verify that when we
2364         add LargeObjects to the free list their neighbors are allocated.
2365
2366         * bmalloc/Heap.cpp:
2367         (bmalloc::Heap::allocateLarge): Deleted private helper version and rolled it into the two the
2368         two public versions of allocateLarge().
2369         * bmalloc/Heap.h:
2370         * bmalloc/LargeObject.h:
2371         (bmalloc::LargeObject::prevIsAllocated): New helper.
2372         (bmalloc::LargeObject::nextIsAllocated): New helper.
2373         (bmalloc::LargeObject::merge): Check that the merge object has allocated neighbors.
2374
2375 2016-02-05  Saam barati  <sbarati@apple.com>
2376
2377         bmalloc: largeMax calculation is wrong on iOS
2378         https://bugs.webkit.org/show_bug.cgi?id=153923
2379
2380         Reviewed by Mark Lam.
2381
2382         Our number for largeMax was larger than what we had
2383         space to actually allocate inside the LargeChunk. This made 
2384         it so that we would allocate a large object for something
2385         that really should be extra large. Previously:
2386         largeMax + sizeof(LargeChunk) > 1MB
2387         which meant that when we would grow() to accommodate an allocation
2388         of a particular size inside a LargeObject despite the fact that
2389         the allocation size would be too large to actually fit in the LargeObject.
2390         This would manifest when we had an allocation size in the range:
2391         1MB - sizeof(LargeChunk) < allocation size < largeMax
2392
2393         We fix this bug by being precise in our calculation of largeMax
2394         instead of just assuming largeChunkSize * 99/100 is enough
2395         space for the metadata.
2396
2397         * bmalloc/LargeChunk.h:
2398         (bmalloc::LargeChunk::get):
2399         * bmalloc/Sizes.h:
2400
2401 2016-01-31  Dan Bernstein  <mitz@apple.com>
2402
2403         [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
2404         https://bugs.webkit.org/show_bug.cgi?id=153729
2405
2406         Reviewed by Sam Weinig.
2407
2408         After r141700, HAVE_HEADER_DETECTION_H is no longer used.
2409
2410         * Configurations/Base.xcconfig:
2411
2412 2015-12-19  Dan Bernstein  <mitz@apple.com>
2413
2414         [Mac] WebKit contains dead source code for OS X Mavericks and earlier
2415         https://bugs.webkit.org/show_bug.cgi?id=152462
2416
2417         Reviewed by Alexey Proskuryakov.
2418
2419         * Configurations/DebugRelease.xcconfig: Removed definition of MACOSX_DEPLOYMENT_TARGET for
2420           OS X 10.9.
2421
2422 2015-12-03  Anders Carlsson  <andersca@apple.com>
2423
2424         Remove Objective-C GC support
2425         https://bugs.webkit.org/show_bug.cgi?id=151819
2426         rdar://problem/23746991
2427
2428         Reviewed by Dan Bernstein.
2429
2430         * Configurations/Base.xcconfig:
2431
2432 2015-12-03  Michael Saboff  <msaboff@apple.com>
2433
2434         bmalloc: extra large allocations could be more efficient
2435         https://bugs.webkit.org/show_bug.cgi?id=151817
2436
2437         Reviewed by Geoffrey Garen.
2438
2439         Reduced the super chunk size from 4MB to 2MB.
2440
2441         Added path to reallocate() of an extra large object to see if we can extend the allocation.
2442
2443         * bmalloc/Allocator.cpp:
2444         (bmalloc::Allocator::reallocate):
2445         * bmalloc/SegregatedFreeList.h:
2446         * bmalloc/Sizes.h:
2447         * bmalloc/VMAllocate.h:
2448         (bmalloc::tryVMAllocate):
2449         (bmalloc::tryVMExtend):
2450         (bmalloc::vmAllocate):
2451
2452 2015-11-11  Akos Kiss  <akiss@inf.u-szeged.hu>
2453
2454         bmalloc: Add libdl dependency
2455         https://bugs.webkit.org/show_bug.cgi?id=151140
2456
2457         Reviewed by Csaba Osztrogonác.
2458
2459         Make sure that the linker links libdl and finds the references to
2460         dlopen, dlsym and dlclose in Environment.cpp.
2461
2462         * CMakeLists.txt:
2463
2464 2015-11-02  Andy Estes  <aestes@apple.com>
2465
2466         [Cocoa] Add tvOS and watchOS to SUPPORTED_PLATFORMS
2467         https://bugs.webkit.org/show_bug.cgi?id=150819
2468
2469         Reviewed by Dan Bernstein.
2470
2471         This tells Xcode to include these platforms in its Devices dropdown, making it possible to build in the IDE.
2472
2473         * Configurations/Base.xcconfig:
2474
2475 2015-11-01  Philip Chimento  <philip.chimento@gmail.com>
2476
2477         [GTK] Fix combinations of PLATFORM(GTK) and OS(DARWIN)
2478         https://bugs.webkit.org/show_bug.cgi?id=144560
2479
2480         Reviewed by Darin Adler.
2481
2482         * PlatformGTK.cmake: Added. This adds Zone.cpp to the PlatformGTK
2483         build, on Darwin only. Since there was previously nothing for the
2484         build system to do that was specific to the GTK platform in
2485         bmalloc, we need to create this file.
2486
2487 2015-10-29  Geoffrey Garen  <ggaren@apple.com>
2488
2489         bmalloc: AsyncTask should handle destruction
2490         https://bugs.webkit.org/show_bug.cgi?id=150648
2491
2492         Reviewed by Mark Lam.
2493
2494         So we can use it in more places.
2495
2496         * bmalloc/AsyncTask.h: Use std::thread instead of pthread because it
2497         should be more portable.
2498
2499         (bmalloc::Function>::AsyncTask): Renamed Signaled to RunRequested for
2500         clarity. Added an ExitRequested state.
2501
2502         (bmalloc::Function>::~AsyncTask): Wait for our child thread to exit
2503         before destroying ourselves because our child thread will modify our
2504         data (and might modify our client's data). Note that we only need to
2505         wait for the last child thread since any prior child thread, having
2506         reached the Exited condition, is guaranteed not to read or write any
2507         data.
2508
2509         (bmalloc::Function>::run):
2510         (bmalloc::Function>::runSlowCase): Updated for interface changes. Also
2511         changed to use our WebKit style for condition signal: Hold the lock
2512         during the signal and always notify all. Technically, neither is necessary,
2513         but it is easier to understand the code this way, and harder to make
2514         mistakes.
2515
2516         (bmalloc::Function>::threadEntryPoint):
2517         (bmalloc::Function>::threadRunLoop): Handle the new ExitRequested state.
2518         Technically, this state has no meaningful difference from the Exited
2519         state, but it is nice to be explicit.
2520
2521         (bmalloc::Function>::join): Deleted.
2522         (bmalloc::Function>::pthreadEntryPoint): Deleted.
2523         (bmalloc::Function>::entryPoint): Deleted.
2524
2525 2015-10-15  Geoffrey Garen  <ggaren@apple.com>
2526
2527         bmalloc: per-thread cache data structure should be smaller
2528         https://bugs.webkit.org/show_bug.cgi?id=150218
2529
2530         Reviewed by Andreas Kling.
2531
2532         Reduce the number of entries in the range cache because it's really
2533         big, and the bigness only helps in cases of serious fragmentation, and
2534         it only saves us a little bit of lock acquisition time.
2535
2536         * bmalloc/Allocator.cpp:
2537         (bmalloc::Allocator::scavenge):
2538         (bmalloc::Allocator::refillAllocatorSlowCase):
2539         (bmalloc::Allocator::refillAllocator):
2540         (bmalloc::Allocator::allocateLarge):
2541         (bmalloc::Allocator::allocateSlowCase):
2542         (bmalloc::Allocator::allocateBumpRangeSlowCase): Deleted.
2543         (bmalloc::Allocator::allocateBumpRange): Deleted.
2544         * bmalloc/Allocator.h: Pass through the empty allocator and the range
2545         cache when refilling, and refill both. Otherwise, we always immediately
2546         pop the last item in the range cache, wasting that slot of capacity.
2547
2548         * bmalloc/Heap.cpp:
2549         (bmalloc::Heap::allocateSmallBumpRanges):
2550         (bmalloc::Heap::allocateMediumBumpRanges): Account for the fact that
2551         the range cache is no longer big enough to guarantee that it can hold
2552         all the ranges in a page.
2553
2554         (bmalloc::Heap::refillSmallBumpRangeCache): Deleted.
2555         (bmalloc::Heap::refillMediumBumpRangeCache): Deleted.
2556
2557         * bmalloc/Heap.h: Move VMHeap to the end of the object because it
2558         contains a lot of unused / wasted space, and we want to pack our data
2559         together in memory.
2560
2561         * bmalloc/Sizes.h: Make the range cache smaller.
2562
2563 2015-10-13  Chris Dumez  <cdumez@apple.com>
2564
2565         Avoid useless copies in range-loops that are using 'auto'
2566         https://bugs.webkit.org/show_bug.cgi?id=150091
2567
2568         Reviewed by Sam Weinig.
2569
2570         Avoid useless copies in range-loops that are using 'auto'. Also use
2571         'auto*' instead of 'auto' when range values are pointers for clarity.
2572
2573         * bmalloc/Deallocator.cpp:
2574         (bmalloc::Deallocator::processObjectLog):
2575
2576 2015-10-12  Geoffrey Garen  <ggaren@apple.com>
2577
2578         bmalloc: Don't ASSERT that all syscalls succeed
2579         https://bugs.webkit.org/show_bug.cgi?id=150047
2580         <rdar://problem/22649531>
2581
2582         Reviewed by Mark Lam.
2583
2584         madvise can fail due to VM behaviors outside of our control:
2585         copy-on-write, fork, mprotect, and other stuff.
2586
2587         Older darwin kernels sometimes return this error value, and new kernels
2588         might again in future.
2589
2590         We haven't gained much from this ASSERT so far, so let's remove it.
2591
2592         Perhaps in future we can come up with a scheme that makes madvise
2593         never fail, or that responds to failure.
2594
2595         * bmalloc/Syscall.h:
2596
2597 2015-10-10  Dan Bernstein  <mitz@apple.com>
2598
2599         [iOS] Remove project support for iOS 8
2600         https://bugs.webkit.org/show_bug.cgi?id=149993
2601
2602         Reviewed by Alexey Proskuryakov.
2603
2604         * Configurations/Base.xcconfig:
2605         * Configurations/bmalloc.xcconfig:
2606         * Configurations/mbmalloc.xcconfig:
2607
2608 2015-08-31  Michael Catanzaro  <mcatanzaro@igalia.com>
2609
2610         Implement bmalloc::isASanEnabled for generic Unix
2611         https://bugs.webkit.org/show_bug.cgi?id=148623
2612
2613         Reviewed by Geoffrey Garen.
2614
2615         * bmalloc/BPlatform.h: Add BOS_UNIX to detect whether the OS is a Unix.
2616         * bmalloc/Environment.cpp:
2617         (bmalloc::isASanEnabled): Implement a runtime check that should work on any Unix.
2618
2619 2015-08-19  Geoffrey Garen  <ggaren@apple.com>
2620
2621         Crash @ bmalloc::Environment::computeIsBmallocEnabled
2622         https://bugs.webkit.org/show_bug.cgi?id=148183
2623
2624         Reviewed by NOBODY Michael Saboff.
2625
2626         CrashTracer says we have some crashes beneath computeIsBmallocEnabled
2627         dereferencing null in strstr. We null check getenv but not
2628         _dyld_get_image_name, so deduction indicates that _dyld_get_image_name
2629         must be returning null. _dyld_get_image_name isn't really documented,
2630         so let's assume it can return null.
2631
2632         * bmalloc/Environment.cpp:
2633         (bmalloc::isASanEnabled): Check _dyld_get_image_name's return value for
2634         null because we can't prove it won't be null.
2635
2636 2015-07-24  Geoffrey Garen  <ggaren@apple.com>
2637
2638         vmmap crash at JavaScriptCore: 0x31cd12f6 (the JavaScript malloc zone enumerator)
2639         https://bugs.webkit.org/show_bug.cgi?id=147274
2640
2641         Reviewed by Anders Carlsson.
2642
2643         It's not really clear why vmmap sometimes fails to read the target
2644         process, but we can avoid a crash when it does. This is useful because
2645         you'll still get all the non-bmalloc data out of the target process,
2646         and bmalloc might not even be relevant to your investigation.
2647
2648         * bmalloc/Zone.cpp:
2649         (bmalloc::remoteRead): Check for failure.
2650
2651 2015-07-24  Geoffrey Garen  <ggaren@apple.com>
2652
2653         JavaScriptCore bmalloc should not register its malloc zone more than once
2654         https://bugs.webkit.org/show_bug.cgi?id=147273
2655
2656         Reviewed by Andreas Kling.
2657
2658         This was a goof: The Zone constructor, by virtue of running automatically,
2659         was registering a Zone inside the analysis process.
2660
2661         * bmalloc/Zone.cpp:
2662         (bmalloc::remoteRead): Clarify that the pointer is remote.
2663
2664         (bmalloc::enumerator):
2665         (bmalloc::Zone::Zone):
2666         * bmalloc/Zone.h: Separate the normal constructor and the remote constructor.
2667         The remote constructor skips zone registration since its goal is not
2668         to register a zone in the current process or do any allocation but rather
2669         to mirror the bytes of the zone from the target process.
2670
2671 2015-07-23  Geoffrey Garen  <ggaren@apple.com>
2672
2673         bmalloc: Shrink the super chunk size (again)
2674         https://bugs.webkit.org/show_bug.cgi?id=147240
2675
2676         Reviewed by Andreas Kling.
2677
2678         Shrinking to 8MB reduced VM exhaustion crashes but did not eliminate them.
2679         Let's try 4MB.
2680
2681         (My previous comment was that the maximum fast object was 2MB. But it
2682         was 4MB! Now it's 2MB for realsies.)
2683
2684         * bmalloc/Sizes.h:
2685
2686 2015-07-03  Dan Bernstein  <mitz@apple.com>
2687
2688         [Xcode] Update some build settings as recommended by Xcode 7
2689         https://bugs.webkit.org/show_bug.cgi?id=146597
2690
2691         Reviewed by Sam Weinig.
2692
2693         * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE, GCC_NO_COMMON_BLOCKS,
2694         and ENABLE_STRICT_OBJC_MSGSEND. Removed GCC_MODEL_TUNING.
2695
2696         * bmalloc.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
2697
2698 2015-07-02  Geoffrey Garen  <ggaren@apple.com>
2699
2700         bmalloc: Shrink the super chunk size
2701         https://bugs.webkit.org/show_bug.cgi?id=146519
2702
2703         Reviewed by Andreas Kling.
2704
2705         We have lots of reports of crashing due to failed VM allocation on iOS.
2706         (This VM limit on iOS is usually 1GB-2GB, and has been as low as 256MB.)
2707
2708         Shrink the super chunk size in case fragmentation is the reason for
2709         VM allocation failure.
2710
2711         This has the downside that >= 2MB allocations will now be super slow,
2712         but they are also super rare (as in never on most websites), so this
2713         is probably an OK tradeoff.
2714
2715         * bmalloc/Sizes.h:
2716
2717 2015-07-01  Geoffrey Garen  <ggaren@apple.com>
2718
2719         bmalloc: realloc of an XLarge range can unmap adjacent VM ranges
2720         https://bugs.webkit.org/show_bug.cgi?id=146535
2721
2722         Reviewed by Anders Carlsson.
2723
2724         This bug causes a crash when running fast/css/large-list-of-rules-crash.html
2725         with the fix applied for https://bugs.webkit.org/show_bug.cgi?id=146519.
2726
2727         * bmalloc/Allocator.cpp:
2728         (bmalloc::Allocator::reallocate): Start at object + newSize since starting
2729         at object + oldSize means deleting the adjacent VM range.
2730
2731 2015-05-26  Geoffrey Garen  <ggaren@apple.com>
2732
2733         Integer overflow in XLarge allocation (due to unchecked roundUpToMultipleOf)
2734         https://bugs.webkit.org/show_bug.cgi?id=145385
2735
2736         Reviewed by Andreas Kling.
2737
2738         Added some checking to verify that round-up operations will not overflow
2739         a size_t.
2740
2741         The simplest way to do this was to introduce a notion of xLargeMax, like
2742         we have for smallMax, mediumMax, and largeMax. It's a bit surprising at
2743         first to think that there is an xLargeMax, since xLarge is what we use
2744         to handle the biggest things. But computers have limits, so it makes sense.
2745
2746         FWIW, TCMalloc used to have an xLargeMax too, which it called kMaxValidPages.
2747
2748         No test because this bug was found by code inspection and I don't know
2749         of a practical way to convince WebKit to make an allocation this large.
2750
2751         * bmalloc/Allocator.cpp:
2752         (bmalloc::Allocator::tryAllocate):
2753         (bmalloc::Allocator::allocate):
2754         (bmalloc::Allocator::reallocate):
2755         (bmalloc::Allocator::allocateSlowCase): Check against xLargeMax to avoid
2756         overflow when rounding up.
2757
2758         * bmalloc/BAssert.h: Added support for explicit crashing.
2759
2760         * bmalloc/Sizes.h:
2761
2762 2015-05-26  Dan Bernstein  <mitz@apple.com>
2763
2764         <rdar://problem/21104551> Update build settings
2765
2766         Reviewed by Anders Carlsson.
2767
2768         * Configurations/DebugRelease.xcconfig:
2769
2770 2015-05-23  Dan Bernstein  <mitz@apple.com>
2771
2772         Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
2773         https://bugs.webkit.org/show_bug.cgi?id=145345
2774
2775         Reviewed by Sam Weinig.
2776
2777         * Configurations/Base.xcconfig: Also changed to use $(inherited).
2778
2779 2015-05-07  Geoffrey Garen  <ggaren@apple.com>
2780
2781         Release assert in com.apple.WebKit.WebContent under JavaScriptCore: JSC::JSONProtoFuncStringify
2782         https://bugs.webkit.org/show_bug.cgi?id=144758
2783
2784         Reviewed by Andreas Kling.
2785
2786         This was an out-of-memory error when trying to shrink a string builder.
2787         bmalloc was missing the optimization that allowed realloc() to shrink
2788         without copying. So, let's add it.
2789
2790         * bmalloc/Allocator.cpp:
2791         (bmalloc::Allocator::reallocate): Added Large and XLarge cases for
2792         shrinking without copying. This isn't possible for small and medium
2793         objects, and probably not very profitable, either.
2794
2795         * bmalloc/Heap.cpp:
2796         (bmalloc::Heap::findXLarge):
2797         (bmalloc::Heap::deallocateXLarge):
2798         * bmalloc/Heap.h: Refactored this code to return a reference to an
2799         XLarge range. This makes the code reusable, and also makes it easier
2800         for realloc() to update metadata.
2801
2802         * bmalloc/LargeObject.h:
2803         (bmalloc::LargeObject::split): Allow allocated objects to split because
2804         that's what realloc() wants to do, and there's nothing intrinsically
2805         wrong with it.
2806
2807 2015-05-07  Dan Bernstein  <mitz@apple.com>
2808
2809         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
2810         https://bugs.webkit.org/show_bug.cgi?id=144727
2811
2812         Reviewed by Darin Adler.
2813
2814         * Configurations/Base.xcconfig: Dont’s include AspenFamily.xcconfig, and define
2815         INSTALL_PATH_PREFIX for the iOS 8.x Simulator.
2816
2817 2015-04-01  Alex Christensen  <achristensen@webkit.org>
2818
2819         Progress towards CMake on Windows and Mac.
2820         https://bugs.webkit.org/show_bug.cgi?id=143293
2821
2822         Reviewed by Filip Pizlo.
2823
2824         * bmalloc/BAssert.h:
2825         Removed ellipses from macros to appease Visual Studio.
2826
2827 2015-03-13  Alex Christensen  <achristensen@webkit.org>
2828
2829         Progress towards CMake on Mac.
2830         https://bugs.webkit.org/show_bug.cgi?id=142680
2831
2832         Reviewed by Gyuyoung Kim.
2833
2834         * CMakeLists.txt:
2835         * PlatformMac.cmake:
2836         Added Zone.cpp to Mac CMake builds.
2837
2838 2015-03-12  Geoffrey Garen  <ggaren@apple.com>
2839
2840         Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
2841         https://bugs.webkit.org/show_bug.cgi?id=142642
2842
2843         Reviewed by Michael Saboff.
2844
2845         The typical backtrace to this crash shows the main thread trying to
2846         realloc a large string while a DFG compiler thread tries to
2847         free a large vector buffer.
2848
2849         I believe that this is a race condition -- at least in debug builds --
2850         since the main thread will try to validate its object's neighbors
2851         without holding a lock, even though those neighbors might be in the
2852         midst of changing.
2853
2854         In general, there may be sneaky times when it is valid to look at an
2855         object's metadata without holding the heap lock, but it is best not to
2856         do so unless we have a really really good reason to.
2857
2858         * bmalloc/Allocator.cpp:
2859         (bmalloc::Allocator::reallocate): Take a lock before reading the metadata
2860         for this object, since we generally require any access to shared heap
2861         metadata to take a lock.
2862
2863 2015-03-10  Geoffrey Garen  <ggaren@apple.com>
2864
2865         bmalloc: tryFastMalloc shouldn't crash
2866         https://bugs.webkit.org/show_bug.cgi?id=142443
2867
2868         Reviewed by Sam Weinig.
2869
2870         Rolling back in r181307 with a check for whether bmalloc is enabled, to
2871         avoid crashes when running with ASan and GuardMalloc.
2872
2873         * bmalloc/Allocator.cpp:
2874         (bmalloc::Allocator::tryAllocate):
2875         * bmalloc/Allocator.h:
2876         * bmalloc/Cache.cpp:
2877         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
2878         * bmalloc/Cache.h:
2879         (bmalloc::Cache::tryAllocate):
2880         * bmalloc/Heap.cpp:
2881         (bmalloc::Heap::allocateXLarge):
2882         (bmalloc::Heap::tryAllocateXLarge):
2883         * bmalloc/Heap.h:
2884         * bmalloc/VMAllocate.h:
2885         (bmalloc::tryVMAllocate):
2886         (bmalloc::vmAllocate):
2887         * bmalloc/bmalloc.h:
2888         (bmalloc::api::tryMalloc):
2889         (bmalloc::api::realloc):
2890         (bmalloc::api::free):
2891
2892 2015-03-09  Commit Queue  <commit-queue@webkit.org>
2893
2894         Unreviewed, rolling out r181307.
2895         https://bugs.webkit.org/show_bug.cgi?id=142525
2896
2897         Broke ASan tests (Requested by ap on #webkit).
2898
2899         Reverted changeset:
2900
2901         "bmalloc: tryFastMalloc shouldn't crash"
2902         https://bugs.webkit.org/show_bug.cgi?id=142443
2903         http://trac.webkit.org/changeset/181307
2904
2905 2015-03-09  Geoffrey Garen  <ggaren@apple.com>
2906
2907         bmalloc: tryFastMalloc shouldn't crash
2908         https://bugs.webkit.org/show_bug.cgi?id=142443
2909
2910         Reviewed by Darin Adler.
2911
2912         Added support for tryMalloc.
2913
2914         We assume that non-x-large allocations always succeed, and we crash
2915         otherwise, since normal allocation failure will just cause the next
2916         non-try allocation or internal metadata allocation to fail, and it's
2917         hard and not really useful to keep limping along after that. But
2918         extra-large allocations can meaningfully fail, and we can recover.
2919
2920         * bmalloc/Heap.cpp:
2921         (bmalloc::Heap::allocateXLarge):
2922         (bmalloc::Heap::tryAllocateXLarge):
2923         * bmalloc/Heap.h: Added support for non-crashy x-large allocation.
2924
2925         * bmalloc/VMAllocate.h:
2926         (bmalloc::tryVMAllocate):
2927         (bmalloc::vmAllocate): Added support for non-crashy VM allocation.
2928
2929         * bmalloc/bmalloc.h:
2930         (bmalloc::api::tryMalloc):
2931         (bmalloc::api::realloc):
2932         (bmalloc::api::free): Tried to clarify our behavior with some comments.
2933         Unfortunately, calling what we do "malloc" is still not quite right, since
2934         malloc returns null on failure and we don't.
2935
2936 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
2937
2938         bmalloc: Don't branch when setting the owner of a large object
2939         https://bugs.webkit.org/show_bug.cgi?id=142241
2940
2941         Reviewed by Andreas Kling.
2942
2943         * bmalloc/BoundaryTag.h:
2944         (bmalloc::BoundaryTag::owner):
2945         (bmalloc::BoundaryTag::setOwner):
2946
2947 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
2948
2949         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
2950         https://bugs.webkit.org/show_bug.cgi?id=141802
2951
2952         Reviewed by Andreas Kling.
2953
2954         Re-enabled this feature on iOS, now that the iOS crash should be fixed.
2955
2956         * bmalloc/VMHeap.cpp:
2957         (bmalloc::VMHeap::grow):
2958         * bmalloc/VMHeap.h:
2959
2960 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
2961
2962         bmalloc: Added missing features to the malloc zone introspection API
2963         https://bugs.webkit.org/show_bug.cgi?id=142235
2964
2965         Reviewed by Andreas Kling.
2966
2967         This should fix the crash we saw on the iOS PLT bot
2968         (c.f. http://trac.webkit.org/changeset/180604).
2969
2970         * bmalloc/Zone.cpp:
2971         (bmalloc::good_size):
2972         (bmalloc::check):
2973         (bmalloc::print):
2974         (bmalloc::log):
2975         (bmalloc::force_lock):
2976         (bmalloc::force_unlock):
2977         (bmalloc::statistics):
2978         (bmalloc::size):
2979         (bmalloc::enumerator): Provide all of these functions since they are called
2980         indiscriminately on all zones.
2981
2982         (bmalloc::Zone::Zone):
2983         (bmalloc::Zone::size): Deleted.
2984         (bmalloc::Zone::enumerator): Deleted. Moved these functions out of the
2985         Zone class since they can stand alone.
2986
2987         * bmalloc/Zone.h:
2988
2989 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
2990
2991         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
2992         https://bugs.webkit.org/show_bug.cgi?id=141802
2993
2994         Reviewed by Andreas Kling.
2995
2996         Rolling back in but disabled on iOS until I can debug why the iOS PLT crashes.
2997
2998         * bmalloc/VMHeap.cpp:
2999         (bmalloc::VMHeap::grow):
3000         * bmalloc/VMHeap.h:
3001         * bmalloc/Zone.cpp:
3002         (bmalloc::Zone::size):
3003         (bmalloc::Zone::Zone):
3004         * bmalloc/Zone.h:
3005
3006 2015-03-03  Geoffrey Garen  <ggaren@apple.com>
3007
3008         bmalloc: Miscellaneous cleanup
3009         https://bugs.webkit.org/show_bug.cgi?id=142231
3010
3011         Reviewed by Andreas Kling.
3012
3013         No performance change -- maybe a tiny reduction in memory use.
3014
3015         * bmalloc/Heap.cpp: Moved the sleep function into StaticMutex, since
3016         it's a helper for working with mutexes.
3017
3018         (bmalloc::Heap::scavenge): Make sure to wait before we start any
3019         scavenging, since individual scavenging functions now always scavenge
3020         at least one page before waiting themselves.
3021
3022         (bmalloc::Heap::scavengeSmallPages):
3023         (bmalloc::Heap::scavengeMediumPages):
3024         (bmalloc::Heap::scavengeLargeObjects): Use the new wait helper to
3025         simplify this code. Also, we now require our caller to wait until at
3026         least one deallocation is desirable. This simplifies our loop.
3027
3028         (bmalloc::Heap::allocateSmallPage):
3029         (bmalloc::Heap::allocateMediumPage):
3030         (bmalloc::Heap::allocateXLarge):
3031         (bmalloc::Heap::allocateLarge): Don't freak out any time the heap does
3032         an allocation. Only consider the heap to be growing if it actually needs
3033         to allocate new VM. This allows us to shrink the heap back down from a
3034         high water mark more reliably even if heap activity continues.
3035
3036         (bmalloc::sleep): Deleted.
3037         (bmalloc::Heap::scavengeLargeRanges): Renamed to match our use of
3038         "LargeObject".
3039
3040         * bmalloc/Heap.h:
3041
3042         * bmalloc/LargeObject.h:
3043         (bmalloc::LargeObject::operator bool): Added to simplify a while loop.
3044
3045         * bmalloc/StaticMutex.h:
3046         (bmalloc::sleep):
3047         (bmalloc::waitUntilFalse): New helper for waiting until a condition
3048         becomes reliably false.
3049
3050         * bmalloc/Vector.h:
3051         (bmalloc::Vector<T>::~Vector): Oops! Don't deallocate the null pointer.
3052         We don't actually run any Vector destructors, but an iteration of this
3053         patch did, and then crashed. So, let's fix that.
3054
3055 2015-03-02  Geoffrey Garen  <ggaren@apple.com>
3056
3057         bmalloc: Eagerly remove allocated objects from the free list
3058         https://bugs.webkit.org/show_bug.cgi?id=142194
3059
3060         Reviewed by Andreas Kling.
3061
3062         This reduces the pressure to garbage collect the free list.
3063
3064         Might be a 1% speedup on MallocBench.
3065
3066         * bmalloc/FreeList.cpp: Put this comment at the top of the file instead
3067         of repeating it inside of each function. Tried to clarify the details.
3068
3069         (bmalloc::FreeList::takeGreedy): Matched the other iteration code in this
3070         file for consistency -- even though either direction works fine in this
3071         function.
3072
3073         (bmalloc::FreeList::take): Change to iterate from low to high so that we
3074         can maintain an index into the vector that is not disturbed even if we
3075         pop from the middle (which invalidates the last index in the vector).
3076
3077         Decrement i when popping from the middle to make sure that we don't
3078         skip the next item after popping.
3079
3080         (bmalloc::FreeList::removeInvalidAndDuplicateEntries): Ditto.
3081
3082 2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>
3083
3084         Fixed a typo in the previous commit.
3085
3086         * bmalloc/BoundaryTag.h:
3087         (bmalloc::BoundaryTag::setOwner):
3088
3089 2015-02-27  Ryosuke Niwa  <rniwa@webkit.org>
3090
3091         EFL build fix after r180797.
3092
3093         * bmalloc/BoundaryTag.h:
3094         (bmalloc::BoundaryTag::owner):
3095         (bmalloc::BoundaryTag::setOwner):
3096
3097 2015-02-27  Geoffrey Garen  <ggaren@apple.com>
3098
3099         bmalloc: Pathological madvise churn on the free(malloc(x)) benchmark
3100         https://bugs.webkit.org/show_bug.cgi?id=142058
3101
3102         Reviewed by Andreas Kling.
3103
3104         The churn was caused by repeatedly splitting an object with physical
3105         pages from an object without, and then merging them back together again.
3106         The merge would conservatively forget that we had physical pages, forcing
3107         a new call to madvise on the next allocation.
3108
3109         This patch more strictly segregates objects in the heap from objects in
3110         the VM heap, with these changes:
3111
3112         (1) Objects in the heap are not allowed to merge with objects in the VM
3113         heap, and vice versa -- since that would erase our precise knowledge of
3114         which physical pages had been allocated.
3115
3116         (2) The VM heap is exclusively responsible for allocating and deallocating
3117         physical pages.
3118
3119         (3) The heap free list must consider entries for objects that are in the
3120         VM heap to be invalid, and vice versa. (This condition can arise
3121         because the free list does not eagerly remove items.)
3122
3123         With these changes, we can know that any valid object in the heap's free
3124         list already has physical pages, and does not need to call madvise.
3125
3126         Note that the VM heap -- as before -- might sometimes contain ranges
3127         or pieces of ranges that have physical pages, since we allow splitting
3128         of ranges at granularities smaller than the VM page size. These ranges
3129         can eventually merge with ranges in the heap during scavenging.
3130
3131         * bmalloc.xcodeproj/project.pbxproj:
3132
3133         * bmalloc/BoundaryTag.h:
3134         (bmalloc::BoundaryTag::owner):
3135         (bmalloc::BoundaryTag::setOwner):
3136         (bmalloc::BoundaryTag::initSentinel):
3137         (bmalloc::BoundaryTag::hasPhysicalPages): Deleted.
3138         (bmalloc::BoundaryTag::setHasPhysicalPages): Deleted. Replaced the concept
3139         of "has physical pages" with a bit indicating which heap owns the large
3140         object. This is a more precise concept, since the old bit was really a
3141         Yes / Maybe bit.
3142
3143         * bmalloc/Deallocator.cpp:
3144
3145         * bmalloc/FreeList.cpp: Adopt
3146         (bmalloc::FreeList::takeGreedy):
3147         (bmalloc::FreeList::take):
3148         (bmalloc::FreeList::removeInvalidAndDuplicateEntries):
3149         * bmalloc/FreeList.h:
3150         (bmalloc::FreeList::push): Added API for considering the owner when
3151         deciding if a free list entry is valid.
3152
3153         * bmalloc/Heap.cpp:
3154         (bmalloc::Heap::Heap): Adopt new API.
3155
3156         (bmalloc::Heap::scavengeLargeRanges): Scavenge all ranges with no minimum,
3157         since some ranges might be able to merge with ranges in the VM heap, and
3158         they won't be allowed to until we scavenge them.
3159
3160         (bmalloc::Heap::allocateSmallPage):
3161         (bmalloc::Heap::allocateMediumPage):
3162         (bmalloc::Heap::allocateLarge): New VM heap API makes this function
3163         simpler, since we always get back physical pages now.
3164
3165         * bmalloc/Heap.h:
3166         * bmalloc/LargeObject.h:
3167         (bmalloc::LargeObject::end):
3168         (bmalloc::LargeObject::owner):
3169         (bmalloc::LargeObject::setOwner):
3170         (bmalloc::LargeObject::isValidAndFree):
3171         (bmalloc::LargeObject::merge): Do not merge objects across heaps since
3172         that causes madvise churn.
3173         (bmalloc::LargeObject::validateSelf):
3174         (bmalloc::LargeObject::init):
3175         (bmalloc::LargeObject::hasPhysicalPages): Deleted.
3176         (bmalloc::LargeObject::setHasPhysicalPages): Deleted. Propogate the Owner API.
3177
3178         * bmalloc/Owner.h: Added.
3179
3180         * bmalloc/SegregatedFreeList.cpp:
3181         (bmalloc::SegregatedFreeList::SegregatedFreeList):
3182         (bmalloc::SegregatedFreeList::insert):
3183         (bmalloc::SegregatedFreeList::takeGreedy):
3184         (bmalloc::SegregatedFreeList::take):
3185         * bmalloc/SegregatedFreeList.h: Propogate the owner API.
3186
3187         * bmalloc/VMAllocate.h:
3188         (bmalloc::vmDeallocatePhysicalPagesSloppy):
3189         (bmalloc::vmAllocatePhysicalPagesSloppy): Clarified these functions and
3190         removed an edge case.
3191
3192         * bmalloc/VMHeap.cpp:
3193         (bmalloc::VMHeap::VMHeap):
3194         * bmalloc/VMHeap.h:
3195         (bmalloc::VMHeap::allocateSmallPage):
3196         (bmalloc::VMHeap::allocateMediumPage):
3197         (bmalloc::VMHeap::allocateLargeObject):
3198         (bmalloc::VMHeap::deallocateLargeObject): Be sure to give each object
3199         a new chance to merge, since it might have been prohibited from merging
3200         before by virtue of not being in the VM heap.
3201
3202         (bmalloc::VMHeap::allocateLargeRange): Deleted.
3203         (bmalloc::VMHeap::deallocateLargeRange): Deleted.
3204
3205 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
3206
3207         bmalloc: Large object free list can grow infinitely
3208         https://bugs.webkit.org/show_bug.cgi?id=142055
3209
3210         Reviewed by Andreas Kling.
3211
3212         By design, we don't eagerly remove large objects from the free list.
3213         This creates two simple pathologies:
3214
3215             (1) If you free and then allocate the same object repeatedly, it will
3216             duplicate itself in the free list repeatedly. Since it is never
3217             invalid at the time of allocation, it will never be removed.
3218
3219             (2) If you split and then merge the same object repeatedly, it will
3220             duplicate its split sibling in the free list repeatedly. If its
3221             sibling is in a separate free list size class, it will never be
3222             consulted at the time of allocation, so it will never be removed.
3223
3224         So, a simple "while (1) { free(malloc(x)); }" causes infinite memory
3225         use in the free list.
3226
3227         The solution in this patch is a simple helper to remove garbage from the
3228         free list if it grows too large. This pathology is not common, so the
3229         cost is OK.
3230
3231         Long-term, perhaps we should rethink the laziness of these free lists.
3232
3233         * bmalloc/BoundaryTag.h:
3234         (bmalloc::BoundaryTag::isMarked):
3235         (bmalloc::BoundaryTag::setMarked): New bit, used by free list GC.
3236
3237         * bmalloc/FreeList.cpp:
3238         (bmalloc::FreeList::removeInvalidAndDuplicateEntries): The GC algorithm.
3239
3240         * bmalloc/FreeList.h:
3241         (bmalloc::FreeList::FreeList):
3242         (bmalloc::FreeList::push): Invoke the GC if we're getting huge.
3243
3244         * bmalloc/LargeObject.h:
3245         (bmalloc::LargeObject::isMarked):
3246         (bmalloc::LargeObject::setMarked):
3247         (bmalloc::LargeObject::validateSelf): Expose the new bit.
3248
3249         * bmalloc/Sizes.h: New constant to control GC frequency.
3250
3251 2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>
3252
3253         URTBF after r180693.
3254
3255         * CMakeLists.txt:
3256
3257 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
3258
3259         Try to fix the Mac build.
3260
3261         Unreviewed.
3262
3263         * bmalloc.xcodeproj/project.pbxproj: Make FreeList.h available.
3264
3265 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
3266
3267         bmalloc: Refactored SegregatedFreeList and BoundaryTag::init
3268         https://bugs.webkit.org/show_bug.cgi?id=142049
3269
3270         Reviewed by Anders Carlsson.
3271
3272         Split out a FreeList class from SegregatedFreeList. This will make it
3273         easier to add behaviors on free list insertion and removal -- and it's
3274         probably how I should have designed things at the start.
3275
3276         Moved BoundaryTag::init into LargeObject, since all the related logic
3277         lives in LargeObject now too, and this allows us to remove BoundaryTagInlines.h.
3278
3279         * bmalloc.xcodeproj/project.pbxproj:
3280         * bmalloc/BoundaryTagInlines.h: Removed.
3281         * bmalloc/FreeList.cpp: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.cpp.
3282         (bmalloc::FreeList::takeGreedy):
3283         (bmalloc::FreeList::take):
3284         (bmalloc::SegregatedFreeList::SegregatedFreeList): Deleted.
3285         (bmalloc::SegregatedFreeList::insert): Deleted.
3286         (bmalloc::SegregatedFreeList::takeGreedy): Deleted.
3287         (bmalloc::SegregatedFreeList::take): Deleted.
3288         * bmalloc/FreeList.h: Copied from Source/bmalloc/bmalloc/SegregatedFreeList.h.
3289         (bmalloc::FreeList::push):
3290         * bmalloc/LargeObject.h:
3291         (bmalloc::LargeObject::init):
3292         * bmalloc/SegregatedFreeList.cpp:
3293         (bmalloc::SegregatedFreeList::SegregatedFreeList):
3294         (bmalloc::SegregatedFreeList::insert):
3295         (bmalloc::SegregatedFreeList::takeGreedy):
3296         (bmalloc::SegregatedFreeList::take):
3297         * bmalloc/SegregatedFreeList.h:
3298         * bmalloc/Sizes.h:
3299         * bmalloc/VMHeap.cpp:
3300         (bmalloc::VMHeap::grow):
3301
3302 2015-02-26  Geoffrey Garen  <ggaren@apple.com>
3303
3304         bmalloc: free up a bit in BoundaryTag
3305         https://bugs.webkit.org/show_bug.cgi?id=142048
3306
3307         Reviewed by Brady Eidson.
3308
3309         We were wasting a bit by accident, and I need one now.
3310
3311         * bmalloc/Algorithm.h:
3312         (bmalloc::rightShift): Deleted. Not needed, now that I've simplified
3313         the math.
3314
3315         * bmalloc/BoundaryTag.h: Since each boundary tag bucket is 1024 bytes
3316         long, the maximum offset into a bucket is 1023.
3317
3318         You need 5 bits to count up to 1024, but only 4 to count up to 1023.
3319         
3320         Math is hard.
3321
3322         (bmalloc::BoundaryTag::compactBegin): Switched to division because it
3323         is simpler, and easier to match up with our ASSERT. The compiler will
3324         turn division by constant power of two into a shift for us.
3325
3326         (bmalloc::BoundaryTag::setRange): Added an ASSERT for compactBegin
3327         because we do encode it, so we should ASSERT that encoding did not
3328         lose information.
3329
3330         * bmalloc/Sizes.h: Shifting is no longer used since we use division
3331         instead.
3332
3333 2015-02-24  Stephanie Lewis  <slewis@apple.com>
3334
3335         Rolling out http://trac.webkit.org/changeset/180430 as it causes the PLT to crash.
3336         <rdar://problem/19948015>
3337
3338         Unreviewed.
3339
3340         * bmalloc/VMHeap.cpp:
3341         (bmalloc::VMHeap::grow):
3342         * bmalloc/VMHeap.h:
3343         * bmalloc/Zone.cpp:
3344         (bmalloc::Zone::Zone):
3345         (bmalloc::Zone::size): Deleted.
3346         * bmalloc/Zone.h:
3347
3348 2015-02-24  Geoffrey Garen  <ggaren@apple.com>
3349
3350         bmalloc: Added a little more abstraction for large objects
3351         https://bugs.webkit.org/show_bug.cgi?id=141978
3352
3353         Reviewed by Sam Weinig.
3354
3355         Previously, each client needed to manage the boundary tags of
3356         a large object using free functions. This patch introduces a LargeObject
3357         class that does things a little more automatically.
3358
3359         * bmalloc.xcodeproj/project.pbxproj:
3360
3361         * bmalloc/Allocator.cpp:
3362         (bmalloc::Allocator::reallocate): Use the new LargeObject class.
3363
3364         * bmalloc/BeginTag.h:
3365         (bmalloc::BeginTag::isInFreeList): Deleted. Moved this logic into the
3366         LargeObject class.
3367
3368         * bmalloc/BoundaryTag.h:
3369         (bmalloc::BoundaryTag::isSentinel):
3370         (bmalloc::BoundaryTag::compactBegin):
3371         (bmalloc::BoundaryTag::setRange):
3372         (bmalloc::BoundaryTag::initSentinel): Added an explicit API for sentinels,
3373         which we used to create and test for implicitly.
3374
3375         * bmalloc/BoundaryTagInlines.h:
3376         (bmalloc::BoundaryTag::init):
3377         (bmalloc::validate): Deleted.
3378         (bmalloc::validatePrev): Deleted.
3379         (bmalloc::validateNext): Deleted.
3380         (bmalloc::BoundaryTag::mergeLeft): Deleted.
3381         (bmalloc::BoundaryTag::mergeRight): Deleted.
3382         (bmalloc::BoundaryTag::merge): Deleted.
3383         (bmalloc::BoundaryTag::deallocate): Deleted.
3384         (bmalloc::BoundaryTag::split): Deleted.
3385         (bmalloc::BoundaryTag::allocate): Deleted. Moved this logic into the
3386         LargeObject class.
3387
3388         * bmalloc/EndTag.h:
3389         (bmalloc::EndTag::init):
3390         (bmalloc::EndTag::operator=): Deleted. Re-reading this code, I found
3391         special behavior in the assignment operator to be a surprising API.
3392         So, I replaced the assignment operation with an explicit initializing
3393         function.
3394
3395         * bmalloc/Heap.cpp:
3396         (bmalloc::Heap::scavengeLargeRanges):
3397         (bmalloc::Heap::allocateXLarge):
3398         (bmalloc::Heap::findXLarge):
3399         (bmalloc::Heap::deallocateXLarge):
3400         (bmalloc::Heap::allocateLarge):
3401         (bmalloc::Heap::deallocateLarge):
3402         * bmalloc/Heap.h: No behavior changes here -- just adopting the
3403         LargeObject interface.
3404
3405         * bmalloc/LargeObject.h: Added.
3406         (bmalloc::LargeObject::operator!):
3407         (bmalloc::LargeObject::begin):
3408         (bmalloc::LargeObject::size):
3409         (bmalloc::LargeObject::range):
3410         (bmalloc::LargeObject::LargeObject):
3411         (bmalloc::LargeObject::setFree):
3412         (bmalloc::LargeObject::isFree):
3413         (bmalloc::LargeObject::hasPhysicalPages):
3414         (bmalloc::LargeObject::setHasPhysicalPages):
3415         (bmalloc::LargeObject::isValidAndFree):
3416         (bmalloc::LargeObject::merge):
3417         (bmalloc::LargeObject::split):
3418         (bmalloc::LargeObject::validateSelf):
3419         (bmalloc::LargeObject::validate): Moved this code into a class, out of
3420         BoundaryTag free functions.
3421
3422         New to the class are these features:
3423
3424             (1) Every reference to an object is validated upon creation and use.
3425
3426             (2) There's an explicit API for "This is a reference to an object
3427             that might be stale (the DoNotValidate API)".
3428
3429             (3) The begin and end tags are kept in sync automatically.
3430
3431         * bmalloc/SegregatedFreeList.cpp:
3432         (bmalloc::SegregatedFreeList::insert):
3433         (bmalloc::SegregatedFreeList::takeGreedy):
3434         (bmalloc::SegregatedFreeList::take):
3435         * bmalloc/SegregatedFreeList.h: Adopt the LargeObject interface.
3436
3437         * bmalloc/VMHeap.cpp:
3438         (bmalloc::VMHeap::grow):
3439         * bmalloc/VMHeap.h:
3440         (bmalloc::VMHeap::allocateLargeRange):
3441         (bmalloc::VMHeap::deallocateLargeRange): Adopt the LargeObject interface.
3442
3443 2015-02-20  Geoffrey Garen  <ggaren@apple.com>
3444
3445         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
3446         https://bugs.webkit.org/show_bug.cgi?id=141802
3447
3448         Reviewed by Andreas Kling.
3449
3450         Rolling back in with a fix for a crash seen while using GuardMalloc.
3451
3452         * bmalloc/VMHeap.cpp:
3453         (bmalloc::VMHeap::grow):
3454         * bmalloc/VMHeap.h:
3455         * bmalloc/Zone.cpp: Re-land the old patch.
3456
3457         (bmalloc::Zone::size): Be sure to implement the size() function since
3458         it's accessible indirectly via the malloc_zone_from_ptr public API --
3459         and GuardMalloc calls it all the time.
3460
3461         (bmalloc::Zone::Zone):
3462         * bmalloc/Zone.h: Re-land the old patch.
3463
3464 2015-02-19  Commit Queue  <commit-queue@webkit.org>
3465
3466         Unreviewed, rolling out r180363.
3467         https://bugs.webkit.org/show_bug.cgi?id=141814
3468
3469         Caused >50 crashes when running LayoutTests in GuardMalloc or
3470         ASAN modes. (Requested by jernoble on #webkit).
3471
3472         Reverted changeset:
3473
3474         "bmalloc should implement malloc introspection (to stop false-
3475         positive leaks when MallocStackLogging is off)"
3476         https://bugs.webkit.org/show_bug.cgi?id=141802
3477         http://trac.webkit.org/changeset/180363
3478
3479 2015-02-19  Geoffrey Garen  <ggaren@apple.com>
3480
3481         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
3482         https://bugs.webkit.org/show_bug.cgi?id=141802
3483
3484         Reviewed by Andreas Kling.
3485
3486         Fixed a last-minute type.
3487
3488         The macro is OS, not PLATFORM.
3489
3490         * bmalloc/VMHeap.cpp:
3491         (bmalloc::VMHeap::grow):
3492         * bmalloc/VMHeap.h:
3493         * bmalloc/Zone.h:
3494
3495 2015-02-19  Geoffrey Garen  <ggaren@apple.com>
3496
3497         bmalloc should implement malloc introspection (to stop false-positive leaks when MallocStackLogging is off)
3498         https://bugs.webkit.org/show_bug.cgi?id=141802
3499
3500         Reviewed by Andreas Kling.
3501
3502         This patch does the bare minimum to stop false positive leaks from
3503         being reported by the Darwin leaks tool. We register each super chunk
3504         as a single object, and then request that the leaks tool scan it.
3505
3506         * bmalloc.xcodeproj/project.pbxproj: Added an abstraction for the malloc
3507         zone introspection API.
3508
3509         * bmalloc/Algorithm.h: Missing #include.
3510
3511         * bmalloc/VMHeap.cpp:
3512         (bmalloc::VMHeap::grow):
3513         * bmalloc/VMHeap.h: Adopt the new abstraction.
3514
3515         * bmalloc/Zone.cpp: Added.
3516         (bmalloc::remoteRead): Helper for reading an object out of another process.
3517         (bmalloc::Zone::enumerator):
3518         (bmalloc::Zone::Zone): Register a malloc zone so that we will participate
3519         in introspection.
3520
3521         * bmalloc/Zone.h: Added.
3522         (bmalloc::Zone::superChunks):
3523         (bmalloc::Zone::addSuperChunk): Use a non-dynamically-allocated vector
3524         since our dynamic allocations will not be scanned by leaks since they
3525         will have the malloc VM tag.
3526
3527 2015-02-18  Geoffrey Garen  <ggaren@apple.com>
3528
3529         bmalloc: VMHeap should keep a record of all of its VM ranges (for malloc introspection)
3530         https://bugs.webkit.org/show_bug.cgi?id=141759
3531
3532         Reviewed by Andreas Kling.
3533
3534         * bmalloc.xcodeproj/project.pbxproj:
3535         * bmalloc/SuperChunk.h: Added.
3536         (bmalloc::SuperChunk::create):
3537         (bmalloc::SuperChunk::SuperChunk):
3538         (bmalloc::SuperChunk::smallChunk):
3539         (bmalloc::SuperChunk::mediumChunk):
3540         (bmalloc::SuperChunk::largeChunk): Factored out super chunk creation
3541         into a separate class, for clarity and type safety.
3542
3543         * bmalloc/VMHeap.cpp:
3544         (bmalloc::VMHeap::grow):
3545         (bmalloc::VMHeap::allocateSuperChunk): Renamed "allocateSuperChunk" to
3546         "grow" because Andreas found "allocateSuperChunk" to be unclear.
3547
3548         * bmalloc/VMHeap.h: Track all our VM ranges. We will use this information
3549         for malloc introspection.
3550
3551         (bmalloc::VMHeap::allocateSmallPage):
3552         (bmalloc::VMHeap::allocateMediumPage):
3553         (bmalloc::VMHeap::allocateLargeRange): Updated for renames.
3554
3555 2015-02-18  Zan Dobersek  <zdobersek@igalia.com>
3556
3557         Build bmalloc through CMake as a static library. It's then linked either
3558         into the WTF library (if built as a shared library) or into the JSC and
3559         WebKit2 libraries. There's no need to build it as a standalone shared library.
3560
3561         Rubber-stamped by Carlos Garcia Campos.
3562
3563         * CMakeLists.txt:
3564
3565 2015-02-13  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
3566
3567         [BMalloc] Add a FIXME comment for memory alignas
3568         https://bugs.webkit.org/show_bug.cgi?id=141556
3569
3570         Reviewed by Csaba Osztrogonác.
3571
3572         * bmalloc/Chunk.h: Add a FIXME comment.
3573         * bmalloc/LargeChunk.h: ditto.
3574
3575 2015-02-11  Csaba Osztrogonác  <ossy@webkit.org>
3576
3577         bmalloc buildfix on 32 bit Linux (x86/ARM)
3578         https://bugs.webkit.org/show_bug.cgi?id=141472
3579
3580         Reviewed by Gyuyoung Kim.
3581
3582         * bmalloc/Algorithm.h:
3583         (bmalloc::roundUpToMultipleOf):
3584         * bmalloc/FixedVector.h:
3585         (bmalloc::FixedVector::clear):
3586         * bmalloc/Sizes.h:
3587         (bmalloc::Sizes::sizeClass):
3588
3589 2015-02-11  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
3590
3591         [EFL][GTK] Use bmalloc instead of tcmalloc
3592         https://bugs.webkit.org/show_bug.cgi?id=140162
3593
3594         Reviewed by Carlos Garcia Campos.
3595
3596         Support to use bmalloc on EFL and GTK ports.
3597
3598         * CMakeLists.txt: Added.
3599         * bmalloc/Allocator.cpp:
3600         (bmalloc::Allocator::allocate):
3601             Fix unused return value caused by posix_memalign().
3602         * bmalloc/AsyncTask.h:
3603         * bmalloc/BoundaryTag.h:
3604         (bmalloc::BoundaryTag::clear):
3605         * bmalloc/Chunk.h:
3606             Change Traits::Page with Traits::PageType in order to fix
3607             -fpermitive build error on EFL and GTK port. 
3608         * bmalloc/EndTag.h:
3609         (bmalloc::EndTag::operator=):
3610         * bmalloc/Line.h: ditto.
3611         * bmalloc/MediumTraits.h:
3612         * bmalloc/Page.h: ditto.
3613         * bmalloc/PerThread.h:
3614             EFL port doesn't support __has_include definition yet.
3615             Define HAVE_PTHREAD_MACHDEP_H according to check if __has_include is supported.
3616         * bmalloc/SmallTraits.h: ditto.
3617         * bmalloc/VMAllocate.h:
3618         (bmalloc::vmDeallocatePhysicalPages):
3619         (bmalloc::vmAllocatePhysicalPages):
3620         * bmalloc/Vector.h:
3621         (bmalloc::Vector<T>::push):
3622         (bmalloc::Vector<T>::reallocateBuffer):
3623
3624 2015-01-31  Sam Weinig  <sam@webkit.org>
3625
3626         Remove even more Mountain Lion support
3627         https://bugs.webkit.org/show_bug.cgi?id=141124
3628
3629         Reviewed by Alexey Proskuryakov.
3630
3631         * Configurations/Base.xcconfig:
3632         * Configurations/DebugRelease.xcconfig:
3633
3634 2015-01-30  Geoffrey Garen  <ggaren@apple.com>
3635
3636         GC marking threads should clear malloc caches
3637         https://bugs.webkit.org/show_bug.cgi?id=141097
3638
3639         Reviewed by Andreas Kling.
3640
3641         Split the scavenging API into per-thread vs global, so that you can
3642         request to scavenge your own thread without scavenging the whole heap.
3643
3644         * bmalloc/Cache.cpp:
3645         (bmalloc::Cache::scavenge):
3646         * bmalloc/bmalloc.h:
3647         (bmalloc::api::scavengeThisThread):
3648         (bmalloc::api::scavenge):
3649
3650 2015-01-28  Dana Burkart  <dburkart@apple.com>
3651
3652         Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
3653         https://bugs.webkit.org/show_bug.cgi?id=136765
3654
3655         Reviewed by Alexey Proskuryakov.
3656
3657         * Configurations/Base.xcconfig:
3658         * Configurations/DebugRelease.xcconfig:
3659
3660 2015-01-21  Geoffrey Garen  <ggaren@apple.com>
3661
3662         bmalloc: support aligned allocation
3663         https://bugs.webkit.org/show_bug.cgi?id=140732
3664
3665         Reviewed by Andreas Kling.
3666
3667         * bmalloc/Allocator.cpp:
3668         (bmalloc::Allocator::allocate): New function for aligned allocation.
3669
3670         Small and medium requests just allocate and free until they find an
3671         aligned pointer. This is slightly inefficient in the worst case, but
3672         still constant-time with little-to-no space overhead.
3673
3674         Large requests use a new API that requires the client to specify both
3675         its ideal size and alignment, and the worst-case size you would have to
3676         allocate in order to produce some interior pointer of the requested size
3677         and alignment. We put the burden of this calculation on the client
3678         because it simplifies things if we guarantee that allocation won't fail.
3679
3680         XLarge requests are easy: we just forward them to vmAllocate, which
3681         already supported aligned requests.
3682
3683         * bmalloc/BoundaryTag.h:
3684         * bmalloc/BoundaryTagInlines.h:
3685         (bmalloc::BoundaryTag::mergeLeft):
3686         (bmalloc::BoundaryTag::mergeRight):
3687         (bmalloc::BoundaryTag::merge):
3688         (bmalloc::BoundaryTag::deallocate):
3689         (bmalloc::BoundaryTag::split):
3690         (bmalloc::BoundaryTag::allocate): No behavior change here. I just
3691         refactored the interface to remove some reference out parameters in
3692         order to clarify what changes and what doesn't.
3693
3694         * bmalloc/Heap.cpp:
3695         (bmalloc::Heap::allocateXLarge): Added an alignment API.
3696
3697         (bmalloc::Heap::allocateLarge):
3698         * bmalloc/Heap.h: Added an alignment API. I split out allocateLarge into
3699         a few variants, so aligned and unaligned allocation could share some code.
3700
3701         * bmalloc/SegregatedFreeList.cpp:
3702         (bmalloc::SegregatedFreeList::take):
3703         * bmalloc/SegregatedFreeList.h: Changed to use a separate, explicit API
3704         for aligned allocation. It turns out that the aligned path is pretty
3705         different, since it ends up searching for two potential ways to satisfy
3706         an allocation: either large enough and aligned, or large enough to split
3707         into something not aligned and something large enough and aligned.
3708
3709         * bmalloc/VMAllocate.h:
3710         (bmalloc::vmAllocate): Switched alignment to come before size because
3711         that's how the memalign API specifies it.
3712
3713         * bmalloc/VMHeap.h:
3714         (bmalloc::VMHeap::allocateLargeRange): Added an alignment API.
3715
3716 2015-01-20  Geoffrey Garen  <ggaren@apple.com>
3717
3718         bmalloc: a little bit of cleanup
3719         https://bugs.webkit.org/show_bug.cgi?id=140687
3720
3721         Reviewed by Anders Carlsson.
3722
3723         * bmalloc/Algorithm.h:
3724         (bmalloc::isPowerOfTwo): Added a check for 0, since 0 would break a lot
3725         of code.
3726
3727         * bmalloc/BoundaryTag.h:
3728         * bmalloc/BoundaryTagInlines.h:
3729         (bmalloc::BoundaryTag::mergeLeft):
3730         (bmalloc::BoundaryTag::mergeRight):
3731         (bmalloc::BoundaryTag::merge):
3732         (bmalloc::BoundaryTag::deallocate):
3733         (bmalloc::BoundaryTag::split):
3734         (bmalloc::BoundaryTag::allocate):
3735         (bmalloc::BoundaryTag::mergeLargeLeft): Deleted.
3736         (bmalloc::BoundaryTag::mergeLargeRight): Deleted.
3737         (bmalloc::BoundaryTag::mergeLarge): Deleted.
3738         (bmalloc::BoundaryTag::splitLarge): Deleted. Removed the word "Large"
3739         from all these functions, since boundary tags always pertain to large
3740         objects, and putting the word "Large" everywhere wasn't helping to
3741         explain that.
3742
3743         * bmalloc/Heap.cpp:
3744         (bmalloc::Heap::allocateXLarge):
3745         (bmalloc::Heap::findXLarge):
3746         (bmalloc::Heap::deallocateXLarge):
3747         * bmalloc/Heap.h:
3748         * bmalloc/VMHeap.h:
3749         (bmalloc::VMHeap::allocateXLarge): Deleted.
3750         (bmalloc::VMHeap::findXLarge): Deleted.
3751         (bmalloc::VMHeap::deallocateXLarge): Deleted. Moved XLarge allocation
3752         from VMHeap to Heap. Since the purpose of the VMHeap is to cache VM
3753         ranges, and the VMHeap never caches any XLarge ranges, it doesn't
3754         really make sense for the VMHeap to be involved.
3755
3756 2015-01-16  Geoffrey Garen  <ggaren@apple.com>
3757
3758         bmalloc: refactored XLarge allocation for better alignment
3759         https://bugs.webkit.org/show_bug.cgi?id=140582
3760
3761         Reviewed by Andreas Kling.
3762
3763         XLarge objects used to be Large objects with an extra bit of metadata
3764         that said "actually, I'm not large -- I'm extra large".
3765
3766         The metadata header in an XLarge allocation made it impossible for the
3767         XLarge object to honor a very large alignment request.
3768
3769         The solution is to stop using a metadata header for XLarge objects, and
3770         instead to store explicit metadata on the side.
3771
3772         This is a bit less astonishing, which is also nice.
3773
3774         Finding XLarge metadata is now a linear search. That's probably OK, since
3775         it was always so in TCMalloc, and the usual number of XLarge allocations
3776         in a process is 0.
3777
3778         This design makes it possible for the heap to cache XLarge allocations
3779         with and/or without physical pages. I haven't actually done that yet
3780         because the tradeoffs are subtle, so I don't want to do anything without
3781         a motivating test case.
3782
3783         * bmalloc.xcodeproj/project.pbxproj:
3784         * bmalloc/Allocator.cpp:
3785         (bmalloc::Allocator::reallocate): Removed the concept of an XLargeChunk,
3786         since an XLarge allocation is now just a naked buffer without a header.
3787
3788         (bmalloc::Allocator::allocateXLarge): Added an explicit qualifier for
3789         XLarge alignment, since XLargeChunk won't give this to us implicitly
3790         anymore.
3791
3792         * bmalloc/BoundaryTag.h:
3793         (bmalloc::BoundaryTag::setRange):
3794         (bmalloc::BoundaryTag::isXLarge): Deleted.
3795         (bmalloc::BoundaryTag::setXLarge): Deleted.
3796         * bmalloc/BoundaryTagInlines.h:
3797         (bmalloc::validate):
3798         (bmalloc::BoundaryTag::deallocate): Removed the XLarge hacks from Large allocations.
3799
3800         * bmalloc/Deallocator.cpp:
3801         (bmalloc::Deallocator::deallocateXLarge):
3802         (bmalloc::Deallocator::deallocateSlowCase):
3803         * bmalloc/Heap.cpp:
3804         (bmalloc::Heap::findXLarge):
3805         (bmalloc::Heap::allocateXLarge):
3806         (bmalloc::Heap::deallocateXLarge):
3807         * bmalloc/Heap.h: Updated for interface changes.
3808
3809         * bmalloc/ObjectType.cpp:
3810         (bmalloc::objectType):
3811         * bmalloc/ObjectType.h:
3812         (bmalloc::isXLarge): We can now tell if a pointer is XLarge just by
3813         examining its bit pattern -- just like we do for other kinds of
3814         allocations -- which is nice.
3815
3816         * bmalloc/Sizes.h:
3817         * bmalloc/VMHeap.h:
3818         (bmalloc::VMHeap::allocateXLarge):
3819         (bmalloc::VMHeap::findXLarge):
3820         (bmalloc::VMHeap::deallocateXLarge): Keep an explicit vector of metadata
3821         for XLarge allocations.
3822
3823         * bmalloc/XLargeChunk.h: Removed.
3824
3825 2015-01-16  Geoffrey Garen  <ggaren@apple.com>
3826
3827         bmalloc: added some infrastructure for aligned allocation
3828         https://bugs.webkit.org/show_bug.cgi?id=140572
3829
3830         Reviewed by Andreas Kling.
3831
3832         * bmalloc/Algorithm.h:
3833         (bmalloc::isPowerOfTwo):
3834         (bmalloc::roundUpToMultipleOf):
3835         (bmalloc::roundDownToMultipleOf): Refactored some duplicate code to use our
3836         isPowerOfTwo helper function.
3837
3838         * bmalloc/Allocator.cpp:
3839         (bmalloc::Allocator::allocate):
3840         * bmalloc/Allocator.h: Stubbed out an implementation of aligned allocation.
3841         Doesn't do anything yet, but does correctly forward to system malloc
3842         when bmalloc is disabled.
3843
3844         * bmalloc/Cache.cpp:
3845         (bmalloc::Cache::allocateSlowCaseNullCache):
3846         * bmalloc/Cache.h:
3847         (bmalloc::Cache::allocate):
3848         * bmalloc/bmalloc.h:
3849         (bmalloc::api::memalign):
3850         * bmalloc/mbmalloc.cpp: Stubbed out an API for aligned allocation.
3851
3852 2015-01-13  Geoffrey Garen  <ggaren@apple.com>
3853
3854         Consider alignment when allocating from a SegregatedFreeList
3855         https://bugs.webkit.org/show_bug.cgi?id=140408
3856
3857         Reviewed by Sam Weinig.
3858
3859         In preparation for supporting aligned allocation.
3860
3861         No performance change.
3862
3863         Since this is just one extra branch in an already expensive function,
3864         I decided not to duplicate the function just to avoid the branch in
3865         the un-aligned case.
3866
3867         * bmalloc/SegregatedFreeList.cpp:
3868         (bmalloc::SegregatedFreeList::take):
3869         * bmalloc/SegregatedFreeList.h:
3870
3871 2015-01-13  Geoffrey Garen  <ggaren@apple.com>
3872
3873         Renamed minimum to size in SegregatedFreeList
3874         https://bugs.webkit.org/show_bug.cgi?id=140406
3875
3876         Reviewed by Sam Weinig.
3877
3878         In preparation for supporting aligned allocation.
3879
3880         * bmalloc/SegregatedFreeList.cpp:
3881         (bmalloc::SegregatedFreeList::takeGreedy):
3882         (bmalloc::SegregatedFreeList::take): Every size passed to malloc is
3883         really just a minimum. Let's not imply that this value is special.
3884
3885 2015-01-11  Dan Bernstein  <mitz@apple.com>
3886
3887         Geoff is organized, but he is not an organization.
3888
3889         Rubber-stamped by Anders Carlsson.
3890
3891         * bmalloc.xcodeproj/project.pbxproj: Removed the ORGANIZATIONNAME project attribute.
3892
3893 2015-01-07  Geoffrey Garen  <ggaren@apple.com>
3894
3895         Make bmalloc work with ASan
3896         https://bugs.webkit.org/show_bug.cgi?id=140194
3897
3898         Reviewed by Mark Lam.
3899
3900         * bmalloc/BPlatform.h: Added a way to detect Darwin OSes, since we need
3901         an OS-specific API to test for loaded runtime libraries.
3902
3903         * bmalloc/Environment.cpp:
3904         (bmalloc::isASanEnabled):
3905         (bmalloc::Environment::computeIsBmallocEnabled): Disabled bmalloc if
3906         ASan is enabled, since system malloc has the Asan hooks we need.
3907
3908         You could check for the ASan compile-time flag instead, but doing this
3909         check at runtime prepares bmalloc for a world where it is a dynamic
3910         library that might be loaded into projects it did not compile with.
3911
3912 2015-01-05  Geoffrey Garen  <ggaren@apple.com>
3913
3914         Fix up bmalloc's PerThread for use on Linux
3915         https://bugs.webkit.org/show_bug.cgi?id=139804
3916
3917         Reviewed by Anders Carlsson.
3918
3919         The previous implementation was a bit slow.
3920
3921         * bmalloc/PerThread.h:
3922         (bmalloc::PerThreadStorage<Cache>::get):
3923         (bmalloc::PerThreadStorage::get):
3924         (bmalloc::PerThreadStorage::init): Added a catch-all cross-platform Unix
3925         way to do fast per-thread access without taking a lock every time. This
3926         probably works on all the platforms we care about, and it matches other
3927         techniques we use elsewhere in WebKit.
3928
3929         (bmalloc::PerThread<T>::getFastCase): Removed the conditional from
3930         this class because PerThreadStorage now encapsulates everything that
3931         needs to be conditional.
3932
3933         (bmalloc::PerThreadStorage::initSharedKeyIfNeeded): Deleted.
3934
3935 2014-12-26  Dan Bernstein  <mitz@apple.com>
3936
3937         <rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
3938         https://bugs.webkit.org/show_bug.cgi?id=139950
3939
3940         Reviewed by David Kilzer.
3941
3942         * Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
3943         in a manner that works with Xcode 5.1.1.
3944
3945 2014-12-15  Geoffrey Garen  <ggaren@apple.com>
3946
3947         Safari crashes when you set Malloc environment variables
3948         https://bugs.webkit.org/show_bug.cgi?id=139656
3949
3950         Reviewed by Michael Saboff.
3951
3952         I forgot to cover the realloc() case. Whoops. (OoPS?)
3953
3954         This time around, I ran the full MallocBench test suite in Malloc=1
3955         mode, and it passed.
3956
3957         * bmalloc/Allocator.cpp:
3958         (bmalloc::Allocator::reallocate):
3959         * bmalloc/Allocator.h: Pushed realloc() logic down into the allocator.
3960         It needs to be down there so that we can do the short-circuiting check
3961         for whether bmalloc is enabled first.
3962
3963         Also added the check.
3964
3965         * bmalloc/Cache.cpp:
3966         (bmalloc::Cache::scavenge):
3967         (bmalloc::Cache::Cache):
3968         (bmalloc::Cache::reallocateSlowCaseNullCache):
3969         * bmalloc/Cache.h:
3970         (bmalloc::Cache::deallocator):
3971         (bmalloc::Cache::reallocate): Ditto.
3972
3973         * bmalloc/bmalloc.h:
3974         (bmalloc::api::free):
3975         (bmalloc::api::realloc): Ditto.
3976
3977         (bmalloc::api::scavenge): Pushed this down into Cache to match the
3978         surrounding functions.
3979
3980 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
3981
3982         bmalloc should support system memory analysis tools (part 2)
3983         https://bugs.webkit.org/show_bug.cgi?id=139565
3984
3985         Reviewed by Mark Lam.
3986
3987         This patch actually queries the environment to see if memory analysis
3988         tools have been enabled.
3989
3990         * bmalloc/Deallocator.cpp:
3991         (bmalloc::Deallocator::scavenge): Don't process the object log if
3992         we've disabled bmalloc because it will be full of invalid nullptrs.
3993
3994         * bmalloc/Environment.cpp:
3995         (bmalloc::isMallocEnvironmentVariableSet): Test for the list of known
3996         Malloc debugging flags. I also added a plain "Malloc" catch-all for
3997         when you want to disable bmalloc without enabling any kind of funny
3998         business.
3999
4000         It would be slightly nicer just to iterate the list of environment
4001         variables and strstr them, but getenv is the more portable option,
4002         and performance here doesn't really matter.
4003
4004         (bmalloc::isLibgmallocEnabled): Test for the libgmalloc insertion
4005         environment variable.
4006
4007         (bmalloc::Environment::computeIsBmallocEnabled):
4008
4009 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
4010
4011         Try to fix the iOS simulator build.
4012
4013         #include the declaration of malloc / free.
4014
4015         * bmalloc/Allocator.cpp:
4016         * bmalloc/Deallocator.cpp:
4017
4018 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
4019
4020         Try to fix the build.
4021
4022         * bmalloc.xcodeproj/project.pbxproj: Marked a header exported.
4023
4024 2014-12-11  Geoffrey Garen  <ggaren@apple.com>
4025
4026         bmalloc should support system memory analysis tools (part 1)
4027         https://bugs.webkit.org/show_bug.cgi?id=139559
4028
4029         Reviewed by Mark Lam.
4030
4031         This patch adds the hooks to disable bmalloc at runtime if certain
4032         environment variables are set, but doesn't actually read from the
4033         environment yet.
4034
4035         No performance change.
4036
4037         * bmalloc.xcodeproj/project.pbxproj: Added the Environment class, which
4038         we'll use to read environment variables and see if memory analysis tools
4039         have been enabled.
4040
4041         * bmalloc/Allocator.cpp:
4042         (bmalloc::Allocator::Allocator):
4043         (bmalloc::Allocator::allocateSlowCase): Added a hook to disable bmalloc
4044         on the allocation path. We cache the setting to make the check fast.
4045
4046         * bmalloc/Allocator.h: Interface changes.
4047
4048         * bmalloc/Cache.cpp:
4049         (bmalloc::Cache::Cache): Pass a heap pointer through to our allocator
4050         and deallocator. This main purpose is to enable them to query the
4051         environment for whether bmalloc is enabled; but this is also a slightly
4052         cleaner way to guarantee to them that the Heap has been pre-initialized.
4053
4054         * bmalloc/Deallocator.cpp:
4055         (bmalloc::Deallocator::Deallocator): If bmalloc is disable, artificially
4056         fill the object log to force us to take the slow path on all deallocations.
4057