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