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