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