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