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