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