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