Enable Gigacage unconditionally when building JSCOnly on macOS (build fix)
[WebKit-https.git] / Source / bmalloc / ChangeLog
1 2018-04-04  Konstantin Tokarev  <annulen@yandex.ru>
2
3         Enable Gigacage unconditionally when building JSCOnly on macOS (build fix)
4         https://bugs.webkit.org/show_bug.cgi?id=184301
5
6         Reviewed by Yusuke Suzuki.
7
8         bmalloc/ProcessCheck.mm implements specific behavior for Mac and iOS ports,
9         which is guarded with BPLATFORM(COCOA). if we don't enable BPLATFORM(MAC)
10         or BPLATFORM(IOS) in JSCOnly, then BPLATFORM(COCOA) won't be defined
11         as well, and code path from ProcessCheck.mm will not be taken.
12
13         * CMakeLists.txt: Exclude ProcessCheck.mm from port-independent file
14         list.
15         * PlatformMac.cmake: Build ProcessCheck.mm for Mac port.
16         * bmalloc/BPlatform.h: Don't enable BPLATFORM(MAC) or BPLATFORM(IOS)
17         when building JSCOnly port.
18
19 2018-04-03  Saam Barati  <sbarati@apple.com>
20
21         totalPhysicalSize calculation when splitting a range must account for double rounding effects
22         https://bugs.webkit.org/show_bug.cgi?id=184275
23
24         Reviewed by Mark Lam.
25
26         The rounding error could happen when we split a range where the
27         range's total physical size equals the range's total size. The
28         rounding may cause the left size to lose a byte, and the right
29         size to gain a byte. This caused the right side to be a byte
30         large than its size.
31
32         * bmalloc/LargeRange.h:
33         (bmalloc::LargeRange::LargeRange):
34         (bmalloc::LargeRange::split const):
35
36 2018-04-02  Saam Barati  <sbarati@apple.com>
37
38         bmalloc should compute its own estimate of its footprint
39         https://bugs.webkit.org/show_bug.cgi?id=184121
40
41         Reviewed by Filip Pizlo.
42
43         This patch makes it so that bmalloc keeps track of its own physical
44         footprint.
45         
46         Doing this for IsoHeaps is trivial. It allocates/deallocates fixed
47         page sizes at a time. IsoHeapImpl just updates a count every time
48         a page is committed/decommitted.
49         
50         Making Heap keep its footprint was a bit trickier because of how
51         LargeRange is constructed. Before this patch, LargeRange kept track
52         of the amount of physical memory at the start of its range. This
53         patch extends large range to also keep track of the total physical memory
54         in the range just for footprint bookkeeping. This was needed to make
55         Heap's footprint come close to resembling reality, because as we merge and split
56         large ranges, the start physical size often becomes wildly inaccurate.
57         The total physical size number stored in LargeRange is still just an
58         estimate. It's possible that as ranges are split, that the total physical
59         size split amongst the two ranges doesn't resemble reality. This can
60         happen when the total physical size is really all in one end of the split,
61         but we mark it as being proportionally split amongst the resulting two
62         ranges. In practice, I did not notice this being a problem. The footprint
63         estimate tracks reality very closely (in my testing, within less than 1MB for
64         heaps with sizes upwards of 1GB). The other nice thing about total physical
65         size is that even if it diverges from reality in terms of how memory is
66         using up physical RAM, it stays internally consistent inside bmalloc's
67         own data structures.
68         
69         The main oversight of this patch is how it deals with Wasm memory. All Wasm
70         memory will be viewed by bmalloc as taking up physical space even when it
71         may not be. Wasm memory starts off as taking up purely virtual pages. When a
72         page is first accessed, only then will the OS page it in and cause it to use
73         physical RAM. I opened a bug to come up with a solution to this problem:
74         https://bugs.webkit.org/show_bug.cgi?id=184207
75
76         * bmalloc.xcodeproj/project.pbxproj:
77         * bmalloc/AvailableMemory.cpp:
78         (bmalloc::memoryStatus):
79         * bmalloc/BPlatform.h:
80         * bmalloc/Heap.cpp:
81         (bmalloc::Heap::Heap):
82         (bmalloc::Heap::freeableMemory):
83         (bmalloc::Heap::footprint):
84         (bmalloc::Heap::scavenge):
85         (bmalloc::Heap::deallocateSmallChunk):
86         (bmalloc::Heap::allocateSmallPage):
87         (bmalloc::Heap::splitAndAllocate):
88         (bmalloc::Heap::tryAllocateLarge):
89         (bmalloc::Heap::shrinkLarge):
90         (bmalloc::Heap::deallocateLarge):
91         (bmalloc::Heap::externalCommit):
92         (bmalloc::Heap::externalDecommit):
93         * bmalloc/Heap.h:
94         * bmalloc/IsoDirectory.h:
95         * bmalloc/IsoDirectoryInlines.h:
96         (bmalloc::passedNumPages>::takeFirstEligible):
97         (bmalloc::passedNumPages>::didDecommit):
98         (bmalloc::passedNumPages>::freeableMemory):
99         * bmalloc/IsoHeapImpl.h:
100         * bmalloc/IsoHeapImplInlines.h:
101         (bmalloc::IsoHeapImpl<Config>::freeableMemory):
102         (bmalloc::IsoHeapImpl<Config>::footprint):
103         (bmalloc::IsoHeapImpl<Config>::didCommit):
104         (bmalloc::IsoHeapImpl<Config>::didDecommit):
105         * bmalloc/LargeRange.h:
106         (bmalloc::LargeRange::LargeRange):
107         (bmalloc::LargeRange::startPhysicalSize const):
108         (bmalloc::LargeRange::setStartPhysicalSize):
109         (bmalloc::LargeRange::totalPhysicalSize const):
110         (bmalloc::LargeRange::setTotalPhysicalSize):
111         (bmalloc::merge):
112         (bmalloc::LargeRange::split const):
113         (bmalloc::LargeRange::physicalSize const): Deleted.
114         (bmalloc::LargeRange::setPhysicalSize): Deleted.
115         * bmalloc/PhysicalPageMap.h: Added.
116         This class is added for debugging purposes. It's useful when hacking
117         on the code that calculates the footprint to use this map as a sanity
118         check. It's just a simple implementation that has a set of all the committed pages.
119
120         (bmalloc::PhysicalPageMap::commit):
121         (bmalloc::PhysicalPageMap::decommit):
122         (bmalloc::PhysicalPageMap::footprint):
123         (bmalloc::PhysicalPageMap::forEachPhysicalPage):
124         * bmalloc/Scavenger.cpp:
125         (bmalloc::dumpStats):
126         (bmalloc::Scavenger::scavenge):
127         (bmalloc::Scavenger::freeableMemory):
128         This is here just for debugging for now. But we should implement an
129         efficient version of this to use when driving when to run the
130         scavenger.
131
132         (bmalloc::Scavenger::footprint):
133         (bmalloc::Scavenger::threadRunLoop):
134         * bmalloc/Scavenger.h:
135         * bmalloc/VMAllocate.h:
136         (bmalloc::physicalPageSizeSloppy):
137         * bmalloc/VMHeap.cpp:
138         (bmalloc::VMHeap::tryAllocateLargeChunk):
139         * bmalloc/bmalloc.cpp:
140         (bmalloc::api::commitAlignedPhysical):
141         (bmalloc::api::decommitAlignedPhysical):
142         * bmalloc/bmalloc.h:
143
144 2018-03-28  Commit Queue  <commit-queue@webkit.org>
145
146         Unreviewed, rolling out r230005.
147         https://bugs.webkit.org/show_bug.cgi?id=184115
148
149         "it caused a huge regression on iOS" (Requested by saamyjoon
150         on #webkit).
151
152         Reverted changeset:
153
154         "memoryStatus() is wrong in certain testing scenarios on iOS"
155         https://bugs.webkit.org/show_bug.cgi?id=184050
156         https://trac.webkit.org/changeset/230005
157
158 2018-03-27  Saam Barati  <sbarati@apple.com>
159
160         memoryStatus() is wrong in certain testing scenarios on iOS
161         https://bugs.webkit.org/show_bug.cgi?id=184050
162         <rdar://problem/37959258>
163
164         Rubber-stamped by Mark Lam.
165
166         This switches us from using "phys_footprint" to using "internal + compressed"
167         when computing the dirty memory in the current process. There are iOS testing
168         scenarios where phys_footprint doesn't give us a reliable answer. In my testing,
169         "internal + compressed" tracks phys_footprint closely (when phys_footprint is
170         working). They're usually within much less than 1% of each other. We're making
171         this change to ensure testing in our iOS infrastructure is valid.
172         
173         I opened a bug to move back to phys_footprint when it's feasible:
174         https://bugs.webkit.org/show_bug.cgi?id=184050
175
176         * bmalloc/AvailableMemory.cpp:
177         (bmalloc::memoryStatus):
178
179 2018-03-20  Tim Horton  <timothy_horton@apple.com>
180
181         Add and adopt WK_PLATFORM_NAME and adjust default feature defines
182         https://bugs.webkit.org/show_bug.cgi?id=183758
183         <rdar://problem/38017644>
184
185         Reviewed by Dan Bernstein.
186
187         * Configurations/Base.xcconfig:
188
189 2018-03-16  Filip Pizlo  <fpizlo@apple.com>
190
191         Put the DOM in IsoHeaps
192         https://bugs.webkit.org/show_bug.cgi?id=183546
193
194         Reviewed by Simon Fraser.
195         
196         Make it easy to runtime-disable IsoHeaps.
197
198         * bmalloc/Allocator.h:
199         * bmalloc/IsoTLS.cpp:
200         (bmalloc::IsoTLS::determineMallocFallbackState):
201         * bmalloc/IsoTLS.h:
202         * bmalloc/IsoTLSInlines.h:
203         (bmalloc::IsoTLS::allocateSlow):
204         (bmalloc::IsoTLS::deallocateSlow):
205
206 2018-03-16  Michael Catanzaro  <mcatanzaro@igalia.com>
207
208         Improve error message when Gigacage cannot allocate virtual memory
209         https://bugs.webkit.org/show_bug.cgi?id=183329
210
211         Reviewed by Filip Pizlo.
212
213         We've discovered that Deja Dup monitor sets a virtual memory limit, breaking Gigacage. Since
214         it runs in the background on a fresh out-of-the-box install of Ubuntu, this is not good.
215         That will have to be fixed by Deja Dup, but there is concern that other applications might
216         try this, or that users will set a virtual memory limit for the entire desktop session. Of
217         particular concern is the possibility that users might have copypasted a ulimit line into
218         a session startup script without understanding it. Let's try to make it slightly easier to
219         understand what's going wrong.
220
221         * bmalloc/Gigacage.cpp:
222         (Gigacage::ensureGigacage):
223
224 2018-03-13  Tim Horton  <timothy_horton@apple.com>
225
226         Add and adopt WK_ALTERNATE_FRAMEWORKS_DIR in WTF and bmalloc
227         https://bugs.webkit.org/show_bug.cgi?id=183576
228         <rdar://problem/38396766>
229
230         Reviewed by Dan Bernstein.
231
232         * Configurations/Base.xcconfig:
233         * Configurations/bmalloc.xcconfig:
234         * Configurations/mbmalloc.xcconfig:
235
236 2018-03-10  Filip Pizlo  <fpizlo@apple.com>
237
238         PerProcess<> should be safe by default
239         https://bugs.webkit.org/show_bug.cgi?id=183545
240
241         Reviewed by Yusuke Suzuki.
242         
243         This makes PerProcess<> safe by default, so we don't need SafePerProcess<>.
244         
245         The new PerProcess<> design relies on a hash-consing mechanism for PerProcess<> storage based
246         on the __PRETTY_FUNCTION__ from inside PerProcess<>, which captures the instantiated type in
247         the string. Therefore, this can be used to runtime-coalesce PerProcess<> instances based on
248         type.
249         
250         I expect this to be perf-neutral. It's an important prerequisite to more bmalloc work, since I
251         don't want to have more PerProcess<> vs SafePerProcess<> bugs, and SafePerProcess<> can't be
252         used for everything (I don't see how to use it for isoheaps).
253
254         * CMakeLists.txt:
255         * bmalloc.xcodeproj/project.pbxproj:
256         * bmalloc/Heap.cpp:
257         (bmalloc::Heap::Heap):
258         * bmalloc/IsoDirectoryInlines.h:
259         (bmalloc::passedNumPages>::takeFirstEligible):
260         (bmalloc::passedNumPages>::didBecome):
261         * bmalloc/PerProcess.cpp: Added.
262         (bmalloc::stringHash):
263         (bmalloc::allocate):
264         (bmalloc::getPerProcessData):
265         * bmalloc/PerProcess.h:
266         (bmalloc::PerProcess::mutex):
267         (bmalloc::PerProcess::coalesce):
268         (bmalloc::PerProcess::getSlowCase):
269         (): Deleted.
270         * bmalloc/Scavenger.cpp:
271         * bmalloc/Scavenger.h:
272         * bmalloc/bmalloc.cpp:
273         (bmalloc::api::scavenge):
274         (bmalloc::api::setScavengerThreadQOSClass):
275
276 2018-03-10  Commit Queue  <commit-queue@webkit.org>
277
278         Unreviewed, rolling out r229436.
279         https://bugs.webkit.org/show_bug.cgi?id=183542
280
281         seems to have regressed wasm compile times by 10% (Requested
282         by pizlo-mbp on #webkit).
283
284         Reverted changeset:
285
286         "bmalloc mutex should be adaptive"
287         https://bugs.webkit.org/show_bug.cgi?id=177839
288         https://trac.webkit.org/changeset/229436
289
290 2018-03-08  Filip Pizlo  <fpizlo@apple.com>
291
292         bmalloc mutex should be adaptive
293         https://bugs.webkit.org/show_bug.cgi?id=177839
294
295         Reviewed by Michael Saboff.
296         
297         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
298         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
299         anything other than malloc.
300
301         Reland after failing to reproduce the WasmBench crash that caused it to get rolled out. Maybe that fixed
302         itself somehow?
303
304         * bmalloc/Algorithm.h:
305         (bmalloc::compareExchangeWeak):
306         (bmalloc::compareExchangeStrong):
307         * bmalloc/PerThread.h:
308         * bmalloc/StaticMutex.cpp:
309         (bmalloc::StaticMutex::lockSlow):
310         (bmalloc::StaticMutex::unlockSlow):
311         (bmalloc::StaticMutex::lockSlowCase): Deleted.
312         * bmalloc/StaticMutex.h:
313         (bmalloc::StaticMutex::try_lock):
314         (bmalloc::StaticMutex::isLocked const):
315         (bmalloc::StaticMutex::init):
316         (bmalloc::StaticMutex::tryLock):
317         (bmalloc::StaticMutex::lock):
318         (bmalloc::StaticMutex::unlock):
319         (bmalloc::sleep): Deleted.
320         (bmalloc::waitUntilFalse): Deleted.
321
322 2018-02-16  Filip Pizlo  <fpizlo@apple.com>
323
324         Unreviewed, roll out r228306 (custom memcpy/memset) because the bots say that it was not a
325         progression.
326
327         * bmalloc/Algorithm.h:
328         (bmalloc::fastCopy): Deleted.
329         (bmalloc::fastZeroFill): Deleted.
330         * bmalloc/Allocator.cpp:
331         (bmalloc::Allocator::reallocate):
332         * bmalloc/Bits.h:
333         (bmalloc::BitsWordOwner::operator=):
334         (bmalloc::BitsWordOwner::clearAll):
335         (bmalloc::BitsWordOwner::set):
336         * bmalloc/IsoPageInlines.h:
337         (bmalloc::IsoPage<Config>::IsoPage):
338         * bmalloc/Vector.h:
339         (bmalloc::Vector<T>::reallocateBuffer):
340
341 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
342
343         Improve of string.h include after r228317.
344         https://bugs.webkit.org/show_bug.cgi?id=182642
345
346         Reviewed by Mark Lam.
347
348         * bmalloc/Algorithm.h: Avoid an architecture-specific #include.
349
350 2018-02-09  Carlos Alberto Lopez Perez  <clopez@igalia.com>
351
352         Fix build for !BCPU(X86_64) after r228306
353         https://bugs.webkit.org/show_bug.cgi?id=182563
354
355         Unreviewed build fix.
356
357         * bmalloc/Algorithm.h:
358
359 2018-02-08  Filip Pizlo  <fpizlo@apple.com>
360
361         Experiment with alternative implementation of memcpy/memset
362         https://bugs.webkit.org/show_bug.cgi?id=182563
363
364         Reviewed by Michael Saboff and Mark Lam.
365         
366         Add a faster x86_64-specific implementation of memcpy and memset. Ideally, this would just be
367         implemented in WTF, but we have to copy it into bmalloc since bmalloc sits below WTF on the
368         stack.
369
370         * bmalloc/Algorithm.h:
371         (bmalloc::fastCopy):
372         (bmalloc::fastZeroFill):
373         * bmalloc/Allocator.cpp:
374         (bmalloc::Allocator::reallocate):
375         * bmalloc/Bits.h:
376         (bmalloc::BitsWordOwner::operator=):
377         (bmalloc::BitsWordOwner::clearAll):
378         (bmalloc::BitsWordOwner::set):
379         * bmalloc/IsoPageInlines.h:
380         (bmalloc::IsoPage<Config>::IsoPage):
381         * bmalloc/Vector.h:
382         (bmalloc::Vector<T>::reallocateBuffer):
383
384 2018-02-05  JF Bastien  <jfbastien@apple.com>
385
386         Gigacage: enable only for WebContent process and token executables
387         https://bugs.webkit.org/show_bug.cgi?id=182457
388         <rdar://problem/35875011>
389
390         Reviewed by Keith Miller.
391
392         Gigacage is a solid security improvement, but it's probably best
393         to roll it out incrementally to the most valuable targets first
394         and progressively try out more and more over time rather than
395         outright enabling it everywhere. We've gotten some reports that it
396         has some side-effects that weren't expected, so for now let's
397         enable it for the WebContent process, JSC, and other executables
398         we know, and then later we'll enable more gigacage uses.
399
400         For now I've chosen the following bundles:
401
402           - com.apple.WebKit.WebContent.Development
403           - com.apple.WebKit.WebContent
404           - com.apple.WebProcess
405
406         And the following processes:
407
408           - jsc
409           - wasm
410           - anything starting with "test", to match the JSC tests
411
412         I tried a different approach first, where I add a function to turn
413         gigacage on or off and crash if gigacage is initialized without
414         having been told what to do. Doing this in ChildProcess and a
415         bunch of the process initialization methods isn't sufficient. I
416         got MiniBrowser working, but some other builds use static globals
417         which themselves use hash and string which are allocate with
418         bmalloc and therefore which initialize gigacage before main is
419         called and before the process gets a chance to opt in our out. It
420         gets tricky with API calls too, because we have to do the right
421         thing in any entry an API user could plausibly use, even the
422         private ones, so I endend up having to initialize gigacage in e.g.
423         WebPreferencesExperimentalFeatures.cpp.erb.
424
425         Another approach could be to create a free-for-all gigacage
426         entitlement, and opt-in the processes we want..
427
428         As a follow-up we can also check that gigacage allocation always
429         succeeds if it was allowed for that process. With my change I
430         expect it to always succeed.
431
432         * CMakeLists.txt:
433         * bmalloc.xcodeproj/project.pbxproj:
434         * bmalloc/BPlatform.h:
435         * bmalloc/Gigacage.cpp:
436         (Gigacage::shouldBeEnabled):
437         * bmalloc/ProcessCheck.h: Added.
438         (bmalloc::gigacageEnabledForProcess):
439         * bmalloc/ProcessCheck.mm: Added.
440         (bmalloc::gigacageEnabledForProcess):
441
442 2018-02-05  Joseph Pecoraro  <pecoraro@apple.com>
443
444         Multiple bmalloc scavenger threads is unexpected
445         https://bugs.webkit.org/show_bug.cgi?id=182474
446         <rdar://problem/37175526>
447
448         Reviewed by Filip Pizlo.
449
450         * bmalloc/Heap.cpp:
451         (bmalloc::Heap::Heap):
452         * bmalloc/IsoDirectoryInlines.h:
453         (bmalloc::passedNumPages>::takeFirstEligible):
454         (bmalloc::passedNumPages>::didBecome):
455         * bmalloc/bmalloc.cpp:
456         (bmalloc::api::scavenge):
457         (bmalloc::api::setScavengerThreadQOSClass):
458         Switch to SafePerProcess for Scavenger to ensure one instance
459         for the entire process.
460
461         * bmalloc/PerProcess.h:
462         (bmalloc::PerProcess::get):
463         (bmalloc::PerProcess::getFastCase):
464         (bmalloc::PerProcess::getSlowCase):
465         (bmalloc::SafePerProcess::get):
466         (bmalloc::SafePerProcess::getFastCase):
467         (bmalloc::SafePerProcess::getSlowCase):
468         Duplicate the class with a version that can ensure
469         single instances by requiring exporting symbols that
470         can be created with macros.
471
472         * bmalloc/Scavenger.cpp:
473         * bmalloc/Scavenger.h:
474         Export symbols to ensure all images get the same instance.
475
476 2018-01-31  Saam Barati  <sbarati@apple.com>
477
478         Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
479         https://bugs.webkit.org/show_bug.cgi?id=182064
480         <rdar://problem/36840132>
481
482         Reviewed by Geoffrey Garen.
483
484         This patch replaces the tryLargeMemalignVirtual API with tryLargeZeroedMemalignVirtual.
485         By doing that, we're able to remove the AllocationKind enum. To zero the memory,
486         tryLargeZeroedMemalignVirtual uses mmap(... MAP_ANON ...) over previously mmapped
487         memory. This both purges the any resident memory for the virtual range and ensures
488         that the pages in the range are zeroed. Most OSs should implement this by taking a
489         page fault and zero filling on first access. Therefore, this API is returning pages
490         that will result in page faults on first access. Hence, the name 'virtual' in the API.
491         This API differs from the old API in that users of it need not call madvise themselves.
492         The memory is ready to go.
493
494         * bmalloc.xcodeproj/project.pbxproj:
495         * bmalloc/AllocationKind.h: Removed.
496         * bmalloc/DebugHeap.cpp:
497         (bmalloc::DebugHeap::memalignLarge):
498         (bmalloc::DebugHeap::freeLarge):
499         * bmalloc/DebugHeap.h:
500         * bmalloc/Heap.cpp:
501         (bmalloc::Heap::splitAndAllocate):
502         (bmalloc::Heap::tryAllocateLarge):
503         (bmalloc::Heap::allocateLarge):
504         (bmalloc::Heap::shrinkLarge):
505         (bmalloc::Heap::deallocateLarge):
506         * bmalloc/Heap.h:
507         * bmalloc/IsoPage.cpp:
508         (bmalloc::IsoPageBase::allocatePageMemory):
509         * bmalloc/VMAllocate.h:
510         (bmalloc::vmZeroAndPurge):
511         * bmalloc/VMHeap.cpp:
512         (bmalloc::VMHeap::tryAllocateLargeChunk):
513         * bmalloc/VMHeap.h:
514         * bmalloc/bmalloc.cpp:
515         (bmalloc::api::tryLargeZeroedMemalignVirtual):
516         (bmalloc::api::freeLargeVirtual):
517         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
518         * bmalloc/bmalloc.h:
519
520 2018-01-19  Keith Miller  <keith_miller@apple.com>
521
522         HaveInternalSDK includes should be "#include?"
523         https://bugs.webkit.org/show_bug.cgi?id=179670
524
525         Reviewed by Dan Bernstein.
526
527         * Configurations/Base.xcconfig:
528
529 2018-01-18  Dan Bernstein  <mitz@apple.com>
530
531         [Xcode] Streamline and future-proof target-macOS-version-dependent build setting definitions
532         https://bugs.webkit.org/show_bug.cgi?id=181803
533
534         Reviewed by Tim Horton.
535
536         * Configurations/Base.xcconfig: Updated.
537         * Configurations/DebugRelease.xcconfig: Ditto.
538
539 2018-01-16  Michael Catanzaro  <mcatanzaro@igalia.com>
540
541         mbmalloc should only be built in developer mode
542         https://bugs.webkit.org/show_bug.cgi?id=181654
543
544         Reviewed by Carlos Garcia Campos.
545
546         * CMakeLists.txt:
547
548 2018-01-15  Michael Catanzaro  <mcatanzaro@igalia.com>
549
550         Improve use of ExportMacros
551         https://bugs.webkit.org/show_bug.cgi?id=181652
552
553         Reviewed by Konstantin Tokarev.
554
555         Disable BEXPORT on Linux ports.
556
557         * bmalloc/BExport.h: Check for BUSE(EXPORT_MACROS).
558         * bmalloc/BPlatform.h: Add BUSE(EXPORT_MACROS) and define it on macOS and iOS.
559
560 2017-12-20  Ting-Wei Lan  <lantw44@gmail.com>
561
562         Include stdio.h before using stderr and _IONBF
563         https://bugs.webkit.org/show_bug.cgi?id=181046
564
565         Reviewed by Alex Christensen.
566
567         * bmalloc/IsoTLS.cpp:
568
569 2017-12-14  David Kilzer  <ddkilzer@apple.com>
570
571         Enable -Wstrict-prototypes for WebKit
572         <https://webkit.org/b/180757>
573         <rdar://problem/36024132>
574
575         Rubber-stamped by Joseph Pecoraro.
576
577         * Configurations/Base.xcconfig:
578         (CLANG_WARN_STRICT_PROTOTYPES): Add. Set to YES.
579
580 2017-12-14  Saam Barati  <sbarati@apple.com>
581
582         logVMFailure should not simulate crash on iOS
583         https://bugs.webkit.org/show_bug.cgi?id=180790
584
585         Reviewed by JF Bastien.
586
587         The Gigacage allocation on iOS is expected to fail in certain circumstances. 
588         Let's not simulate a crash on failure because since this is expected behavior.
589
590         * bmalloc/VMAllocate.h:
591         (bmalloc::tryVMAllocate):
592
593 2017-12-11  Tim Horton  <timothy_horton@apple.com>
594
595         Stop using deprecated target conditional for simulator builds
596         https://bugs.webkit.org/show_bug.cgi?id=180662
597         <rdar://problem/35136156>
598
599         Reviewed by Simon Fraser.
600
601         * bmalloc/BPlatform.h:
602
603 2017-12-08  Saam Barati  <sbarati@apple.com>
604
605         Enable gigacage on iOS with a 32GB runway and ensure it doesn't break WasmBench
606         https://bugs.webkit.org/show_bug.cgi?id=178557
607
608         Reviewed by Mark Lam.
609
610         * bmalloc/Algorithm.h:
611         (bmalloc::isPowerOfTwo):
612         * bmalloc/Gigacage.cpp:
613         * bmalloc/Gigacage.h:
614
615 2017-12-05  Andy Estes  <aestes@apple.com>
616
617         [Darwin] Simplify use of TargetConditionals
618         https://bugs.webkit.org/show_bug.cgi?id=180455
619         <rdar://problem/35142971>
620
621         Reviewed by Tim Horton.
622
623         There's no need to check if TARGET_* macros are defined on Darwin platforms, since
624         TargetConditionals.h always defines them. Also, we can simplify
625         (TARGET_OS_EMBEDDED || TARGET_OS_IPHONE || TARGET_IPHONE_SIMULATOR) to TARGET_OS_IPHONE.
626
627         * bmalloc/BPlatform.h:
628
629 2017-12-05  Filip Pizlo  <fpizlo@apple.com>
630
631         bmalloc IsoHeap needs to allow a thread to deallocate some size for the first time
632         https://bugs.webkit.org/show_bug.cgi?id=180443
633
634         Reviewed by Saam Barati.
635
636         It's true that we can expect a heap to already be initialized if we try to deallocate in it.  But it
637         may not have its deallocator initialized on this thread yet.
638         
639         This is easily fixed by adding a null check on the deallocate path. That's probably not going to
640         change perf at all. But doing that allows me to get rid of a lot of weird stuff I previously did to
641         avoid that null check, like creating a dummy TLS in the DebugHeap case.
642
643         * bmalloc/IsoTLS.cpp:
644         (bmalloc::IsoTLS::debugFree):
645         (bmalloc::IsoTLS::deallocateSlow): Deleted.
646         * bmalloc/IsoTLS.h:
647         * bmalloc/IsoTLSInlines.h:
648         (bmalloc::IsoTLS::allocateImpl):
649         (bmalloc::IsoTLS::allocateSlow):
650         (bmalloc::IsoTLS::deallocateImpl):
651         (bmalloc::IsoTLS::deallocateSlow):
652         (bmalloc::IsoTLS::ensureHeapAndEntries):
653
654 2017-12-01  Michael Saboff  <msaboff@apple.com>
655
656         Gigacage should not be enabled for ARM64_32
657         https://bugs.webkit.org/show_bug.cgi?id=180265
658
659         Reviewed by Saam Barati.
660
661         Disabled Gigacage for ARM64_32.
662         In the process, restructured Gigacage::shouldBeEnabled() with GIGACAGE_ENABLED set
663         to 0 to avoid a dead code compiler warning.
664
665         * bmalloc/Gigacage.cpp:
666         (Gigacage::shouldBeEnabled):
667         * bmalloc/Gigacage.h:
668
669 2017-11-29  JF Bastien  <jfbastien@apple.com>
670
671         WTF / bmalloc: don't write to 0xbbadbeef when ASAN is looking
672         https://bugs.webkit.org/show_bug.cgi?id=180175
673
674         Reviewed by Mark Lam.
675
676         ASAN knows that 0xbbadbeef is a bbad aaddress, and tells us so
677         when we write to it, say in an assert. That creates bbad error
678         reports where ASAN thinks we write to an invalid address, instead
679         of thinking that we hit an assertion. In some cases, tooling that
680         use fuzzers aggregate similar issues, and think that we just have
681         the one bug and not a bunch of different asserts.
682
683         At the same time, bmalloc's version of CRASH just writes to
684         0xbbadbeef and assumes that's invalid and will crash, which isn't
685         necessarily true on non-Mac platforms. WTF's version then makes
686         sure there's a crash, so bmalloc should do the same.
687
688         * bmalloc.xcodeproj/project.pbxproj:
689         * bmalloc/BAssert.h:
690         * bmalloc/BCompiler.h: Added.
691         * bmalloc/BPlatform.h:
692
693 2017-11-27  Filip Pizlo  <fpizlo@apple.com>
694
695         Don't crash in forEachEntry when DebugHeap is enabled.
696
697         Unreviewed, fixing crashes on leaks bots by removing an assertion.
698
699         * bmalloc/IsoTLS.cpp:
700         (bmalloc::IsoTLS::forEachEntry):
701         * test/testbmalloc.cpp: Make this test work with DebugHeap so I can catch this kind of problem in the future.
702
703 2017-11-16  Filip Pizlo  <fpizlo@apple.com>
704
705         Isolated Heaps caused an increase in reported leaks on the bots
706         https://bugs.webkit.org/show_bug.cgi?id=179463
707
708         Reviewed by Darin Adler.
709         
710         This fixes the way isoheaps interact with system tools:
711         
712         - Opts into the VMHeap API so that the leaks tool can find isoheap memory.
713         
714         - Opts into the DebugHeap/Environment APIs so that we turn off isoheap allocation if memory
715           debugging options are in use.
716
717         * bmalloc.xcodeproj/project.pbxproj:
718         * bmalloc/DebugHeap.h:
719         * bmalloc/IsoHeap.h:
720         * bmalloc/IsoPage.cpp: Added.
721         (bmalloc::IsoPageBase::allocatePageMemory):
722         * bmalloc/IsoPage.h:
723         * bmalloc/IsoPageInlines.h:
724         (bmalloc::IsoPage<Config>::tryCreate):
725         * bmalloc/IsoTLS.cpp:
726         (bmalloc::IsoTLS::deallocateSlow):
727         (bmalloc::IsoTLS::ensureEntries):
728         (bmalloc::IsoTLS::isUsingDebugHeap):
729         (bmalloc::IsoTLS::debugMalloc):
730         * bmalloc/IsoTLS.h:
731         * bmalloc/IsoTLSInlines.h:
732         (bmalloc::IsoTLS::allocate):
733         (bmalloc::IsoTLS::deallocate):
734         (bmalloc::IsoTLS::allocateImpl):
735         (bmalloc::IsoTLS::allocateFast):
736         (bmalloc::IsoTLS::allocateSlow):
737         (bmalloc::IsoTLS::deallocateImpl):
738         (bmalloc::IsoTLS::deallocateFast):
739         (bmalloc::IsoTLS::ensureHeapAndEntries):
740         (bmalloc::IsoTLS::allocator): Deleted.
741         (bmalloc::IsoTLS::deallocator): Deleted.
742         * bmalloc/bmalloc.cpp:
743         (bmalloc::api::tryLargeMemalignVirtual):
744         (bmalloc::api::freeLargeVirtual):
745         (bmalloc::api::scavenge):
746         (bmalloc::api::isEnabled):
747         (bmalloc::api::setScavengerThreadQOSClass):
748         * bmalloc/bmalloc.h:
749         (bmalloc::api::tryLargeMemalignVirtual): Deleted.
750         (bmalloc::api::freeLargeVirtual): Deleted.
751         (bmalloc::api::scavenge): Deleted.
752         (bmalloc::api::isEnabled): Deleted.
753         (bmalloc::api::setScavengerThreadQOSClass): Deleted.
754
755 2017-11-14  Saam Barati  <sbarati@apple.com>
756
757         Make the gigacage runway 32GB
758         https://bugs.webkit.org/show_bug.cgi?id=175062
759
760         Reviewed by Mark Lam.
761
762         Making the gigacage runway 32GB defends us against buffer overflows in the
763         cage reaching memory outside the cage assuming indices are 32-bit unsigned
764         integers and the type they're indexing into has size <= 8 bytes. This is
765         exactly the case for many things in JSC. For example, butterfly access in
766         JSC meet this criteria, as does typed array access.
767         
768         The 32GB comes from 8 * 2^32 = 32GB.
769
770         * bmalloc/Gigacage.cpp:
771
772 2017-11-08  Michael Catanzaro  <mcatanzaro@igalia.com>
773
774         Gigacage.cpp:44:46: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
775         https://bugs.webkit.org/show_bug.cgi?id=179427
776
777         Reviewed by Saam Barati.
778
779         Tweak the conditional to suppress the warning.
780
781         * bmalloc/Gigacage.cpp:
782         (Gigacage::ensureGigacage):
783
784 2017-11-07  Saam Barati  <sbarati@apple.com>
785
786         We should PROT_NONE the Gigacage runway so OOB accesses crash
787         https://bugs.webkit.org/show_bug.cgi?id=179392
788
789         Reviewed by Mark Lam.
790
791         If we assume that an attacker will exploit JSC and cause OOB accesses,
792         we should make OOB accesses in the Gigacage runway crash.
793
794         * bmalloc/Gigacage.cpp:
795         (Gigacage::ensureGigacage):
796
797 2017-10-31  Filip Pizlo  <fpizlo@apple.com>
798
799         bmalloc should support strictly type-segregated isolated heaps
800         https://bugs.webkit.org/show_bug.cgi?id=178108
801
802         Reviewed by Saam Barati, Simon Fraser, and Ryosuke Niwa.
803         
804         This introduces a new allocation API in bmalloc called IsoHeap. An IsoHeap is templatized by
805         type and created in static storage. When unused, it takes only a few words. When you do use
806         it, each IsoHeap gets a bag of virtual pages unique to it. This prevents use-after-free bugs
807         in one IsoHeap from affecting any other memory. At worst, two pointers of the same type will
808         point to the same object even though they should not have.
809         
810         IsoHeaps allocate using a first-fit discipline that combines ideas from bmalloc and Riptide
811         (the JSC GC):
812         
813         Like Riptide, it uses a bump'n'pop allocator. What Riptide calls blocks, IsoHeaps calls
814         pages. Pages are collected into directories. Directories track pages using bitvectors, so
815         that it's easy to quickly find a completely free page or one that has at least one free
816         object. I think that the bump'n'pop allocator is as fast as the bmalloc Immix-style (page and
817         line) allocator, but is better at allocating in holes. It's guaranteed to follow a first-fit
818         discipline. However, the real reason why I wrote it that was is that this is what I'm more
819         familiar with. This is a part of the design I want to revisit (bug 179278).
820         
821         Like bmalloc, it uses a deallocation log. This means that the internal IsoHeap data
822         structures can be locked with a coarse-grained lock, since the deallocator only grabs it when
823         flushing the log. Similarly, the allocator only grabs it when refilling the bump'n'pop
824         FreeList.
825         
826         This adds a unit test for IsoHeaps. In this change, IsoHeaps are adopted only by WebCore's
827         RenderObject.
828         
829         Note that despite the use of GC concepts, it's not a goal to make this code directly sharable
830         with GC. The GC will probably have to do isolated heaps its own way (likely a special
831         Subspace or something like that).
832
833         * bmalloc.xcodeproj/project.pbxproj:
834         * bmalloc/Algorithm.h:
835         (bmalloc::findBitInWord):
836         * bmalloc/AllIsoHeaps.cpp: Added.
837         (bmalloc::AllIsoHeaps::AllIsoHeaps):
838         (bmalloc::AllIsoHeaps::add):
839         (bmalloc::AllIsoHeaps::head):
840         * bmalloc/AllIsoHeaps.h: Added.
841         * bmalloc/AllIsoHeapsInlines.h: Added.
842         (bmalloc::AllIsoHeaps::forEach):
843         * bmalloc/BMalloced.h: Added.
844         * bmalloc/Bits.h: Added.
845         (bmalloc::bitsArrayLength):
846         (bmalloc::BitsWordView::BitsWordView):
847         (bmalloc::BitsWordView::numBits const):
848         (bmalloc::BitsWordView::word const):
849         (bmalloc::BitsWordOwner::BitsWordOwner):
850         (bmalloc::BitsWordOwner::view const):
851         (bmalloc::BitsWordOwner::operator=):
852         (bmalloc::BitsWordOwner::setAll):
853         (bmalloc::BitsWordOwner::clearAll):
854         (bmalloc::BitsWordOwner::set):
855         (bmalloc::BitsWordOwner::numBits const):
856         (bmalloc::BitsWordOwner::arrayLength const):
857         (bmalloc::BitsWordOwner::word const):
858         (bmalloc::BitsWordOwner::word):
859         (bmalloc::BitsWordOwner::words const):
860         (bmalloc::BitsWordOwner::words):
861         (bmalloc::BitsAndWords::BitsAndWords):
862         (bmalloc::BitsAndWords::view const):
863         (bmalloc::BitsAndWords::numBits const):
864         (bmalloc::BitsAndWords::word const):
865         (bmalloc::BitsOrWords::BitsOrWords):
866         (bmalloc::BitsOrWords::view const):
867         (bmalloc::BitsOrWords::numBits const):
868         (bmalloc::BitsOrWords::word const):
869         (bmalloc::BitsNotWords::BitsNotWords):
870         (bmalloc::BitsNotWords::view const):
871         (bmalloc::BitsNotWords::numBits const):
872         (bmalloc::BitsNotWords::word const):
873         (bmalloc::BitsImpl::BitsImpl):
874         (bmalloc::BitsImpl::numBits const):
875         (bmalloc::BitsImpl::size const):
876         (bmalloc::BitsImpl::arrayLength const):
877         (bmalloc::BitsImpl::operator== const):
878         (bmalloc::BitsImpl::operator!= const):
879         (bmalloc::BitsImpl::at const):
880         (bmalloc::BitsImpl::operator[] const):
881         (bmalloc::BitsImpl::isEmpty const):
882         (bmalloc::BitsImpl::operator& const):
883         (bmalloc::BitsImpl::operator| const):
884         (bmalloc::BitsImpl::operator~ const):
885         (bmalloc::BitsImpl::forEachSetBit const):
886         (bmalloc::BitsImpl::forEachClearBit const):
887         (bmalloc::BitsImpl::forEachBit const):
888         (bmalloc::BitsImpl::findBit const):
889         (bmalloc::BitsImpl::findSetBit const):
890         (bmalloc::BitsImpl::findClearBit const):
891         (bmalloc::BitsImpl::wordView const):
892         (bmalloc::BitsImpl::atImpl const):
893         (bmalloc::Bits::Bits):
894         (bmalloc::Bits::operator=):
895         (bmalloc::Bits::resize):
896         (bmalloc::Bits::setAll):
897         (bmalloc::Bits::clearAll):
898         (bmalloc::Bits::setAndCheck):
899         (bmalloc::Bits::operator|=):
900         (bmalloc::Bits::operator&=):
901         (bmalloc::Bits::at const):
902         (bmalloc::Bits::operator[] const):
903         (bmalloc::Bits::BitReference::BitReference):
904         (bmalloc::Bits::BitReference::operator bool const):
905         (bmalloc::Bits::BitReference::operator=):
906         (bmalloc::Bits::at):
907         (bmalloc::Bits::operator[]):
908         * bmalloc/CryptoRandom.cpp: Replaced with Source/bmalloc/bmalloc/CryptoRandom.cpp.
909         (bmalloc::cryptoRandom):
910         * bmalloc/CryptoRandom.h: Replaced with Source/bmalloc/bmalloc/CryptoRandom.h.
911         * bmalloc/DeferredDecommit.h: Added.
912         * bmalloc/DeferredDecommitInlines.h: Added.
913         (bmalloc::DeferredDecommit::DeferredDecommit):
914         * bmalloc/DeferredTrigger.h: Added.
915         (bmalloc::DeferredTrigger::DeferredTrigger):
916         * bmalloc/DeferredTriggerInlines.h: Added.
917         (bmalloc::DeferredTrigger<trigger>::didBecome):
918         (bmalloc::DeferredTrigger<trigger>::handleDeferral):
919         * bmalloc/EligibilityResult.h: Added.
920         (bmalloc::EligibilityResult::EligibilityResult):
921         * bmalloc/EligibilityResultInlines.h: Added.
922         (bmalloc::EligibilityResult<Config>::EligibilityResult):
923         * bmalloc/FixedVector.h:
924         * bmalloc/FreeList.cpp: Added.
925         (bmalloc::FreeList::FreeList):
926         (bmalloc::FreeList::~FreeList):
927         (bmalloc::FreeList::clear):
928         (bmalloc::FreeList::initializeList):
929         (bmalloc::FreeList::initializeBump):
930         (bmalloc::FreeList::contains const):
931         * bmalloc/FreeList.h: Added.
932         (bmalloc::FreeCell::scramble):
933         (bmalloc::FreeCell::descramble):
934         (bmalloc::FreeCell::setNext):
935         (bmalloc::FreeCell::next const):
936         (bmalloc::FreeList::allocationWillFail const):
937         (bmalloc::FreeList::allocationWillSucceed const):
938         (bmalloc::FreeList::originalSize const):
939         (bmalloc::FreeList::head const):
940         * bmalloc/FreeListInlines.h: Added.
941         (bmalloc::FreeList::allocate):
942         (bmalloc::FreeList::forEach const):
943         * bmalloc/IsoAllocator.h: Added.
944         * bmalloc/IsoAllocatorInlines.h: Added.
945         (bmalloc::IsoAllocator<Config>::IsoAllocator):
946         (bmalloc::IsoAllocator<Config>::~IsoAllocator):
947         (bmalloc::IsoAllocator<Config>::allocate):
948         (bmalloc::IsoAllocator<Config>::allocateSlow):
949         (bmalloc::IsoAllocator<Config>::scavenge):
950         * bmalloc/IsoConfig.h: Added.
951         * bmalloc/IsoDeallocator.h: Added.
952         * bmalloc/IsoDeallocatorInlines.h: Added.
953         (bmalloc::IsoDeallocator<Config>::IsoDeallocator):
954         (bmalloc::IsoDeallocator<Config>::~IsoDeallocator):
955         (bmalloc::IsoDeallocator<Config>::deallocate):
956         (bmalloc::IsoDeallocator<Config>::scavenge):
957         * bmalloc/IsoDirectory.h: Added.
958         (bmalloc::IsoDirectoryBaseBase::IsoDirectoryBaseBase):
959         (bmalloc::IsoDirectoryBaseBase::~IsoDirectoryBaseBase):
960         (bmalloc::IsoDirectoryBase::heap):
961         * bmalloc/IsoDirectoryInlines.h: Added.
962         (bmalloc::IsoDirectoryBase<Config>::IsoDirectoryBase):
963         (bmalloc::passedNumPages>::IsoDirectory):
964         (bmalloc::passedNumPages>::takeFirstEligible):
965         (bmalloc::passedNumPages>::didBecome):
966         (bmalloc::passedNumPages>::didDecommit):
967         (bmalloc::passedNumPages>::scavenge):
968         (bmalloc::passedNumPages>::forEachCommittedPage):
969         * bmalloc/IsoDirectoryPage.h: Added.
970         (bmalloc::IsoDirectoryPage::index const):
971         * bmalloc/IsoDirectoryPageInlines.h: Added.
972         (bmalloc::IsoDirectoryPage<Config>::IsoDirectoryPage):
973         (bmalloc::IsoDirectoryPage<Config>::pageFor):
974         * bmalloc/IsoHeap.h: Added.
975         (bmalloc::api::IsoHeap::allocatorOffset):
976         (bmalloc::api::IsoHeap::setAllocatorOffset):
977         (bmalloc::api::IsoHeap::deallocatorOffset):
978         (bmalloc::api::IsoHeap::setDeallocatorOffset):
979         * bmalloc/IsoHeapImpl.cpp: Added.
980         (bmalloc::IsoHeapImplBase::IsoHeapImplBase):
981         (bmalloc::IsoHeapImplBase::~IsoHeapImplBase):
982         (bmalloc::IsoHeapImplBase::scavengeNow):
983         (bmalloc::IsoHeapImplBase::finishScavenging):
984         * bmalloc/IsoHeapImpl.h: Added.
985         * bmalloc/IsoHeapImplInlines.h: Added.
986         (bmalloc::IsoHeapImpl<Config>::IsoHeapImpl):
987         (bmalloc::IsoHeapImpl<Config>::takeFirstEligible):
988         (bmalloc::IsoHeapImpl<Config>::didBecomeEligible):
989         (bmalloc::IsoHeapImpl<Config>::scavenge):
990         (bmalloc::IsoHeapImpl<Config>::allocatorOffset):
991         (bmalloc::IsoHeapImpl<Config>::deallocatorOffset):
992         (bmalloc::IsoHeapImpl<Config>::numLiveObjects):
993         (bmalloc::IsoHeapImpl<Config>::numCommittedPages):
994         (bmalloc::IsoHeapImpl<Config>::forEachDirectory):
995         (bmalloc::IsoHeapImpl<Config>::forEachCommittedPage):
996         (bmalloc::IsoHeapImpl<Config>::forEachLiveObject):
997         * bmalloc/IsoHeapInlines.h: Added.
998         (bmalloc::api::IsoHeap<Type>::allocate):
999         (bmalloc::api::IsoHeap<Type>::tryAllocate):
1000         (bmalloc::api::IsoHeap<Type>::deallocate):
1001         (bmalloc::api::IsoHeap<Type>::scavenge):
1002         (bmalloc::api::IsoHeap<Type>::isInitialized):
1003         (bmalloc::api::IsoHeap<Type>::impl):
1004         * bmalloc/IsoPage.h: Added.
1005         (bmalloc::IsoPage::index const):
1006         (bmalloc::IsoPage::directory):
1007         (bmalloc::IsoPage::isInUseForAllocation const):
1008         (bmalloc::IsoPage::indexOfFirstObject):
1009         * bmalloc/IsoPageInlines.h: Added.
1010         (bmalloc::IsoPage<Config>::tryCreate):
1011         (bmalloc::IsoPage<Config>::IsoPage):
1012         (bmalloc::IsoPage<Config>::free):
1013         (bmalloc::IsoPage<Config>::startAllocating):
1014         (bmalloc::IsoPage<Config>::stopAllocating):
1015         (bmalloc::IsoPage<Config>::forEachLiveObject):
1016         * bmalloc/IsoPageTrigger.h: Added.
1017         * bmalloc/IsoTLS.cpp: Added.
1018         (bmalloc::IsoTLS::scavenge):
1019         (bmalloc::IsoTLS::IsoTLS):
1020         (bmalloc::IsoTLS::ensureEntries):
1021         (bmalloc::IsoTLS::destructor):
1022         (bmalloc::IsoTLS::sizeForCapacity):
1023         (bmalloc::IsoTLS::capacityForSize):
1024         (bmalloc::IsoTLS::size):
1025         (bmalloc::IsoTLS::forEachEntry):
1026         * bmalloc/IsoTLS.h: Added.
1027         * bmalloc/IsoTLSAllocatorEntry.h: Added.
1028         * bmalloc/IsoTLSAllocatorEntryInlines.h: Added.
1029         (bmalloc::IsoTLSAllocatorEntry<Config>::IsoTLSAllocatorEntry):
1030         (bmalloc::IsoTLSAllocatorEntry<Config>::~IsoTLSAllocatorEntry):
1031         (bmalloc::IsoTLSAllocatorEntry<Config>::construct):
1032         * bmalloc/IsoTLSDeallocatorEntry.h: Added.
1033         * bmalloc/IsoTLSDeallocatorEntryInlines.h: Added.
1034         (bmalloc::IsoTLSDeallocatorEntry<Config>::IsoTLSDeallocatorEntry):
1035         (bmalloc::IsoTLSDeallocatorEntry<Config>::~IsoTLSDeallocatorEntry):
1036         (bmalloc::IsoTLSDeallocatorEntry<Config>::construct):
1037         * bmalloc/IsoTLSEntry.cpp: Added.
1038         (bmalloc::IsoTLSEntry::IsoTLSEntry):
1039         (bmalloc::IsoTLSEntry::~IsoTLSEntry):
1040         * bmalloc/IsoTLSEntry.h: Added.
1041         (bmalloc::IsoTLSEntry::offset const):
1042         (bmalloc::IsoTLSEntry::alignment const):
1043         (bmalloc::IsoTLSEntry::size const):
1044         (bmalloc::IsoTLSEntry::extent const):
1045         * bmalloc/IsoTLSEntryInlines.h: Added.
1046         (bmalloc::IsoTLSEntry::walkUpToInclusive):
1047         (bmalloc::DefaultIsoTLSEntry<EntryType>::DefaultIsoTLSEntry):
1048         (bmalloc::DefaultIsoTLSEntry<EntryType>::~DefaultIsoTLSEntry):
1049         (bmalloc::DefaultIsoTLSEntry<EntryType>::move):
1050         (bmalloc::DefaultIsoTLSEntry<EntryType>::destruct):
1051         (bmalloc::DefaultIsoTLSEntry<EntryType>::scavenge):
1052         * bmalloc/IsoTLSInlines.h: Added.
1053         (bmalloc::IsoTLS::allocate):
1054         (bmalloc::IsoTLS::deallocate):
1055         (bmalloc::IsoTLS::scavenge):
1056         (bmalloc::IsoTLS::allocator):
1057         (bmalloc::IsoTLS::deallocator):
1058         (bmalloc::IsoTLS::get):
1059         (bmalloc::IsoTLS::set):
1060         (bmalloc::IsoTLS::ensureHeap):
1061         (bmalloc::IsoTLS::ensureHeapAndEntries):
1062         * bmalloc/IsoTLSLayout.cpp: Added.
1063         (bmalloc::IsoTLSLayout::IsoTLSLayout):
1064         (bmalloc::IsoTLSLayout::add):
1065         * bmalloc/IsoTLSLayout.h: Added.
1066         (bmalloc::IsoTLSLayout::head const):
1067         * bmalloc/PerHeapKind.h:
1068         * bmalloc/PerProcess.h:
1069         (bmalloc::PerProcess<T>::getFastCase):
1070         * bmalloc/Scavenger.cpp:
1071         (bmalloc::Scavenger::scavenge):
1072         * bmalloc/Scavenger.h:
1073         * bmalloc/bmalloc.h:
1074         (bmalloc::api::scavengeThisThread):
1075         * test: Added.
1076         * test/testbmalloc.cpp: Added.
1077         (hiddenTruthBecauseNoReturnIsStupid):
1078         (usage):
1079         (assertEmptyPointerSet):
1080         (assertHasObjects):
1081         (assertHasOnlyObjects):
1082         (assertClean):
1083         (testIsoSimple):
1084         (testIsoSimpleScavengeBeforeDealloc):
1085         (testIsoFlipFlopFragmentedPages):
1086         (testIsoFlipFlopFragmentedPagesScavengeInMiddle):
1087         (BisoMalloced::BisoMalloced):
1088         (testBisoMalloced):
1089         (BisoMallocedInline::BisoMallocedInline):
1090         (testBisoMallocedInline):
1091         (run):
1092         (main):
1093
1094 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
1095
1096         [ARM64][Linux] Re-enable Gigacage
1097         https://bugs.webkit.org/show_bug.cgi?id=178130
1098
1099         Reviewed by Michael Catanzaro.
1100
1101         * bmalloc/Gigacage.h: Re-enable Gigacage on ARM64 Linux.
1102
1103 2017-10-25  Commit Queue  <commit-queue@webkit.org>
1104
1105         Unreviewed, rolling out r222945.
1106         https://bugs.webkit.org/show_bug.cgi?id=178818
1107
1108         "It made WasmBench crash" (Requested by saamyjoon on #webkit).
1109
1110         Reverted changeset:
1111
1112         "bmalloc mutex should be adaptive"
1113         https://bugs.webkit.org/show_bug.cgi?id=177839
1114         https://trac.webkit.org/changeset/222945
1115
1116 2017-10-24  Zan Dobersek  <zdobersek@igalia.com>
1117
1118         [Linux] Enable Gigacage in x64 Linux environment
1119         https://bugs.webkit.org/show_bug.cgi?id=177745
1120         <rdar://problem/34773148>
1121
1122         Reviewed by Yusuke Suzuki.
1123
1124         Re-enable Gigacage on x86_64 Linux platforms after it was disabled in 223877.
1125
1126         The cause for the revert was problems with huge coredumps being generated
1127         while Gigacage was enabled. The feature virtually allocates about 80GB of
1128         memory at the beginning of the process lifetime. This is not a problem in
1129         itself since the memory range is marked as not needed through madvise(),
1130         but all this memory was still included upon core dump generation on Linux.
1131         Since there are reasonable limits enforced upon core dumps, these were
1132         being truncated every time, not yielding any useful information.
1133
1134         To avoid this, on Linux, invocations of madvise() with the MADV_NORMAL and
1135         MADV_DONTNEED advice parameters should be accompanied with respectively
1136         matching MADV_DODUMP and MADV_DONTDUMP madvise() calls. This correctly
1137         avoids core-dumping any memory that's not yet been physically allocated.
1138
1139         * bmalloc/Gigacage.h:
1140         * bmalloc/VMAllocate.h:
1141         (bmalloc::vmDeallocatePhysicalPages):
1142         (bmalloc::vmAllocatePhysicalPages):
1143
1144 2017-10-24  David Kilzer  <ddkilzer@apple.com>
1145
1146         Need to pass non-nil argument to SimulateCrash() in bmalloc::logVMFailure()
1147         <https://webkit.org/b/178740>
1148         <rdar://problem/35154943>
1149
1150         Reviewed by Saam Barati.
1151
1152         * bmalloc/BPlatform.h:
1153         (BUNUSED_PARAM): Define macro.
1154         * bmalloc/Logging.cpp:
1155         (SimulateCrash): Change third argument of SimulateCrash() to
1156         CFStringRef since it's an NSString * in Objective-C.
1157         (bmalloc::logVMFailure): Create a CFStringRef to use as a
1158         description string.  Use new vmSize parameter to log size.
1159         * bmalloc/Logging.h:
1160         (bmalloc::logVMFailure): Update function signature to take a
1161         size_t parameter representing vmSize.
1162         * bmalloc/VMAllocate.h:
1163         (bmalloc::tryVMAllocate): Pass vmSize into logVMFailure().
1164
1165 2017-10-23  Michael Catanzaro  <mcatanzaro@igalia.com>
1166
1167         Unreviewed, roll out r222731
1168         https://bugs.webkit.org/show_bug.cgi?id=177745
1169         <rdar://problem/34773148>
1170
1171         Unfortunately Gigacage has broken core dump generation.
1172
1173         * bmalloc/Gigacage.h:
1174
1175 2017-10-23  Zan Dobersek  <zdobersek@igalia.com>
1176
1177         bmalloc::api::tryLargeMemalignVirtual() shouldn't assert on a failed allocation
1178         https://bugs.webkit.org/show_bug.cgi?id=178654
1179
1180         Reviewed by Geoffrey Garen.
1181
1182         * bmalloc/bmalloc.h:
1183         (bmalloc::api::tryLargeMemalignVirtual): Call Heap::tryAllocateLarge()
1184         instead of Heap::allocateLarge(). The former will return a null pointer
1185         upon a failed allocation, allowing the caller to fail gracefully just as
1186         the API entrypoint implies, while the latter currently provokes a crash
1187         in these circumstances.
1188
1189 2017-10-19  Saam Barati  <sbarati@apple.com>
1190
1191         Runtime disable gigacage on iOS because it broke WasmBench
1192         https://bugs.webkit.org/show_bug.cgi?id=178556
1193
1194         Reviewed by Keith Miller.
1195
1196         * bmalloc/Gigacage.cpp:
1197         (Gigacage::shouldBeEnabled):
1198
1199 2017-10-17  Filip Pizlo  <fpizlo@apple.com>
1200
1201         You can't vmDeallocate null
1202         <rdar://problem/35038926>
1203
1204         Reviewed by Michael Saboff.
1205         
1206         After failing allocation, we would try to deallocate the thing we failed to allocate. The fix is to
1207         not try to deallocate something that is obviously null.
1208
1209         * bmalloc/Gigacage.cpp:
1210         (Gigacage::ensureGigacage):
1211
1212 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1213
1214         Enable gigacage on iOS
1215         https://bugs.webkit.org/show_bug.cgi?id=177586
1216
1217         Reviewed by JF Bastien.
1218         
1219         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1220         allocation fails, we free all of the gigacages and turn off gigacage support.
1221         
1222         Roll this back in after discussion.
1223
1224         * CMakeLists.txt:
1225         * bmalloc.xcodeproj/project.pbxproj:
1226         * bmalloc/Cache.cpp:
1227         (bmalloc::Cache::scavenge):
1228         * bmalloc/Cache.h:
1229         (bmalloc::Cache::tryAllocate):
1230         (bmalloc::Cache::allocate):
1231         (bmalloc::Cache::deallocate):
1232         (bmalloc::Cache::reallocate):
1233         * bmalloc/Gigacage.cpp:
1234         (Gigacage::ensureGigacage):
1235         (Gigacage::runway):
1236         (Gigacage::totalSize):
1237         (Gigacage::shouldBeEnabled):
1238         (): Deleted.
1239         (Gigacage::Callback::Callback): Deleted.
1240         (Gigacage::Callback::function): Deleted.
1241         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1242         * bmalloc/Gigacage.h:
1243         (Gigacage::wasEnabled):
1244         (Gigacage::isEnabled):
1245         (Gigacage::runway): Deleted.
1246         (Gigacage::totalSize): Deleted.
1247         * bmalloc/HeapKind.cpp: Added.
1248         (bmalloc::isActiveHeapKind):
1249         (bmalloc::mapToActiveHeapKind):
1250         * bmalloc/HeapKind.h:
1251         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1252         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1253         * bmalloc/Scavenger.cpp:
1254         (bmalloc::Scavenger::scavenge):
1255         * bmalloc/bmalloc.h:
1256         (bmalloc::api::tryLargeMemalignVirtual):
1257         (bmalloc::api::freeLargeVirtual):
1258         (bmalloc::api::isEnabled):
1259
1260 2017-10-11  Commit Queue  <commit-queue@webkit.org>
1261
1262         Unreviewed, rolling out r223113 and r223121.
1263         https://bugs.webkit.org/show_bug.cgi?id=178182
1264
1265         Reintroduced 20% regression on Kraken (Requested by rniwa on
1266         #webkit).
1267
1268         Reverted changesets:
1269
1270         "Enable gigacage on iOS"
1271         https://bugs.webkit.org/show_bug.cgi?id=177586
1272         https://trac.webkit.org/changeset/223113
1273
1274         "Use one virtual allocation for all gigacages and their
1275         runways"
1276         https://bugs.webkit.org/show_bug.cgi?id=178050
1277         https://trac.webkit.org/changeset/223121
1278
1279 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
1280
1281         Use one virtual allocation for all gigacages and their runways
1282         https://bugs.webkit.org/show_bug.cgi?id=178050
1283
1284         Reviewed by Saam Barati.
1285
1286         * bmalloc/Gigacage.cpp:
1287         (Gigacage::ensureGigacage):
1288         (Gigacage::runway): Deleted.
1289         (Gigacage::totalSize): Deleted.
1290         * bmalloc/Gigacage.h:
1291
1292 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1293
1294         Enable gigacage on iOS
1295         https://bugs.webkit.org/show_bug.cgi?id=177586
1296
1297         Reviewed by JF Bastien.
1298         
1299         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1300         allocation fails, we free all of the gigacages and turn off gigacage support.
1301         
1302         Reland this after confirming that the 20% Kraken regression was a one-bot fluke. Local testing on the
1303         same kind of system did not show the regression. Saam and I both tried independently.
1304
1305         * CMakeLists.txt:
1306         * bmalloc.xcodeproj/project.pbxproj:
1307         * bmalloc/Cache.cpp:
1308         (bmalloc::Cache::scavenge):
1309         * bmalloc/Cache.h:
1310         (bmalloc::Cache::tryAllocate):
1311         (bmalloc::Cache::allocate):
1312         (bmalloc::Cache::deallocate):
1313         (bmalloc::Cache::reallocate):
1314         * bmalloc/Gigacage.cpp:
1315         (Gigacage::ensureGigacage):
1316         (Gigacage::runway):
1317         (Gigacage::totalSize):
1318         (Gigacage::shouldBeEnabled):
1319         (): Deleted.
1320         (Gigacage::Callback::Callback): Deleted.
1321         (Gigacage::Callback::function): Deleted.
1322         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1323         * bmalloc/Gigacage.h:
1324         (Gigacage::wasEnabled):
1325         (Gigacage::isEnabled):
1326         (Gigacage::runway): Deleted.
1327         (Gigacage::totalSize): Deleted.
1328         * bmalloc/HeapKind.cpp: Added.
1329         (bmalloc::isActiveHeapKind):
1330         (bmalloc::mapToActiveHeapKind):
1331         * bmalloc/HeapKind.h:
1332         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1333         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1334         * bmalloc/Scavenger.cpp:
1335         (bmalloc::Scavenger::scavenge):
1336         * bmalloc/bmalloc.h:
1337         (bmalloc::api::tryLargeMemalignVirtual):
1338         (bmalloc::api::freeLargeVirtual):
1339         (bmalloc::api::isEnabled):
1340
1341 2017-10-09  Commit Queue  <commit-queue@webkit.org>
1342
1343         Unreviewed, rolling out r223015 and r223025.
1344         https://bugs.webkit.org/show_bug.cgi?id=178093
1345
1346         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
1347         #webkit).
1348
1349         Reverted changesets:
1350
1351         "Enable gigacage on iOS"
1352         https://bugs.webkit.org/show_bug.cgi?id=177586
1353         http://trac.webkit.org/changeset/223015
1354
1355         "Unreviewed, disable Gigacage on ARM64 Linux"
1356         https://bugs.webkit.org/show_bug.cgi?id=177586
1357         http://trac.webkit.org/changeset/223025
1358
1359 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1360
1361         Unreviewed, disable Gigacage on ARM64 Linux
1362         https://bugs.webkit.org/show_bug.cgi?id=177586
1363
1364         Gigacage's LLInt change breaks ARM64 Linux.
1365         Currently we do not have maintainers for this.
1366         Let's simply disable it.
1367
1368         * bmalloc/Gigacage.h:
1369
1370 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1371
1372         Enable gigacage on iOS
1373         https://bugs.webkit.org/show_bug.cgi?id=177586
1374
1375         Reviewed by JF Bastien.
1376         
1377         Introduce the ability to disable gigacage at runtime if allocation fails. If any step of gigacage
1378         allocation fails, we free all of the gigacages and turn off gigacage support.
1379
1380         * CMakeLists.txt:
1381         * bmalloc.xcodeproj/project.pbxproj:
1382         * bmalloc/Cache.cpp:
1383         (bmalloc::Cache::scavenge):
1384         * bmalloc/Cache.h:
1385         (bmalloc::Cache::tryAllocate):
1386         (bmalloc::Cache::allocate):
1387         (bmalloc::Cache::deallocate):
1388         (bmalloc::Cache::reallocate):
1389         * bmalloc/Gigacage.cpp:
1390         (Gigacage::ensureGigacage):
1391         (Gigacage::runway):
1392         (Gigacage::totalSize):
1393         (Gigacage::shouldBeEnabled):
1394         (): Deleted.
1395         (Gigacage::Callback::Callback): Deleted.
1396         (Gigacage::Callback::function): Deleted.
1397         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks): Deleted.
1398         * bmalloc/Gigacage.h:
1399         (Gigacage::wasEnabled):
1400         (Gigacage::isEnabled):
1401         (Gigacage::runway): Deleted.
1402         (Gigacage::totalSize): Deleted.
1403         * bmalloc/HeapKind.cpp: Added.
1404         (bmalloc::isActiveHeapKind):
1405         (bmalloc::mapToActiveHeapKind):
1406         * bmalloc/HeapKind.h:
1407         (bmalloc::isActiveHeapKindAfterEnsuringGigacage):
1408         (bmalloc::mapToActiveHeapKindAfterEnsuringGigacage):
1409         * bmalloc/Scavenger.cpp:
1410         (bmalloc::Scavenger::scavenge):
1411         * bmalloc/bmalloc.h:
1412         (bmalloc::api::tryLargeMemalignVirtual):
1413         (bmalloc::api::freeLargeVirtual):
1414         (bmalloc::api::isEnabled):
1415
1416 2017-10-05  Filip Pizlo  <fpizlo@apple.com>
1417
1418         Use one Scavenger thread for all Heaps
1419         https://bugs.webkit.org/show_bug.cgi?id=174973
1420
1421         Reviewed by JF Bastien.
1422         
1423         This combines the scavengers from all Heap instances into a single scavenger. It also combines
1424         the accounting for deciding when to run. Each Heap still controls what it means to scavenge
1425         itself (it's all in Heap::scavenge) but the policy decisions are all controlled by Scavenger.
1426         Because Scavenger is also the only thing that needs an AsyncTask, this removes AsyncTask and
1427         moves all of AsyncTask's logic into Scavenger.
1428         
1429         This appears to be a 1% progression on JetStream (with high statistical confidence: p = 0.0049).
1430
1431         * bmalloc.xcodeproj/project.pbxproj:
1432         * bmalloc/AsyncTask.h: Removed.
1433         * bmalloc/Heap.cpp:
1434         (bmalloc::Heap::Heap):
1435         (bmalloc::Heap::allocateSmallChunk):
1436         (bmalloc::Heap::allocateSmallPage):
1437         (bmalloc::Heap::deallocateSmallLine):
1438         (bmalloc::Heap::splitAndAllocate):
1439         (bmalloc::Heap::tryAllocateLarge):
1440         (bmalloc::Heap::shrinkLarge):
1441         (bmalloc::Heap::deallocateLarge):
1442         (bmalloc::Heap::concurrentScavenge): Deleted.
1443         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Deleted.
1444         (bmalloc::Heap::scheduleScavenger): Deleted.
1445         * bmalloc/Heap.h:
1446         * bmalloc/Scavenger.cpp:
1447         (bmalloc::Scavenger::Scavenger):
1448         (bmalloc::Scavenger::run):
1449         (bmalloc::Scavenger::runHoldingLock):
1450         (bmalloc::Scavenger::runSoon):
1451         (bmalloc::Scavenger::runSoonHoldingLock):
1452         (bmalloc::Scavenger::didStartGrowing):
1453         (bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
1454         (bmalloc::Scavenger::scheduleIfUnderMemoryPressureHoldingLock):
1455         (bmalloc::Scavenger::schedule):
1456         (bmalloc::Scavenger::threadEntryPoint):
1457         (bmalloc::Scavenger::threadRunLoop):
1458         (bmalloc::Scavenger::setSelfQOSClass):
1459         * bmalloc/Scavenger.h:
1460         (bmalloc::Scavenger::willRun):
1461         (bmalloc::Scavenger::willRunSoon):
1462
1463 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
1464
1465         bmalloc mutex should be adaptive
1466         https://bugs.webkit.org/show_bug.cgi?id=177839
1467
1468         Reviewed by Michael Saboff.
1469         
1470         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
1471         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
1472         anything other than malloc.
1473
1474         Reland after fixing ancient WordLock bug: the notify_one has to happen with the lock held
1475         to ensure it doesn't run after that thread has died.
1476
1477         * bmalloc/Algorithm.h:
1478         (bmalloc::compareExchangeWeak):
1479         (bmalloc::compareExchangeStrong):
1480         * bmalloc/PerThread.h:
1481         * bmalloc/StaticMutex.cpp:
1482         (bmalloc::StaticMutex::lockSlow):
1483         (bmalloc::StaticMutex::unlockSlow):
1484         (bmalloc::StaticMutex::lockSlowCase): Deleted.
1485         * bmalloc/StaticMutex.h:
1486         (bmalloc::StaticMutex::try_lock):
1487         (bmalloc::StaticMutex::isLocked const):
1488         (bmalloc::StaticMutex::init):
1489         (bmalloc::StaticMutex::tryLock):
1490         (bmalloc::StaticMutex::lock):
1491         (bmalloc::StaticMutex::unlock):
1492         (bmalloc::sleep): Deleted.
1493         (bmalloc::waitUntilFalse): Deleted.
1494
1495 2017-10-05  Matt Lewis  <jlewis3@apple.com>
1496
1497         Unreviewed, rolling out r222893.
1498
1499         This caused multiple API failures.
1500
1501         Reverted changeset:
1502
1503         "bmalloc mutex should be adaptive"
1504         https://bugs.webkit.org/show_bug.cgi?id=177839
1505         http://trac.webkit.org/changeset/222893
1506
1507 2017-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1508
1509         [Linux] Port MallocBench
1510         https://bugs.webkit.org/show_bug.cgi?id=177856
1511
1512         Reviewed by Filip Pizlo.
1513
1514         * CMakeLists.txt:
1515
1516 2017-10-04  Filip Pizlo  <fpizlo@apple.com>
1517
1518         bmalloc mutex should be adaptive
1519         https://bugs.webkit.org/show_bug.cgi?id=177839
1520
1521         Reviewed by Michael Saboff.
1522         
1523         This pulls the WordLock algorithm into bmalloc, mostly by copy-pasting the code. We need to
1524         copy paste because sometimes we build WTF without bmalloc, so WTF cannot rely on bmalloc for
1525         anything other than malloc.
1526
1527         * bmalloc/Algorithm.h:
1528         (bmalloc::compareExchangeWeak):
1529         (bmalloc::compareExchangeStrong):
1530         * bmalloc/PerThread.h:
1531         * bmalloc/StaticMutex.cpp:
1532         (bmalloc::StaticMutex::lockSlow):
1533         (bmalloc::StaticMutex::unlockSlow):
1534         (bmalloc::StaticMutex::lockSlowCase): Deleted.
1535         * bmalloc/StaticMutex.h:
1536         (bmalloc::StaticMutex::try_lock):
1537         (bmalloc::StaticMutex::isLocked const):
1538         (bmalloc::StaticMutex::init):
1539         (bmalloc::StaticMutex::tryLock):
1540         (bmalloc::StaticMutex::lock):
1541         (bmalloc::StaticMutex::unlock):
1542         (bmalloc::sleep): Deleted.
1543         (bmalloc::waitUntilFalse): Deleted.
1544
1545 2017-10-02  Yusuke Suzuki  <utatane.tea@gmail.com>
1546
1547         [Linux] Enable Gigacage in x64 Linux environment
1548         https://bugs.webkit.org/show_bug.cgi?id=177745
1549
1550         Reviewed by Carlos Garcia Campos.
1551
1552         This patch enables Gigacage in x64 Linux environment.
1553         Gigacage enforces a caged pointer to reference to the
1554         specific memory region. This reduces the effectiveness
1555         of some types of attacks setting a pointer to ArrayBuffer
1556         and modifying arbitrary memory region.
1557
1558         * bmalloc/Gigacage.h:
1559
1560 2017-09-29  Commit Queue  <commit-queue@webkit.org>
1561
1562         Unreviewed, rolling out r222625.
1563         https://bugs.webkit.org/show_bug.cgi?id=177664
1564
1565         causes crashes on iOS (Requested by pizlo-mbp on #webkit).
1566
1567         Reverted changeset:
1568
1569         "Enable gigacage on iOS"
1570         https://bugs.webkit.org/show_bug.cgi?id=177586
1571         http://trac.webkit.org/changeset/222625
1572
1573 2017-09-28  Filip Pizlo  <fpizlo@apple.com>
1574
1575         Enable gigacage on iOS
1576         https://bugs.webkit.org/show_bug.cgi?id=177586
1577
1578         Reviewed by Michael Saboff.
1579         
1580         This enables Gigacage on iOS using a much smaller cage size. It's not necessary for it to be so
1581         small, but this is a good conservative starting point to start to exercise the code.
1582
1583         * bmalloc/Gigacage.h:
1584
1585 2017-09-26  Filip Pizlo  <fpizlo@apple.com>
1586
1587         Put g_gigacageBasePtr into its own page and make it read-only
1588         https://bugs.webkit.org/show_bug.cgi?id=174972
1589
1590         Reviewed by Michael Saboff.
1591         
1592         This puts the gigacage base pointers into their own page and makes that page read-only.
1593
1594         * bmalloc/Gigacage.cpp:
1595         (Gigacage::ensureGigacage):
1596         (Gigacage::disablePrimitiveGigacage):
1597         (Gigacage::addPrimitiveDisableCallback):
1598         * bmalloc/Gigacage.h:
1599         (Gigacage::basePtr):
1600         (Gigacage::basePtrs):
1601
1602 2017-09-04  Adrian Perez de Castro  <aperez@igalia.com>
1603
1604         Unreviewed build fix for Clang with libc++
1605
1606         Fixes a build failure when building with Clang, -stdlib=libc++, and gigacage
1607         support enabled, which resulted in "stderr" being undefined.
1608
1609         * bmalloc/Gigacage.cpp: Add missing <ctsdio> include to pull the definition.
1610
1611 2017-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1612
1613         Large virtual memory region allocation requires MMAP_NORESERVE in Linux
1614         https://bugs.webkit.org/show_bug.cgi?id=176211
1615
1616         Reviewed by Geoffrey Garen.
1617
1618         In Linux, we cannot allocate very large memory region without MMAP_NORESERVE.
1619         Linux kernel needs to reserve swap area for allocated memory region. If the
1620         swap area is exhausted, kernel fails to allocate the memory region with ENOMEM.
1621
1622         This patch adds MMAP_NORESERVE to mmap flags in Linux. By adding this flag,
1623         mmap does not need to reserve swap area for the reserved memory region.
1624         This allows us to reserve very large memory region that is necessary for Gigacage.
1625
1626         * bmalloc/BPlatform.h:
1627         * bmalloc/VMAllocate.h:
1628         (bmalloc::tryVMAllocate):
1629
1630 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
1631
1632         Strings need to be in some kind of gigacage
1633         https://bugs.webkit.org/show_bug.cgi?id=174924
1634
1635         Reviewed by Oliver Hunt.
1636         
1637         This adds a StringGigacage.
1638
1639         * bmalloc/Gigacage.cpp:
1640         * bmalloc/Gigacage.h:
1641         (Gigacage::name):
1642         (Gigacage::basePtr):
1643         (Gigacage::forEachKind):
1644         * bmalloc/HeapKind.h:
1645         (bmalloc::isGigacage):
1646         (bmalloc::gigacageKind):
1647         (bmalloc::heapKind):
1648
1649 2017-08-30  Matt Lewis  <jlewis3@apple.com>
1650
1651         Unreviewed, rolling out r221384.
1652
1653         This patch caused multiple 32-bit JSC test failures.
1654
1655         Reverted changeset:
1656
1657         "Strings need to be in some kind of gigacage"
1658         https://bugs.webkit.org/show_bug.cgi?id=174924
1659         http://trac.webkit.org/changeset/221384
1660
1661 2017-08-22  Filip Pizlo  <fpizlo@apple.com>
1662
1663         Strings need to be in some kind of gigacage
1664         https://bugs.webkit.org/show_bug.cgi?id=174924
1665
1666         Reviewed by Oliver Hunt.
1667         
1668         This adds a StringGigacage.
1669
1670         * bmalloc/Gigacage.cpp:
1671         * bmalloc/Gigacage.h:
1672         (Gigacage::name):
1673         (Gigacage::basePtr):
1674         (Gigacage::forEachKind):
1675         * bmalloc/HeapKind.h:
1676         (bmalloc::isGigacage):
1677         (bmalloc::gigacageKind):
1678         (bmalloc::heapKind):
1679
1680 2017-08-25  Daniel Bates  <dabates@apple.com>
1681
1682         Demarcate code added due to lack of NSDMI for aggregates
1683         https://bugs.webkit.org/show_bug.cgi?id=175990
1684
1685         Reviewed by Andy Estes.
1686
1687         * bmalloc/BPlatform.h:
1688         * bmalloc/List.h: Be explicit when initializing m_node to improve readability.
1689         (bmalloc::ListNode::ListNode):
1690
1691 2017-08-23  Filip Pizlo  <fpizlo@apple.com>
1692
1693         Reduce Gigacage sizes
1694         https://bugs.webkit.org/show_bug.cgi?id=175920
1695
1696         Reviewed by Mark Lam.
1697
1698         This introduces the ability to have different gigacage sizes for different gigacages, and uses it to reduce the size of both
1699         gigacages, but to different extents: Primitive gets 32GB with a 16GB runway and JSValue gets 16GB.
1700
1701         This is a ~10% membuster progression on my Mac Pro.
1702
1703         * bmalloc/Gigacage.cpp:
1704         (Gigacage::ensureGigacage):
1705         * bmalloc/Gigacage.h:
1706         (Gigacage::size):
1707         (Gigacage::alignment):
1708         (Gigacage::mask):
1709         (Gigacage::runway):
1710         (Gigacage::totalSize):
1711         (Gigacage::caged):
1712         * bmalloc/Heap.cpp:
1713         (bmalloc::Heap::Heap):
1714         (bmalloc::Heap::gigacageSize):
1715         * bmalloc/Heap.h:
1716
1717 2017-08-08  Filip Pizlo  <fpizlo@apple.com>
1718
1719         Baseline JIT should do caging
1720         https://bugs.webkit.org/show_bug.cgi?id=175037
1721
1722         Reviewed by Mark Lam.
1723         
1724         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
1725         and WebProcess.
1726         
1727         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
1728         checks on each typed array access.
1729
1730         * bmalloc/Gigacage.cpp:
1731         (Gigacage::primitiveGigacageDisabled):
1732         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
1733         (Gigacage::isDisablingPrimitiveGigacageDisabled):
1734         * bmalloc/Gigacage.h:
1735         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
1736         (Gigacage::canPrimitiveGigacageBeDisabled):
1737
1738 2017-08-08  Ryan Haddad  <ryanhaddad@apple.com>
1739
1740         Unreviewed, rolling out r220368.
1741
1742         This change caused WK1 tests to exit early with crashes.
1743
1744         Reverted changeset:
1745
1746         "Baseline JIT should do caging"
1747         https://bugs.webkit.org/show_bug.cgi?id=175037
1748         http://trac.webkit.org/changeset/220368
1749
1750 2017-08-07  Filip Pizlo  <fpizlo@apple.com>
1751
1752         Baseline JIT should do caging
1753         https://bugs.webkit.org/show_bug.cgi?id=175037
1754
1755         Reviewed by Mark Lam.
1756         
1757         This centralizes the notion of permanently enabling the primitive gigacage, which we only do in jsc
1758         and WebProcess.
1759         
1760         This saves the baseline JIT from emitting some code. Otherwise it would always have to emit enabled
1761         checks on each typed array access.
1762
1763         * bmalloc/Gigacage.cpp:
1764         (Gigacage::primitiveGigacageDisabled):
1765         (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled):
1766         (Gigacage::isDisablingPrimitiveGigacageDisabled):
1767         * bmalloc/Gigacage.h:
1768         (Gigacage::isPrimitiveGigacagePermanentlyEnabled):
1769         (Gigacage::canPrimitiveGigacageBeDisabled):
1770
1771 2017-08-06  Filip Pizlo  <fpizlo@apple.com>
1772
1773         Primitive auxiliaries and JSValue auxiliaries should have separate gigacages
1774         https://bugs.webkit.org/show_bug.cgi?id=174919
1775
1776         Reviewed by Keith Miller.
1777         
1778         This introduces two kinds of Gigacage, Primitive and JSValue. This translates to two kinds of
1779         HeapKind, PrimitiveGigacage and JSValueGigacage.
1780         
1781         The new support functionality required turning Inline.h into BInline.h, and INLINE into BINLINE, and
1782         NO_INLINE into BNO_INLINE.
1783
1784         * bmalloc.xcodeproj/project.pbxproj:
1785         * bmalloc/Allocator.cpp:
1786         (bmalloc::Allocator::refillAllocatorSlowCase):
1787         (bmalloc::Allocator::refillAllocator):
1788         (bmalloc::Allocator::allocateLarge):
1789         (bmalloc::Allocator::allocateLogSizeClass):
1790         * bmalloc/AsyncTask.h:
1791         * bmalloc/BInline.h: Copied from Source/bmalloc/bmalloc/Inline.h.
1792         * bmalloc/Cache.cpp:
1793         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
1794         (bmalloc::Cache::allocateSlowCaseNullCache):
1795         (bmalloc::Cache::deallocateSlowCaseNullCache):
1796         (bmalloc::Cache::reallocateSlowCaseNullCache):
1797         * bmalloc/Deallocator.cpp:
1798         * bmalloc/Gigacage.cpp:
1799         (Gigacage::PrimitiveDisableCallbacks::PrimitiveDisableCallbacks):
1800         (Gigacage::ensureGigacage):
1801         (Gigacage::disablePrimitiveGigacage):
1802         (Gigacage::addPrimitiveDisableCallback):
1803         (Gigacage::removePrimitiveDisableCallback):
1804         (Gigacage::Callbacks::Callbacks): Deleted.
1805         (Gigacage::disableGigacage): Deleted.
1806         (Gigacage::addDisableCallback): Deleted.
1807         (Gigacage::removeDisableCallback): Deleted.
1808         * bmalloc/Gigacage.h:
1809         (Gigacage::name):
1810         (Gigacage::basePtr):
1811         (Gigacage::forEachKind):
1812         (Gigacage::caged):
1813         (Gigacage::isCaged):
1814         * bmalloc/Heap.cpp:
1815         (bmalloc::Heap::Heap):
1816         (bmalloc::Heap::usingGigacage):
1817         (bmalloc::Heap::gigacageBasePtr):
1818         * bmalloc/Heap.h:
1819         * bmalloc/HeapKind.h:
1820         (bmalloc::isGigacage):
1821         (bmalloc::gigacageKind):
1822         (bmalloc::heapKind):
1823         * bmalloc/Inline.h: Removed.
1824         * bmalloc/Map.h:
1825         * bmalloc/PerProcess.h:
1826         (bmalloc::PerProcess<T>::getFastCase):
1827         (bmalloc::PerProcess<T>::get):
1828         (bmalloc::PerProcess<T>::getSlowCase):
1829         * bmalloc/PerThread.h:
1830         (bmalloc::PerThread<T>::getFastCase):
1831         * bmalloc/Vector.h:
1832         (bmalloc::Vector<T>::push):
1833         (bmalloc::Vector<T>::shrinkCapacity):
1834         (bmalloc::Vector<T>::growCapacity):
1835
1836 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
1837
1838         If Gigacage is disabled, bmalloc should service large aligned memory allocation requests through vmAllocate
1839         https://bugs.webkit.org/show_bug.cgi?id=175085
1840
1841         Reviewed by Saam Barati.
1842         
1843         This fixes a problem where if we used gmalloc, WebAssembly memory allocations would still use
1844         bmalloc's large allocator.
1845         
1846         We want to use the page allocator for those "large" allocations when the Gigacage is disabled.
1847
1848         * bmalloc/DebugHeap.cpp:
1849         (bmalloc::DebugHeap::DebugHeap):
1850         (bmalloc::DebugHeap::memalignLarge):
1851         (bmalloc::DebugHeap::freeLarge):
1852         * bmalloc/DebugHeap.h:
1853         * bmalloc/Heap.cpp:
1854         (bmalloc::Heap::tryAllocateLarge):
1855         (bmalloc::Heap::deallocateLarge):
1856
1857 2017-08-02  Filip Pizlo  <fpizlo@apple.com>
1858
1859         We should be OK with the gigacage being disabled on gmalloc
1860         https://bugs.webkit.org/show_bug.cgi?id=175082
1861
1862         Reviewed by Michael Saboff.
1863         
1864         This adds Gigacage::shouldBeEnabled(), which returns false when we're using gmalloc or other things
1865         that enable DebugHeap.
1866
1867         * bmalloc/Environment.cpp:
1868         (bmalloc::Environment::Environment):
1869         * bmalloc/Environment.h:
1870         * bmalloc/Gigacage.cpp:
1871         (Gigacage::ensureGigacage):
1872         (Gigacage::shouldBeEnabled):
1873         * bmalloc/Gigacage.h:
1874         * bmalloc/Heap.cpp:
1875         (bmalloc::Heap::Heap):
1876         * bmalloc/Heap.h:
1877
1878 2017-08-01  Filip Pizlo  <fpizlo@apple.com>
1879
1880         Bmalloc and GC should put auxiliaries (butterflies, typed array backing stores) in a gigacage (separate multi-GB VM region)
1881         https://bugs.webkit.org/show_bug.cgi?id=174727
1882
1883         Reviewed by Mark Lam.
1884         
1885         This adds a mechanism for managing multiple isolated heaps in bmalloc. For now, these isoheaps
1886         (isolated heaps) have a very simple relationship with each other and with the rest of bmalloc:
1887         
1888         - You have to choose how many isoheaps you will have statically. See numHeaps in HeapKind.h.
1889         
1890         - Because numHeaps is static, each isoheap gets fast thread-local allocation. Basically, we have a
1891           Cache for each heap kind.
1892         
1893         - Each isoheap gets its own Heap.
1894         
1895         - Each Heap gets a scavenger thread.
1896         
1897         - Some things, like Zone/VMHeap/Scavenger, are per-process.
1898         
1899         Most of the per-HeapKind functionality is handled by PerHeapKind<>.
1900         
1901         This approach is ideal for supporting special per-HeapKind behaviors. For now we have two heaps:
1902         the Primary heap for normal malloc and the Gigacage. The gigacage is a 64GB-aligned 64GB virtual
1903         region that we now use for variable-length random-access allocations. No Primary allocations will
1904         go into the Gigacage.
1905
1906         * CMakeLists.txt:
1907         * bmalloc.xcodeproj/project.pbxproj:
1908         * bmalloc/AllocationKind.h: Added.
1909         * bmalloc/Allocator.cpp:
1910         (bmalloc::Allocator::Allocator):
1911         (bmalloc::Allocator::tryAllocate):
1912         (bmalloc::Allocator::allocateImpl):
1913         (bmalloc::Allocator::reallocate):
1914         (bmalloc::Allocator::refillAllocatorSlowCase):
1915         (bmalloc::Allocator::allocateLarge):
1916         * bmalloc/Allocator.h:
1917         * bmalloc/BExport.h: Added.
1918         * bmalloc/Cache.cpp:
1919         (bmalloc::Cache::scavenge):
1920         (bmalloc::Cache::Cache):
1921         (bmalloc::Cache::tryAllocateSlowCaseNullCache):
1922         (bmalloc::Cache::allocateSlowCaseNullCache):
1923         (bmalloc::Cache::deallocateSlowCaseNullCache):
1924         (bmalloc::Cache::reallocateSlowCaseNullCache):
1925         (bmalloc::Cache::operator new): Deleted.
1926         (bmalloc::Cache::operator delete): Deleted.
1927         * bmalloc/Cache.h:
1928         (bmalloc::Cache::tryAllocate):
1929         (bmalloc::Cache::allocate):
1930         (bmalloc::Cache::deallocate):
1931         (bmalloc::Cache::reallocate):
1932         * bmalloc/Deallocator.cpp:
1933         (bmalloc::Deallocator::Deallocator):
1934         (bmalloc::Deallocator::scavenge):
1935         (bmalloc::Deallocator::processObjectLog):
1936         (bmalloc::Deallocator::deallocateSlowCase):
1937         * bmalloc/Deallocator.h:
1938         * bmalloc/Gigacage.cpp: Added.
1939         (Gigacage::Callback::Callback):
1940         (Gigacage::Callback::function):
1941         (Gigacage::Callbacks::Callbacks):
1942         (Gigacage::ensureGigacage):
1943         (Gigacage::disableGigacage):
1944         (Gigacage::addDisableCallback):
1945         (Gigacage::removeDisableCallback):
1946         * bmalloc/Gigacage.h: Added.
1947         (Gigacage::caged):
1948         (Gigacage::isCaged):
1949         * bmalloc/Heap.cpp:
1950         (bmalloc::Heap::Heap):
1951         (bmalloc::Heap::usingGigacage):
1952         (bmalloc::Heap::concurrentScavenge):
1953         (bmalloc::Heap::splitAndAllocate):
1954         (bmalloc::Heap::tryAllocateLarge):
1955         (bmalloc::Heap::allocateLarge):
1956         (bmalloc::Heap::shrinkLarge):
1957         (bmalloc::Heap::deallocateLarge):
1958         * bmalloc/Heap.h:
1959         (bmalloc::Heap::mutex):
1960         (bmalloc::Heap::kind const):
1961         (bmalloc::Heap::setScavengerThreadQOSClass): Deleted.
1962         * bmalloc/HeapKind.h: Added.
1963         * bmalloc/ObjectType.cpp:
1964         (bmalloc::objectType):
1965         * bmalloc/ObjectType.h:
1966         * bmalloc/PerHeapKind.h: Added.
1967         (bmalloc::PerHeapKindBase::PerHeapKindBase):
1968         (bmalloc::PerHeapKindBase::size):
1969         (bmalloc::PerHeapKindBase::at):
1970         (bmalloc::PerHeapKindBase::at const):
1971         (bmalloc::PerHeapKindBase::operator[]):
1972         (bmalloc::PerHeapKindBase::operator[] const):
1973         (bmalloc::StaticPerHeapKind::StaticPerHeapKind):
1974         (bmalloc::PerHeapKind::PerHeapKind):
1975         (bmalloc::PerHeapKind::~PerHeapKind):
1976         * bmalloc/PerThread.h:
1977         (bmalloc::PerThread<T>::destructor):
1978         (bmalloc::PerThread<T>::getSlowCase):
1979         (bmalloc::PerThreadStorage<Cache>::get): Deleted.
1980         (bmalloc::PerThreadStorage<Cache>::init): Deleted.
1981         * bmalloc/Scavenger.cpp: Added.
1982         (bmalloc::Scavenger::Scavenger):
1983         (bmalloc::Scavenger::scavenge):
1984         * bmalloc/Scavenger.h: Added.
1985         (bmalloc::Scavenger::setScavengerThreadQOSClass):
1986         (bmalloc::Scavenger::requestedScavengerThreadQOSClass const):
1987         * bmalloc/VMHeap.cpp:
1988         (bmalloc::VMHeap::VMHeap):
1989         (bmalloc::VMHeap::tryAllocateLargeChunk):
1990         * bmalloc/VMHeap.h:
1991         * bmalloc/Zone.cpp:
1992         (bmalloc::Zone::Zone):
1993         * bmalloc/Zone.h:
1994         * bmalloc/bmalloc.h:
1995         (bmalloc::api::tryMalloc):
1996         (bmalloc::api::malloc):
1997         (bmalloc::api::tryMemalign):
1998         (bmalloc::api::memalign):
1999         (bmalloc::api::realloc):
2000         (bmalloc::api::tryLargeMemalignVirtual):
2001         (bmalloc::api::free):
2002         (bmalloc::api::freeLargeVirtual):
2003         (bmalloc::api::scavengeThisThread):
2004         (bmalloc::api::scavenge):
2005         (bmalloc::api::isEnabled):
2006         (bmalloc::api::setScavengerThreadQOSClass):
2007         * bmalloc/mbmalloc.cpp:
2008
2009 2017-08-01  Daewoong Jang  <daewoong.jang@navercorp.com>
2010
2011         Implement __builtin_clzl for MSVC
2012         https://bugs.webkit.org/show_bug.cgi?id=174232
2013
2014         Reviewed by Geoffrey Garen.
2015
2016         * bmalloc/Algorithm.h:
2017         (bmalloc::clzl):
2018         (bmalloc::clzl<1>):
2019         (bmalloc::__builtin_clzl):
2020         * bmalloc/BPlatform.h:
2021
2022 2017-07-31  Mark Lam  <mark.lam@apple.com>
2023
2024         Fixed some comment typos.
2025
2026         Not reviewed.
2027
2028         * bmalloc/PerProcess.h:
2029
2030 2017-07-14  Filip Pizlo  <fpizlo@apple.com>
2031
2032         It should be easy to decide how WebKit yields
2033         https://bugs.webkit.org/show_bug.cgi?id=174298
2034
2035         Reviewed by Saam Barati.
2036         
2037         Use sched_yield() explicitly.
2038
2039         * bmalloc/StaticMutex.cpp:
2040         (bmalloc::StaticMutex::lockSlowCase):
2041
2042 2017-07-20  Chris Dumez  <cdumez@apple.com>
2043
2044         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable
2045         https://bugs.webkit.org/show_bug.cgi?id=174660
2046
2047         Reviewed by Geoffrey Garen.
2048
2049         Replace calls to Vector::resize() with calls to more efficient shrink() / grow() when applicable.
2050         This essentially replaces a branch to figure out if the new size is less or greater than the
2051         current size by an assertion.
2052
2053         * bmalloc/Map.h:
2054         (bmalloc::Hash>::rehash):
2055
2056 2017-07-18  Andy Estes  <aestes@apple.com>
2057
2058         [Xcode] Enable CLANG_WARN_RANGE_LOOP_ANALYSIS
2059         https://bugs.webkit.org/show_bug.cgi?id=174631
2060
2061         Reviewed by Tim Horton.
2062
2063         * Configurations/Base.xcconfig:
2064
2065 2017-07-18  Andy Estes  <aestes@apple.com>
2066
2067         [Xcode] Enable CLANG_WARN_OBJC_LITERAL_CONVERSION
2068         https://bugs.webkit.org/show_bug.cgi?id=174631
2069
2070         Reviewed by Sam Weinig.
2071
2072         * Configurations/Base.xcconfig:
2073
2074 2017-07-18  Andy Estes  <aestes@apple.com>
2075
2076         [Xcode] Enable CLANG_WARN_NON_LITERAL_NULL_CONVERSION
2077         https://bugs.webkit.org/show_bug.cgi?id=174631
2078
2079         Reviewed by Dan Bernstein.
2080
2081         * Configurations/Base.xcconfig:
2082
2083 2017-07-18  Andy Estes  <aestes@apple.com>
2084
2085         [Xcode] Enable CLANG_WARN_BLOCK_CAPTURE_AUTORELEASING
2086         https://bugs.webkit.org/show_bug.cgi?id=174631
2087
2088         Reviewed by Darin Adler.
2089
2090         * Configurations/Base.xcconfig:
2091
2092 2017-07-12  Adrian Perez de Castro  <aperez@igalia.com>
2093
2094         bmalloc: Failure to build when the compiler specifically targets ARMv8-A / defines __ARM_ARCH_8A__
2095         https://bugs.webkit.org/show_bug.cgi?id=174424
2096
2097         Reviewed by Michael Catanzaro.
2098
2099         * bmalloc/BPlatform.h: Also check for __ARCH_ARM_8A__ to detect ARMv8.
2100
2101 2017-07-05  Daewoong Jang  <daewoong.jang@navercorp.com>
2102
2103         reinterpret_cast does not evaluate to constexpr
2104         https://bugs.webkit.org/show_bug.cgi?id=173622
2105
2106         Reviewed by Yusuke Suzuki.
2107
2108         * bmalloc/Algorithm.h:
2109         (bmalloc::mask):
2110         (bmalloc::roundUpToMultipleOf):
2111
2112 2017-07-03  Andy Estes  <aestes@apple.com>
2113
2114         [Xcode] Add an experimental setting to build with ccache
2115         https://bugs.webkit.org/show_bug.cgi?id=173875
2116
2117         Reviewed by Tim Horton.
2118
2119         * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig.
2120
2121 2017-07-01  Dan Bernstein  <mitz@apple.com>
2122
2123         [iOS] Remove code only needed when building for iOS 9.x
2124         https://bugs.webkit.org/show_bug.cgi?id=174068
2125
2126         Reviewed by Tim Horton.
2127
2128         * bmalloc/BPlatform.h:
2129         * bmalloc/VMAllocate.h:
2130         (bmalloc::vmPageSizePhysical):
2131
2132 2017-07-01  Dan Bernstein  <mitz@apple.com>
2133
2134         [macOS] Remove code only needed when building for OS X Yosemite
2135         https://bugs.webkit.org/show_bug.cgi?id=174067
2136
2137         Reviewed by Tim Horton.
2138
2139         * Configurations/Base.xcconfig:
2140         * Configurations/DebugRelease.xcconfig:
2141
2142 2017-06-30  Ryosuke Niwa  <rniwa@webkit.org>
2143
2144         Ran sort-Xcode-project-file.
2145
2146         * bmalloc.xcodeproj/project.pbxproj:
2147
2148 2017-06-19  Geoffrey Garen  <ggaren@apple.com>
2149
2150         bmalloc: Add a per-thread line cache
2151         https://bugs.webkit.org/show_bug.cgi?id=173552
2152
2153         Reviewed by Darin Adler.
2154
2155         Previously, any thread could allocate out of any page with free lines.
2156         Now, the first thread to free a line in a page owns that page's free
2157         lines until the whole page becomes free.
2158
2159         This patch is a big speedup on multi-threaded benchmarks.
2160         tree_churn --parallel gets 14% faster on a 2-core (4-hyper-core) MacBook
2161         Air and 2.85X faster on 12-core (24-hyper-core) Mac Pro. Other parallel
2162         benchmarks show significant but smaller speedups.
2163
2164         Thread affinity is a great predictor of object lifetime. The per-thread
2165         line cache avoids the pathology of shuffling pages between threads,
2166         turning predictable lifetimes into unpredictable lifetimes, increasing
2167         fragmentation. On tree_churn --parallel, the per-thread line cache
2168         increases free memory found per page scanned by 2.85X.
2169
2170         Free line scanning in fragmented pages is pretty expensive relative to
2171         other allocate / initialize / free operations. According to Instruments,
2172         on tree_churn --parallel, scanning is about 10X more expensive than
2173         freeing. This explains why a 2.85X improvement in scanning efficiency
2174         translates into a 2.85X overall speedup on tree_churn --parallel.
2175
2176         * bmalloc/Allocator.cpp:
2177         (bmalloc::Allocator::refillAllocatorSlowCase): Pass through our line
2178         cache so the Heap can fill it.
2179
2180         * bmalloc/Deallocator.cpp:
2181         (bmalloc::Deallocator::scavenge): Scavenge our line cache.
2182
2183         (bmalloc::Deallocator::processObjectLog): Deleted.
2184
2185         * bmalloc/Deallocator.h:
2186         (bmalloc::Deallocator::lineCache): Added a line cache.
2187
2188         * bmalloc/Heap.cpp:
2189         (bmalloc::Heap::deallocateLineCache): Deallocation function for thread
2190         destruction.
2191
2192         (bmalloc::Heap::allocateSmallPage):
2193         (bmalloc::Heap::deallocateSmallLine):
2194         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2195         (bmalloc::Heap::allocateSmallBumpRangesByObject): Consult the new per-thread line
2196         cache for allocation and deallocation.
2197
2198         * bmalloc/Heap.h:
2199         (bmalloc::Heap::allocateSmallBumpRanges):
2200         (bmalloc::Heap::derefSmallLine):
2201
2202         * bmalloc/List.h:
2203         (bmalloc::List::remove): Remove has always been a logically static
2204         operation. Declare it static now so that the Heap can remove a page from
2205         a thread's line cache without holding a direct pointer to the cache.
2206
2207         * bmalloc/SmallPage.h:
2208
2209 2017-06-10  Dan Bernstein  <mitz@apple.com>
2210
2211         Reverted r218056 because it made the IDE reindex constantly.
2212
2213         * Configurations/DebugRelease.xcconfig:
2214
2215 2017-06-10  Dan Bernstein  <mitz@apple.com>
2216
2217         [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE
2218         https://bugs.webkit.org/show_bug.cgi?id=173223
2219
2220         Reviewed by Sam Weinig.
2221
2222         The rebuilds were happening due to a difference in the compiler options that the IDE and
2223         xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make
2224         xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and
2225         specify an appropriate path in CLANG_INDEX_STORE_PATH.
2226
2227         * Configurations/DebugRelease.xcconfig:
2228
2229 2017-06-07  Geoffrey Garen  <ggaren@apple.com>
2230
2231         bmalloc: memory APIs don't need to be heap members
2232         https://bugs.webkit.org/show_bug.cgi?id=173076
2233
2234         Reviewed by Sam Weinig.
2235
2236         Asking the OS about memory use is unrelated to the state of bmalloc's
2237         heap, so it's a better separation of concerns if related code is not 
2238         part of the heap.
2239
2240         * bmalloc/AvailableMemory.cpp:
2241         (bmalloc::memoryStatus):
2242         * bmalloc/AvailableMemory.h:
2243         (bmalloc::MemoryStatus::MemoryStatus):
2244         (bmalloc::isUnderMemoryPressure):
2245         (bmalloc::memoryFootprint):
2246         (bmalloc::percentAvailableMemoryInUse):
2247         * bmalloc/Heap.cpp:
2248         (bmalloc::Heap::Heap):
2249         (bmalloc::Heap::updateMemoryInUseParameters): Deleted.
2250         * bmalloc/Heap.h:
2251         (bmalloc::Heap::isUnderMemoryPressure): Deleted.
2252         (bmalloc::Heap::memoryFootprint): Deleted.
2253         (bmalloc::Heap::percentAvailableMemoryInUse): Deleted.
2254
2255 2017-06-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2256
2257         struct does not accept initializer-form if member has initializers in GCC 4.9
2258         https://bugs.webkit.org/show_bug.cgi?id=172974
2259
2260         Reviewed by Carlos Garcia Campos.
2261
2262         struct cannot accept initializer-form constructor (like, `ListNode<T> t { ... }`) if
2263         the member of the struct has a default initializer.
2264         Here is a simple snippet.
2265
2266         template<typename T>
2267         struct Pair {
2268             T* prev { nullptr };
2269             T* next { nullptr };
2270         };
2271
2272         Pair<int> pair { nullptr, nullptr };  // compile erorr in GCC 4.9.
2273
2274         Instead, we define a default constructor (to invoke default initializers) and a constructor
2275         to accept the above initialization.
2276
2277         * bmalloc/List.h:
2278         (bmalloc::ListNode::ListNode):
2279         (bmalloc::List::iterator::iterator):
2280
2281 2017-06-06  Geoffrey Garen  <ggaren@apple.com>
2282
2283         Try to fix the GTK build.
2284
2285         Unreviewed.
2286
2287         * bmalloc/List.h:
2288         (bmalloc::List::List):
2289
2290 2017-06-05  Geoffrey Garen  <ggaren@apple.com>
2291
2292         Try to fix the GTK build.
2293
2294         Unreviewed.
2295
2296         * bmalloc/List.h:
2297
2298 2017-06-02  Geoffrey Garen  <ggaren@apple.com>
2299
2300         bmalloc: Small and large objects should share memory
2301         https://bugs.webkit.org/show_bug.cgi?id=172880
2302         <rdar://problem/31494732>
2303
2304         Reviewed by Sam Weinig.
2305
2306         This reduces our high water mark memory usage on JetStream on macOS
2307         by 10%-20%. It also has the nice side effect that we can free small
2308         object metadata after returning from a high water mark.
2309
2310         No change in throughput.
2311
2312         Our old algorithm allocated small object chunks and large objects in
2313         segregated virtual memory and never recycled addresses between them.
2314         This provided a slight security benefit because we could apply guard
2315         pages between the segregated ranges and we would never reuse the same
2316         virtual address for object and metadata memory.
2317
2318         Our new algorithm allocates small object chunks from the large object
2319         allocator. This naturally recycles memory between small chunks and large
2320         objects, and between small chunks of different page classes. This allows
2321         us to shift memory between allocation types as a program moves between
2322         different phases of allocation, and to delete small object chunk metadata
2323         when a program shrinks back from a high water mark.
2324
2325         Two intuitions I had about memory use turned out to be backwards in
2326         this context:
2327
2328         (1) I thought that this optimization would work because it allowed you to
2329         allocate and free a 4MB object and then reuse that large allocation to
2330         service small allocations. In practice, the common benefit seems to be
2331         the opposite: After you allocate and free many small objects, you can
2332         stitch them together to allocate a large object without growing the heap.
2333
2334         (2) I thought that it would be more memory-efficient to allocate
2335         fine-grained pages from the large object allocator. In practice, giving
2336         the large object allocator too many arbitrarily-sized ranges to manage
2337         leads to fragmentation. Meanwhile, segregated fit is a powerful memory
2338         optimization. So, it's best to return small object memory to the large
2339         allocator only when a whole small object chunk is free.
2340
2341         * bmalloc/Chunk.h:
2342         (bmalloc::Chunk::ref):
2343         (bmalloc::Chunk::deref):
2344         (bmalloc::Chunk::refCount):
2345         (bmalloc::Chunk::freePages): We keep a free list per chunk and refcount
2346         each chunk so we can notice when a chunk becomes empty, and return it
2347         to the large allocator.
2348
2349         (bmalloc::forEachPage): A new helper function for iterating the pages
2350         in a Chunk.
2351
2352         (bmalloc::Chunk::Chunk): Use forEachPage instead of manual iteration.
2353         Use { } initialization because we don't get zero-initialized by the OS
2354         anymore.
2355
2356         * bmalloc/Heap.cpp:
2357         (bmalloc::Heap::Heap):
2358         (bmalloc::Heap::concurrentScavenge):
2359         (bmalloc::Heap::scavenge): Don't bother unlocking while scavenging. I
2360         wasn't able to show it to be a consistent speedup. A more promising
2361         approach, if we find a motivating example, is for the scavenger to give
2362         up and return early if any other client is waiting on the lock.
2363
2364         (bmalloc::Heap::allocateSmallChunk): New helper function for allocating
2365         a small chunk. It allocates through the large allocator to facilitate
2366         sharing. We still allocate a chunk at a time instead of a page at a time.
2367         Surprisingly, more precise page-at-a-time allocation is worse for memory
2368         use because of fragmentation. Segregated fit is a powerful optimization.
2369
2370         (bmalloc::Heap::deallocateSmallChunk): New helper function for deallocating
2371         a small chunk.
2372
2373         (bmalloc::Heap::allocateSmallPage): Updated for new APIs.
2374
2375         (bmalloc::Heap::deallocateSmallLine):  Updated for new APIs. Note that
2376         we cache one free chunk per page class. This avoids churn in the large
2377         allocator when you free(malloc(X)).
2378
2379         (bmalloc::Heap::allocateSmallBumpRangesByMetadata):
2380         (bmalloc::Heap::allocateSmallBumpRangesByObject):
2381         (bmalloc::Heap::tryAllocateLarge):
2382         (bmalloc::Heap::scavengeSmallPages): Deleted.
2383         (bmalloc::Heap::scavengeLargeObjects): Deleted.
2384         * bmalloc/Heap.h:
2385
2386         * bmalloc/LargeMap.h:
2387         (bmalloc::LargeMap::begin):
2388         (bmalloc::LargeMap::end): Added iteration helpers for scavenging.
2389
2390         * bmalloc/LargeRange.h:
2391         (bmalloc::LargeRange::physicalSize): Added a comment about something
2392         that I confused myself about in this patch.
2393
2394         * bmalloc/List.h:
2395         (bmalloc::List::iterator::operator*):
2396         (bmalloc::List::iterator::operator->):
2397         (bmalloc::List::iterator::operator!=):
2398         (bmalloc::List::iterator::operator++):
2399         (bmalloc::List::begin):
2400         (bmalloc::List::end):
2401         (bmalloc::List::pushFront):
2402         (bmalloc::List::remove):
2403         (bmalloc::ListNode::ListNode): Deleted. Added iteration helpers for
2404         scavenging. Changed the default state of a Node to null pointers instead
2405         of self pointers to distinguish the null node from the empty node for
2406         easier debugging.
2407
2408         * bmalloc/Sizes.h: Changed the chunk size to 1MB to increase the chances
2409         of a chunk becoming free and recyclable.
2410
2411         * bmalloc/SmallPage.h:
2412         (bmalloc::SmallPage::hasPhysicalPages):
2413         (bmalloc::SmallPage::setHasPhysicalPages): Track physical state by page
2414         instead of implicitly by which list a page is in. It's simpler not
2415         to have to move chunks and pages between physical vs virtual lists.
2416
2417         (bmalloc::SmallPage::SmallPage): Deleted.
2418
2419         * bmalloc/VMHeap.cpp:
2420         (bmalloc::VMHeap::tryAllocateLargeChunk):
2421         (bmalloc::VMHeap::allocateSmallChunk): Deleted.
2422         * bmalloc/VMHeap.h:
2423         (bmalloc::VMHeap::allocateSmallPage): Deleted.
2424         (bmalloc::VMHeap::deallocateSmallPage): Deleted. Small chunk allocation
2425         just forwards to the large allocator now.
2426
2427         * bmalloc/bmalloc.h:
2428         (bmalloc::api::scavenge):
2429
2430 2017-05-28  Dan Bernstein  <mitz@apple.com>
2431
2432         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
2433         https://bugs.webkit.org/show_bug.cgi?id=172691
2434
2435         Reviewed by Tim Horton.
2436
2437         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
2438
2439 2017-05-25  Geoffrey Garen  <ggaren@apple.com> and Michael Saboff  <msaboff@apple.com>
2440
2441         bmalloc: scavenger runs too much on JetStream
2442         https://bugs.webkit.org/show_bug.cgi?id=172373
2443
2444         Reviewed by Geoffrey Garen.
2445
2446         Instruments says that JetStream on macOS spends about 3% of its time in
2447         madvise.
2448
2449         In <https://bugs.webkit.org/show_bug.cgi?id=160098>, Ben saw some
2450         evidence that madvise was the reason that switching to bmalloc for
2451         DFG::Node allocations was a slowdown the first time around.
2452
2453         In <https://bugs.webkit.org/show_bug.cgi?id=172124>, Michael saw that
2454         scavening policy can affect JetStream.
2455
2456         Intuitively, it seems wrong for the heap to idle shrink during hardcore
2457         benchmarking.
2458
2459         The strategy here is to back off in response to any heap growth event,
2460         and to wait 2s instead of 0.5s for heap growth to take place -- but we
2461         scavenge immediately in response to critical memory pressure, to avoid
2462         jetsam.
2463
2464         One hole in this strategy is that a workload with a perfectly
2465         unfragmented heap that allocates and deallocates ~16kB every 2s will
2466         never shrink its heap. This doesn't seem to be a problem in practice.
2467
2468         This looks like a 2% - 4% speedup on JetStream on Mac Pro and MacBook Air.
2469
2470         * bmalloc/AsyncTask.h:
2471         (bmalloc::AsyncTask::willRun):
2472         (bmalloc::AsyncTask::willRunSoon):
2473         (bmalloc::Function>::AsyncTask):
2474         (bmalloc::Function>::run):
2475         (bmalloc::Function>::runSoon):
2476         (bmalloc::Function>::threadRunLoop):
2477         (bmalloc::Function>::runSlowCase): Deleted. Added a "run soon" state
2478         so that execution delay is modeled directly instead of implicitly
2479         through sleep events. This enables the Heap to issue a "run now" event
2480         at any moment in response ot memory pressure.
2481
2482         * bmalloc/Heap.cpp:
2483         (bmalloc::Heap::Heap): Don't call into our own API -- that's a layering
2484         violation.
2485
2486         (bmalloc::Heap::updateMemoryInUseParameters): No need for
2487         m_scavengeSleepDuration anymore.
2488
2489         (bmalloc::Heap::concurrentScavenge): Added a back-off policy when the
2490         heap is growing.
2491         (bmalloc::Heap::scavenge):
2492
2493         (bmalloc::Heap::scavengeSmallPages):
2494         (bmalloc::Heap::scavengeLargeObjects): Don't try to give up in the middle
2495         of a scavenge event. Our new backoff policy supplants that design. Also,
2496         it's easier to profile and understand scavenging behavior if it always
2497         runs to completion once started.
2498
2499         (bmalloc::Heap::scheduleScavenger):
2500         (bmalloc::Heap::scheduleScavengerIfUnderMemoryPressure): Added a
2501         synchronous amortized check for memory pressure. This check has the
2502         benefit that it runs immediately during high rates of heap activity,
2503         so we can detect memory pressure right away and wake the scavenger
2504         instead of waiting for the scavenger to wake up.
2505
2506         (bmalloc::Heap::allocateSmallPage):
2507         (bmalloc::Heap::deallocateSmallLine):
2508         (bmalloc::Heap::splitAndAllocate):
2509         (bmalloc::Heap::tryAllocateLarge):
2510         (bmalloc::Heap::shrinkLarge):
2511         (bmalloc::Heap::deallocateLarge):
2512         * bmalloc/Heap.h:
2513         (bmalloc::Heap::isUnderMemoryPressure):
2514         * bmalloc/Sizes.h:
2515         * bmalloc/VMHeap.h:
2516         (bmalloc::VMHeap::deallocateSmallPage):
2517         * bmalloc/bmalloc.h:
2518         (bmalloc::api::scavenge): Updated for API changes above.
2519
2520 2017-05-17  Michael Saboff  <msaboff@apple.com>
2521
2522         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info (172186)
2523         https://bugs.webkit.org/show_bug.cgi?id=172186
2524
2525         Reviewed by Geoffrey Garen.
2526
2527         The calls memoryFootprint() and percentAvailableMemoryInUse() now make a system call to get
2528         the current memory footprint value.
2529
2530         * bmalloc/Heap.h:
2531         (bmalloc::Heap::memoryFootprint):
2532         (bmalloc::Heap::percentAvailableMemoryInUse):
2533
2534 2017-05-16  Michael Saboff  <msaboff@apple.com>
2535
2536         REGRESSION(r216763): JetStream is 1% slower on Mac
2537         https://bugs.webkit.org/show_bug.cgi?id=172124
2538
2539         Reviewed by Filip Pizlo.
2540
2541         It appears that changing maxScavengeSleepDuration from 512 to 250ms in r216763 is
2542         responsible for the regression.
2543
2544         * bmalloc/Sizes.h:
2545
2546 2017-05-15  Geoffrey Garen  <ggaren@apple.com>
2547
2548         bmalloc: Bump the size of the deallocator log to 512
2549         https://bugs.webkit.org/show_bug.cgi?id=172143
2550
2551         Reviewed by Michael Saboff.
2552
2553         This is a speedup on parallel workloads for machines with lots of CPUs.
2554
2555         * bmalloc/Sizes.h:
2556
2557 2017-05-12  Michael Saboff  <msaboff@apple.com>
2558
2559         [iOS] Use memory footprint to dynamically adjust behavior of allocators
2560         https://bugs.webkit.org/show_bug.cgi?id=171944
2561
2562         Reviewed by Filip Pizlo.
2563
2564         This change is iOS only.
2565
2566         After the scavenger thread completes scavenging, it asks the OS for how much total memory the
2567         process is using.  This information is used to update the sleep delay for the scanvenger thread,
2568         as well as to provide memory in use data for other parts of the system.
2569
2570         The scavenger sleep time is calculated using the following quadradic equation.
2571
2572             scavengerSleep = 1.2*percentFreeMemory^2 - percentFreeMemory + 2
2573
2574         Where percentFreeMemory is between 0 and 100.  The result is constrained to the values 2 and 250.
2575
2576         This equation empirically works out to providing a 2ms sleep time when we have less than 10%
2577         memory available, 30ms when 20% is available and 250ms when 50% or more is available.  In testing,
2578         this exponentially agressive scavenging delay by itself reduced memory usage and made it much
2579         more deterministic when used without the corresponding change in the JSC Heap.
2580
2581         Changed the scavenger thread to use the User Initiated QOS priority to ensure it doesn't
2582         get starved.
2583
2584         Moved the non-Windows functionality of WTF::RAMSize() to new files AvailableMemory.{cpp,h}
2585         and implemented in the function availableMemory().  That functions limits the value returned
2586         on iOS to a maximum of 840MB as that is the jetsam soft memory limit.
2587         Added a new API availableMemory() so that WTF::RAMSize() will use this value.
2588
2589         * CMakeLists.txt:
2590         * bmalloc.xcodeproj/project.pbxproj:
2591         * bmalloc/BPlatform.h:
2592         * bmalloc/Heap.cpp:
2593         (bmalloc::Heap::Heap):
2594         (bmalloc::Heap::updateMemoryInUseParameters):
2595         (bmalloc::Heap::concurrentScavenge):
2596         (bmalloc::Heap::scavenge):
2597         * bmalloc/Heap.h:
2598         (bmalloc::Heap::memoryFootprint):
2599         (bmalloc::Heap::percentAvailableMemoryInUse):
2600         * bmalloc/Sizes.h:
2601         * bmalloc/bmalloc.h:
2602         (bmalloc::api::availableMemory):
2603         (bmalloc::api::memoryFootprint):
2604         (bmalloc::api::percentAvailableMemoryInUse):
2605         * bmalloc/AvailableMemory.cpp: Added.
2606         (bmalloc::computeAvailableMemory):
2607         (bmalloc::availableMemory):
2608         * bmalloc/AvailableMemory.h: Added.
2609
2610 2017-05-05  Joseph Pecoraro  <pecoraro@apple.com>
2611
2612         Leaks always reports "WebKit Malloc Memory Pressure Handler" dispatch_queue/source as leaking
2613         https://bugs.webkit.org/show_bug.cgi?id=171532
2614
2615         Reviewed by Geoffrey Garen.
2616
2617         * bmalloc/Heap.cpp:
2618         (bmalloc::Heap::Heap):
2619         * bmalloc/Heap.h:
2620         Store the dispatch_source_t in a member to avoid a false positive leak.
2621
2622 2017-04-27  Michael Saboff  <msaboff@apple.com>
2623
2624         bmalloc scavenger should know what page classes are allocating
2625         https://bugs.webkit.org/show_bug.cgi?id=171384
2626
2627         Reviewed by Geoffrey Garen.
2628
2629         This change replaces m_isAllocatingPages with a per page class flag to track which page
2630         classes are currently allocating.  When scavenging, we skip page classes that are actively
2631         allocating and come back to them on a subsequent pass.  This reduces the amount of time it
2632         takes for scavenger to free up pages as well as the total time it takes to handle all
2633         page classes.
2634
2635         * bmalloc/Heap.cpp:
2636         (bmalloc::Heap::Heap):
2637         (bmalloc::Heap::concurrentScavenge):
2638         (bmalloc::Heap::scavenge):
2639         (bmalloc::Heap::scavengeSmallPages):
2640         (bmalloc::Heap::scavengeLargeObjects):
2641         (bmalloc::Heap::allocateSmallPage):
2642         (bmalloc::Heap::splitAndAllocate):
2643         (bmalloc::Heap::deallocateLarge):
2644         * bmalloc/Heap.h:
2645         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass): Deleted.
2646         * bmalloc/VMHeap.h:
2647         (bmalloc::VMHeap::deallocateSmallPage):
2648         * bmalloc/bmalloc.h:
2649         (bmalloc::api::scavenge):
2650
2651 2017-04-25  Michael Saboff  <msaboff@apple.com>
2652
2653         Call bmalloc scavenger first when handling a memory pressure event
2654         https://bugs.webkit.org/show_bug.cgi?id=171289
2655
2656         Reviewed by Geoffrey Garen.
2657
2658         Registered a critical memory pressure handler.  We add this handler in addition to the
2659         call to release bmalloc memory in the WebCore releaseMemory handler for the case of
2660         JSC API users that don't use WebCore.  When both handlers are in the process, it is
2661         basically a race.  One will win, but the loser won't do any more work, so it is harmless.
2662
2663         * bmalloc/Heap.cpp:
2664         (bmalloc::Heap::Heap):
2665
2666 2017-04-14  Mark Lam  <mark.lam@apple.com>
2667
2668         Update architectures in xcconfig files.
2669         https://bugs.webkit.org/show_bug.cgi?id=170867
2670         <rdar://problem/31628104>
2671
2672         Reviewed by Joseph Pecoraro.
2673
2674         * Configurations/Base.xcconfig:
2675
2676 2017-04-12  Dan Bernstein  <mitz@apple.com>
2677
2678         [Mac] Future-proof .xcconfig files
2679         https://bugs.webkit.org/show_bug.cgi?id=170802
2680
2681         Reviewed by Tim Horton.
2682
2683         * Configurations/Base.xcconfig:
2684         * Configurations/DebugRelease.xcconfig:
2685
2686 2017-02-03  Ting-Wei Lan  <lantw44@gmail.com>
2687
2688         Include cstdlib before using ::malloc and posix_memalign
2689         https://bugs.webkit.org/show_bug.cgi?id=167800
2690
2691         Reviewed by Geoffrey Garen.
2692
2693         * bmalloc/DebugHeap.cpp:
2694
2695 2017-02-01  Andreas Kling  <akling@apple.com>
2696
2697         Implement the alwaysRunsAtBackgroundPriority WK2 setting using thread QoS.
2698         <https://webkit.org/b/167387>
2699         <rdar://problem/29711409>
2700
2701         Reviewed by Antti Koivisto.
2702
2703         Support changing the QoS level of the scavenger thread asynchronously through
2704         a request variable. This is not the most elegant thing in the world, but since
2705         threads are only allowed to change their own QoS class, our options are limited.
2706
2707         * bmalloc/Heap.cpp:
2708         (bmalloc::Heap::concurrentScavenge):
2709         * bmalloc/Heap.h:
2710         (bmalloc::Heap::takeRequestedScavengerThreadQOSClass):
2711         (bmalloc::Heap::setScavengerThreadQOSClass):
2712         * bmalloc/bmalloc.h:
2713         (bmalloc::api::setScavengerThreadQOSClass):
2714
2715 2017-01-13  Geoffrey Garen  <ggaren@apple.com>
2716
2717         bmalloc: Use a separate zone when using system malloc
2718         https://bugs.webkit.org/show_bug.cgi?id=167014
2719
2720         Reviewed by Filip Pizlo.
2721
2722         Harris asked for this so he could separate Safari and WebKit memory use
2723         when doing memory analysis.
2724
2725         This patch adds an explicit DebugHeap class that contains all our
2726         code for specialized allocation with debugging.
2727
2728         * bmalloc.xcodeproj/project.pbxproj:
2729
2730         * bmalloc/Allocator.cpp:
2731         (bmalloc::Allocator::Allocator):
2732         (bmalloc::Allocator::tryAllocate):
2733         (bmalloc::Allocator::allocateImpl):
2734         (bmalloc::Allocator::reallocate):
2735         (bmalloc::Allocator::allocateSlowCase):
2736         * bmalloc/Allocator.h: Forward to DebugHeap instead of inlining all the
2737         code. This is required for our new interface, and it is also a nice
2738         simplification that moves some not-very-important code out of the way.
2739
2740         * bmalloc/Deallocator.cpp:
2741         (bmalloc::Deallocator::Deallocator):
2742         (bmalloc::Deallocator::scavenge):
2743         (bmalloc::Deallocator::deallocateSlowCase):
2744         * bmalloc/Deallocator.h: Ditto.
2745
2746         * bmalloc/DebugHeap.cpp: Added.
2747         (bmalloc::DebugHeap::DebugHeap):
2748         (bmalloc::DebugHeap::malloc):
2749         (bmalloc::DebugHeap::memalign):
2750         (bmalloc::DebugHeap::realloc):
2751         (bmalloc::DebugHeap::free):
2752         * bmalloc/DebugHeap.h: Added. New class for overriding normal heap
2753         behavior. Right now, it just adds a malloc zone and then forwards to
2754         system malloc -- but we can add lots more kinds of debug heaps in the
2755         future if we find them useful.
2756
2757         * bmalloc/Environment.cpp:
2758         (bmalloc::Environment::Environment):
2759         (bmalloc::Environment::computeIsDebugHeapEnabled):
2760         (bmalloc::Environment::computeIsBmallocEnabled): Deleted.
2761         * bmalloc/Environment.h:
2762         (bmalloc::Environment::isDebugHeapEnabled):
2763         (bmalloc::Environment::isBmallocEnabled): Deleted. Renamed everything to
2764         reflect our new use of DebugHeap.
2765
2766         * bmalloc/Heap.cpp:
2767         (bmalloc::Heap::Heap):
2768         * bmalloc/Heap.h:
2769         (bmalloc::Heap::debugHeap): Updated to use DebugHeap.
2770         (bmalloc::Heap::environment): Deleted. 
2771
2772         * bmalloc/bmalloc.h:
2773         (bmalloc::api::isEnabled): Updated to use DebugHeap.
2774
2775 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
2776
2777         Sort Xcode project files
2778         https://bugs.webkit.org/show_bug.cgi?id=165937
2779
2780         Reviewed by Simon Fraser.
2781
2782         * bmalloc.xcodeproj/project.pbxproj:
2783
2784 2016-12-08  David Kilzer  <ddkilzer@apple.com>
2785
2786         Always check the return value of pthread_key_create()
2787         <https://webkit.org/b/165274>
2788
2789         Reviewed by Darin Adler.
2790
2791         * bmalloc/PerThread.h:
2792         (bmalloc::PerThreadStorage::init): Call BCRASH() if
2793         pthread_key_create() returns an error.  The error code will be
2794         stored in a register available in a crash log, so no need to log
2795         the value explicitly.
2796
2797 2016-12-06  Alexey Proskuryakov  <ap@apple.com>
2798
2799         Correct SDKROOT values in xcconfig files
2800         https://bugs.webkit.org/show_bug.cgi?id=165487
2801         rdar://problem/29539209
2802
2803         Reviewed by Dan Bernstein.
2804
2805         Fix suggested by Dan Bernstein.
2806
2807         * Configurations/DebugRelease.xcconfig:
2808
2809 2016-11-29  Andy Estes  <aestes@apple.com>
2810
2811         [Cocoa] Enable two clang warnings recommended by Xcode
2812         https://bugs.webkit.org/show_bug.cgi?id=164498
2813
2814         Reviewed by Mark Lam.
2815
2816         * Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
2817
2818 2016-11-10  Geoffrey Garen  <ggaren@apple.com>
2819
2820         bmalloc threads should have a non-default QoS
2821         https://bugs.webkit.org/show_bug.cgi?id=164612
2822
2823         Reviewed by Filip Pizlo.
2824
2825         * bmalloc/AsyncTask.h:
2826         (bmalloc::Function>::threadEntryPoint): Request user-interactive quality
2827         of service because user-interactive tasks use malloc.
2828
2829 2016-10-20  Mark Lam  <mark.lam@apple.com>
2830
2831         bmalloc api should crash on failure to allocate when !isBmallocEnabled.
2832         https://bugs.webkit.org/show_bug.cgi?id=163766
2833
2834         Reviewed by Keith Miller and Filip Pizlo.
2835
2836         We want to crash in bmalloc on failure to allocate even when !isBmallocEnabled.
2837         This is so that failures to allocate memory will manifest as crashes with a
2838         unique signature (i.e. as a SIGTRAP on release builds, or as a write to illegal
2839         address 0xbbadbeef on debug builds) and the crash will manifest inside bmalloc.
2840         This distinguishes allocation failures from other crashing bugs that manifest as
2841         SIGSEGVs due to random pointer dereferences in the clients of bmalloc.
2842
2843         * bmalloc/Allocator.cpp:
2844         (bmalloc::Allocator::allocateImpl):
2845         (bmalloc::Allocator::reallocate):
2846         (bmalloc::Allocator::allocateSlowCase):
2847
2848 2016-09-26  Yoshiaki Jitsukawa  <Yoshiaki.Jitsukawa@sony.com>
2849
2850         Avoid implicit conversion from iterator to pointer
2851         https://bugs.webkit.org/show_bug.cgi?id=162482
2852
2853         Reviewed by Geoffrey Garen.
2854
2855         Not every STL supporting such conversion, we should get a pointer explicitly.
2856
2857         * bmalloc/Chunk.h:
2858         (bmalloc::Chunk::lines):
2859         (bmalloc::Chunk::pages):
2860         * bmalloc/FixedVector.h:
2861         (bmalloc::FixedVector::begin):
2862
2863 2016-08-31  Filip Pizlo  <fpizlo@apple.com>
2864
2865         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
2866         https://bugs.webkit.org/show_bug.cgi?id=160125
2867
2868         Reviewed by Geoffrey Garen and Keith Miller.
2869         
2870         I needed to tryMemalign, so I added such a thing.
2871
2872         * bmalloc/Allocator.cpp:
2873         (bmalloc::Allocator::allocate):
2874         (bmalloc::Allocator::tryAllocate):
2875         (bmalloc::Allocator::allocateImpl):
2876         * bmalloc/Allocator.h:
2877         * bmalloc/Cache.h:
2878         (bmalloc::Cache::tryAllocate):
2879         * bmalloc/bmalloc.h:
2880         (bmalloc::api::tryMemalign):
2881
2882 2016-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2883
2884         Unreviewed, build fix for GCC ports
2885
2886         std::forward is declared in <utility> header.
2887
2888         * bmalloc/ScopeExit.h:
2889
2890 2016-08-30  Geoffrey Garen  <ggaren@apple.com>
2891
2892         bmalloc: speed up the lock slow path
2893         https://bugs.webkit.org/show_bug.cgi?id=161058
2894
2895         Unreviewed roll-in - with regression fixed.
2896
2897         Revert to using yield() instead of swtch() because very low priority
2898         background tasks can cause priority inversion and deadlock. In the
2899         network process, that happened with com.apple.WebKit.Cache.Storage.serialBackground.
2900
2901         Still a big speedup on MallocBench.
2902
2903         * bmalloc.xcodeproj/project.pbxproj:
2904         * bmalloc/ScopeExit.h: Added.
2905         (bmalloc::ScopeExit::ScopeExit):
2906         (bmalloc::ScopeExit::~ScopeExit):
2907         (bmalloc::makeScopeExit):
2908         * bmalloc/StaticMutex.cpp:
2909         (bmalloc::StaticMutex::lockSlowCase):
2910         * bmalloc/StaticMutex.h:
2911         (bmalloc::StaticMutex::init):
2912
2913 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
2914
2915         Unreviewed build fix.
2916
2917         Fix the CMake build.
2918
2919         * CMakeLists.txt:
2920
2921 2016-08-26  Geoffrey Garen  <ggaren@apple.com>
2922
2923         Renamed XLarge* => Large*
2924         https://bugs.webkit.org/show_bug.cgi?id=161261
2925
2926         Reviewed by Andreas Kling.
2927
2928         XLarge is not a thing anymore: We just have Small and Large.
2929
2930         * bmalloc.xcodeproj/project.pbxproj:
2931         * bmalloc/Heap.cpp:
2932         (bmalloc::Heap::splitAndAllocate):
2933         (bmalloc::Heap::tryAllocateLarge):
2934         (bmalloc::Heap::shrinkLarge):
2935         (bmalloc::Heap::deallocateLarge):
2936         * bmalloc/Heap.h:
2937         * bmalloc/LargeMap.cpp: Copied from Source/bmalloc/bmalloc/XLargeMap.cpp.
2938         (bmalloc::LargeMap::remove):
2939         (bmalloc::LargeMap::add):
2940         (bmalloc::XLargeMap::remove): Deleted.
2941         (bmalloc::XLargeMap::add): Deleted.
2942         * bmalloc/LargeMap.h: Copied from Source/bmalloc/bmalloc/XLargeMap.h.
2943         (bmalloc::LargeMap::ranges):
2944         (bmalloc::XLargeMap::ranges): Deleted.
2945         * bmalloc/LargeRange.h: Copied from Source/bmalloc/bmalloc/XLargeRange.h.
2946         (bmalloc::LargeRange::LargeRange):
2947         (bmalloc::LargeRange::operator<):
2948         (bmalloc::canMerge):
2949         (bmalloc::merge):
2950         (bmalloc::LargeRange::split):
2951         (bmalloc::XLargeRange::XLargeRange): Deleted.
2952         (bmalloc::XLargeRange::operator<): Deleted.
2953         (bmalloc::XLargeRange::split): Deleted.
2954         * bmalloc/VMHeap.cpp:
2955         (bmalloc::VMHeap::tryAllocateLargeChunk):
2956         * bmalloc/VMHeap.h:
2957         * bmalloc/XLargeMap.cpp: Removed.
2958         * bmalloc/XLargeMap.h: Removed.
2959         * bmalloc/XLargeRange.h: Removed.
2960
2961 2016-08-26  Gavin Barraclough  <barraclough@apple.com>
2962
2963         bmalloc: speed up the lock slow path
2964         https://bugs.webkit.org/show_bug.cgi?id=161058
2965
2966         Unreviewed rollout - this caused regressions <rdar://problem/28026089>.
2967
2968         * bmalloc.xcodeproj/project.pbxproj:
2969         * bmalloc/ScopeExit.h: Removed.
2970         * bmalloc/StaticMutex.cpp:
2971         (bmalloc::StaticMutex::lockSlowCase):
2972         * bmalloc/StaticMutex.h:
2973         (bmalloc::StaticMutex::init):
2974         * bmalloc/ThreadSwitch.h: Removed.
2975
2976 2016-08-24  Andreas Kling  <akling@apple.com>
2977
2978         Add bmalloc::api::isEnabled().
2979         <https://webkit.org/b/160534>
2980
2981         Reviewed by Joseph Pecoraro.
2982
2983         * bmalloc/bmalloc.h:
2984         (bmalloc::api::isEnabled):
2985
2986 2016-08-24  Filip Pizlo  <fpizlo@apple.com>
2987
2988         Unreviewed, roll out r204901, r204897, r204866, r204856, r204854.
2989
2990         * bmalloc/Allocator.cpp:
2991         (bmalloc::Allocator::allocate):
2992         (bmalloc::Allocator::tryAllocate): Deleted.
2993         (bmalloc::Allocator::allocateImpl): Deleted.
2994         * bmalloc/Allocator.h:
2995         * bmalloc/Cache.h:
2996         (bmalloc::Cache::tryAllocate): Deleted.
2997         * bmalloc/bmalloc.h:
2998         (bmalloc::api::tryMemalign): Deleted.
2999
3000 2016-08-12  Filip Pizlo  <fpizlo@apple.com>
3001
3002         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
3003         https://bugs.webkit.org/show_bug.cgi?id=160125
3004
3005         Reviewed by Geoffrey Garen.
3006         
3007         I needed to tryMemalign, so I added such a thing.
3008
3009         * bmalloc/Allocator.cpp:
3010         (bmalloc::Allocator::allocate):
3011         (bmalloc::Allocator::tryAllocate):
3012         (bmalloc::Allocator::allocateImpl):
3013         (bmalloc::Allocator::reallocate):
3014         * bmalloc/Allocator.h:
3015         * bmalloc/Cache.h:
3016         (bmalloc::Cache::allocate):
3017         (bmalloc::Cache::tryAllocate):
3018         * bmalloc/bmalloc.h:
3019         (bmalloc::api::malloc):
3020         (bmalloc::api::tryMemalign):
3021         (bmalloc::api::memalign):
3022
3023 2016-08-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3024
3025         Unreviewed, build fix on GCC environment
3026         https://bugs.webkit.org/show_bug.cgi?id=161058
3027
3028         std::forward is declared in <utility> header.
3029
3030         * bmalloc/ScopeExit.h:
3031
3032 2016-08-22  Geoffrey Garen  <ggaren@apple.com>
3033
3034         bmalloc: speed up the lock slow path
3035         https://bugs.webkit.org/show_bug.cgi?id=161058
3036
3037         Reviewed by Filip Pizlo.
3038
3039         It is generally accepted practice that a lock should yield instead of
3040         spinning when a lock acquisition fails, to avoid wasting CPU and power.
3041
3042         There are two problems with this generally accepted practice:
3043
3044         (1) It's a fallacy that yielding is free. In reality, yielding itself
3045         consumes CPU and power -- by performing a syscall, running the OS
3046         scheduler, and possibly performing a context switch. (Instruments
3047         traces of MallocBench show the cost of yielding.) Therefore, spinning a
3048         little to avoid yielding can actually *save* CPU and power.
3049
3050         (2) std::this_thread_yield() on Darwin is way too aggressive: It not only
3051         yields but also depresses your priority to absolute zero for 10ms. A
3052         recent PLT trace showed a few spots where the main thread just gave up
3053         on loading and rendering a page for 10ms so an unimportant background
3054         task could run.
3055
3056         To correct these problems, this patch adds a little bit of spinning to
3057         the bmalloc lock slow path.
3058
3059         Below are performance results on various CPUs.
3060
3061         Mac Pro (12 hyperthreaded cores = 24 threads):
3062
3063                                                             Baseline                       Patch                           Δ
3064             Execution Time:
3065                 message_one                                    173ms                       173ms                            
3066                 message_many                                   953ms                       927ms              ^ 1.03x faster
3067                 churn --parallel                                60ms                        41ms              ^ 1.46x faster
3068                 list_allocate --parallel                       224ms                       143ms              ^ 1.57x faster
3069                 tree_allocate --parallel                     1,190ms                       758ms              ^ 1.57x faster
3070                 tree_churn --parallel                        1,517ms                       906ms              ^ 1.67x faster
3071                 facebook --parallel                          6,519ms                     4,580ms              ^ 1.42x faster
3072                 reddit --parallel                            5,097ms                     3,411ms              ^ 1.49x faster
3073                 flickr --parallel                            4,903ms                     3,501ms               ^ 1.4x faster
3074                 theverge --parallel                          6,641ms                     4,505ms              ^ 1.47x faster
3075
3076                 <geometric mean>                             1,158ms                       832ms              ^ 1.39x faster
3077                 <arithmetic mean>                            2,728ms                     1,895ms              ^ 1.44x faster
3078                 <harmonic mean>                                332ms                       240ms              ^ 1.38x faster
3079
3080         MacBook Air (2 hyperthreaded cores = 4 threads):
3081
3082                                                             Baseline                       Patch                           Δ
3083             Execution Time:
3084                 message_one                                    911ms                       907ms               ^ 1.0x faster
3085                 message_many                                   515ms                       513ms               ^ 1.0x faster
3086                 churn --parallel                               132ms                       134ms              ! 1.02x slower
3087                 list_allocate --parallel                       104ms                       102ms              ^ 1.02x faster
3088                 tree_allocate --parallel                       117ms                       111ms              ^ 1.05x faster
3089                 tree_churn --parallel                          154ms                       151ms              ^ 1.02x faster
3090                 facebook --parallel                            719ms                       687ms              ^ 1.05x faster
3091                 reddit --parallel                              382ms                       341ms              ^ 1.12x faster
3092                 flickr --parallel                              372ms                       345ms              ^ 1.08x faster
3093                 theverge --parallel                            489ms                       444ms               ^ 1.1x faster
3094
3095                 <geometric mean>                               299ms                       287ms              ^ 1.04x faster
3096                 <arithmetic mean>                              390ms                       374ms              ^ 1.04x faster
3097                 <harmonic mean>                                227ms                       220ms              ^ 1.03x faster
3098
3099         iPad (2 cores = 2 threads):
3100
3101             [ Doesn't run Ruby, so no pretty subtest output. ]
3102
3103                                                             Baseline                       Patch                           Δ
3104             Execution Time:                                 174.14ms                     171.5ms              ^ 1.02x faster
3105
3106         * bmalloc.xcodeproj/project.pbxproj:
3107
3108         * bmalloc/ScopeExit.h: Added. A barebones very wimpy version of
3109         WTF::ScopeExit.
3110         (bmalloc::ScopeExit::ScopeExit):
3111         (bmalloc::ScopeExit::~ScopeExit):
3112         (bmalloc::makeScopeExit):
3113
3114         * bmalloc/StaticMutex.cpp:
3115         (bmalloc::StaticMutex::lockSlowCase): Spin before yielding -- that's the
3116         speedup. Don't spin if another CPU is already spinning. In theory, more
3117         than one spinner accomplishes nothing, and I found that there's a cutoff
3118         around 8 or 16 spinners that becomes performance negative on Mac Pro.
3119
3120         (Note: Another way to accomplish a similar result, if you don't want to
3121         use a bit of state in the lock, is to spin for a random duration between
3122         0 and aLot. I tested a version of WTF::WeakRandom with unsynchronized
3123         static state and it worked great. But I ultimately opted for the explicit
3124         bit because I thought it was clearer.)
3125
3126         * bmalloc/StaticMutex.h:
3127         (bmalloc::StaticMutex::init): Initialize our new bit.
3128
3129         * bmalloc/ThreadSwitch.h: Added.
3130         (bmalloc::threadSwitch): Don't call yield() on Darwin because it's too
3131         aggressive. swtch() does what we want: Go run something else, without
3132         any other side-effects.
3133
3134 2016-08-03  Geoffrey Garen  <ggaren@apple.com>
3135
3136         [bmalloc] Merging of XLargeRanges can leak the upper range
3137         https://bugs.webkit.org/show_bug.cgi?id=160403
3138
3139         Reviewed by Michael Saboff.
3140
3141         * bmalloc/Heap.cpp:
3142         (bmalloc::Heap::scavengeLargeObjects): Don't use removePhysical().
3143         Recorded physical size is a performance optimization. It is not the
3144         truth. So it might be zero even if a range contains physical pages.
3145
3146         Instead, iterate each range in the map unconditionally.
3147
3148         The map can shrink when we release the lock, so we must clamp our
3149         iterator each time through the loop.
3150
3151         The map can grow when we release the lock, but we don't care because
3152         growth restarts the scavenger from the beginning.
3153
3154         * bmalloc/XLargeMap.cpp:
3155         (bmalloc::XLargeMap::removePhysical): Deleted. Not used anymore.
3156
3157         * bmalloc/XLargeMap.h:
3158         (bmalloc::XLargeMap::ranges): Added direct access for the sake of
3159         scavengeLargeObjects. (This violates our naming conventions -- I'll do
3160         a rename in a follow-up patch.)
3161
3162 2016-07-13  Enrica Casucci  <enrica@apple.com>
3163
3164         Update supported platforms in xcconfig files to match the sdk names.
3165         https://bugs.webkit.org/show_bug.cgi?id=159728
3166
3167         Reviewed by Tim Horton.
3168
3169         * Configurations/Base.xcconfig:
3170
3171 2016-07-11  Geoffrey Garen  <ggaren@apple.com>
3172
3173         Crash due to abort() calling libc++.1.dylib: std::__1::thread::detach()
3174         https://bugs.webkit.org/show_bug.cgi?id=159655
3175
3176         Reviewed by Sam Weinig.
3177
3178         It's not entirely clear what was happening in these crashes, but our
3179         use of detach() was 100% forward-looking, so we can just remove it for
3180         now.
3181
3182         This patch removes the ability for the scavenger owner to die before
3183         the scavenger thread dies (which was unused) and also removes the
3184         ability for the scavenger thread to exit (which was used, but we
3185         messed up and did thread joining lazily, so we never got any benefit
3186         from thread exit.)
3187
3188         We can add these features back when we need them, and make them work then.
3189
3190         * bmalloc/AsyncTask.h:
3191         (bmalloc::Function>::AsyncTask): We start out in the running state now
3192         because we know that starting our thread will run it.
3193
3194         (bmalloc::Function>::~AsyncTask): We don't support destruction anymore.
3195
3196         (bmalloc::Function>::runSlowCase): I removed the Exited state.
3197
3198         (bmalloc::Function>::threadRunLoop): I removed the Exited and
3199         ExitRequested states.
3200
3201         * bmalloc/Heap.h:
3202
3203         * bmalloc/VMHeap.h:
3204
3205 2016-06-12  David Kilzer  <ddkilzer@apple.com>
3206
3207         Crash in com.apple.WebKit.WebContent at std::__1::__call_once_proxy<std::__1::tuple<CrashReporterSupportLibrary()::$_0&&> >
3208         <https://webkit.org/b/158660>
3209         <rdar://problem/25652686>
3210
3211         Reviewed by Darin Adler.
3212
3213         * bmalloc/Logging.cpp: Switch to use
3214         BSOFT_LINK_PRIVATE_FRAMEWORK() to link
3215         CrashReporterSupport.framework.
3216         * bmalloc/darwin/BSoftLinking.h:
3217         (BSOFT_LINK_PRIVATE_FRAMEWORK): Rename from BSOFT_LINK_FRAMEWORK.
3218         Switch to use /System/Library/PrivateFrameworks/.
3219
3220 2016-06-11  David Kilzer  <ddkilzer@apple.com>
3221
3222         Implement logging for RELEASE_BASSERT_WITH_MESSAGE() in BAssert.h
3223         <http://webkit.org/b/155992>
3224
3225         Reviewed by Geoff Garen.
3226
3227         * bmalloc/BAssert.h:
3228         (BLOG_ERROR): Add method to always log error messages.
3229         (RELEASE_BASSERT_WITH_MESSAGE): Use BLOG_ERROR() to implement
3230         logging in Debug builds.
3231         * bmalloc/BPlatform.h:
3232         (BPLATFORM_MAC): Add.
3233         (BUSE): Add BUSE() macro.
3234         (BATTRIBUTE_PRINTF): Add.
3235         (BUSE_OS_LOG): Add.
3236         * bmalloc/Logging.cpp:
3237         (bmalloc::reportAssertionFailureWithMessage): Add.  Logs to
3238         stderr.
3239         * bmalloc/Logging.h:
3240         (bmalloc::reportAssertionFailureWithMessage): Add declaration.
3241
3242 2016-06-07  Pranjal Jumde  <pjumde@apple.com>
3243
3244         Prevents integer overflow in Vector.h
3245         https://bugs.webkit.org/show_bug.cgi?id=158455
3246         <rdar://problem/20235469>
3247
3248         Reviewed by Mark Lam.
3249
3250         * bmalloc/Vector.h:
3251         (bmalloc::Vector<T>::reallocateBuffer):
3252
3253 2016-05-27  Konstantin Tokarev  <annulen@yandex.ru>
3254
3255         [cmake] Deduplicated bmalloc/Zone.cpp handling.
3256         https://bugs.webkit.org/show_bug.cgi?id=158154
3257
3258         Reviewed by Alex Christensen.
3259
3260         File bmalloc/Zone.cpp is required on Darwin irrespectively from what
3261         port is being built.
3262
3263         Also I removed WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS() because it's
3264         unlikely that bmalloc will ever need port-specific customizations (as
3265         opposed to OS-specific customizations which should be done in
3266         CMakeLists.txt).
3267
3268         * CMakeLists.txt: Added bmalloc/Zone.cpp for Darwin.
3269         * PlatformGTK.cmake: Removed.
3270         * PlatformMac.cmake: Removed.
3271
3272 2016-05-22  Brady Eidson  <beidson@apple.com>
3273
3274         Move to C++14.
3275         https://bugs.webkit.org/show_bug.cgi?id=157948
3276
3277         Reviewed by Michael Catanzaro.
3278
3279         * Configurations/Base.xcconfig:
3280
3281 2016-05-17  Geoffrey Garen  <ggaren@apple.com>
3282
3283         REGRESSION: JetStream crashes on some iPhones
3284         https://bugs.webkit.org/show_bug.cgi?id=157814
3285
3286         Reviewed by Michael Saboff.
3287
3288         * bmalloc/Sizes.h: Reduce smallMax to 32kB. 
3289
3290         Previous justification for 64kB was:
3291
3292             * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
3293             reasonable, since sizes between 16kB and 32kB share page sizes. I went
3294             all the way up to 64kB because the GC uses 64kB blocks, and also just
3295             for extra padding to ensure that large allocations are indeed rare.
3296
3297         It turns out that the bump to 64kB substantially increases our memory
3298         high water mark on JetStream, leading to jetsam crashes. Also, there
3299         doesn't seem to be a practical performance problem to putting objects in
3300         the (32kB - 64kB) range in the large allocator.
3301
3302 2016-05-16  Geoffrey Garen  <ggaren@apple.com>
3303
3304         REGRESSION (200035): changes in "WebKit Malloc" VM regions are causing 'leaks' to spew "Failed to map remote region" messages
3305         https://bugs.webkit.org/show_bug.cgi?id=157764
3306
3307         Reviewed by Gavin Barraclough.
3308
3309         We need to allow for guard pages and only report unguarded pages to the
3310         leaks tool -- otherwise, it will try to remote map our guarded pages,
3311         and crash.
3312
3313         * bmalloc/VMHeap.cpp:
3314         (bmalloc::VMHeap::tryAllocateLargeChunk):
3315         (bmalloc::VMHeap::allocateSmallChunk): Adopt the new API for reporting
3316         a range instead of a Chunk*, and report the unguarded range.
3317
3318         This also fixes a separate bug -- very large allocations would not
3319         fully participate in pointer scanning because they would only report 2MB
3320         (chunkSize) in size. This could cause false-positive leak reports.
3321
3322         * bmalloc/Zone.cpp:
3323         (bmalloc::enumerator): Updated to scan ranges instead of fixed-sized
3324         Chunk pointers.
3325
3326         * bmalloc/Zone.h:
3327         (bmalloc::Zone::ranges):
3328         (bmalloc::Zone::addRange): Store ranges instead of fixed-sized Chunk 
3329         pointers because our VM ranges have variable sizes -- both due to guard
3330         pages and due to large allocations.
3331
3332         (bmalloc::Zone::chunks): Deleted.
3333         (bmalloc::Zone::addChunk): Deleted.
3334
3335 2016-05-10  David Kilzer  <ddkilzer@apple.com>
3336
3337         bmalloc should automatically disable itself when ThreadSanitizer is used
3338         <https://webkit.org/b/157527>
3339
3340         Reviewed by Michael Catanzaro.
3341
3342         * bmalloc/Environment.cpp:
3343         (bmalloc::isASanEnabled): Rename to isSanitizerEnabled.
3344         (bmalloc::isSanitizerEnabled): Rename from isASanEnabled. Add
3345         support for detecting ThreadSanitizer.
3346         (bmalloc::Environment::computeIsBmallocEnabled): Switch from
3347         isASanEnabled to isSanitizerEnabled.
3348
3349 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
3350
3351         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3352         https://bugs.webkit.org/show_bug.cgi?id=157047
3353
3354         Reviewed by Filip Pizlo.
3355
3356         Renamed roundUpToMultipleOfSloppy => roundUpToMultipleOfNonPowerOfTwo.
3357
3358         * bmalloc/Algorithm.h:
3359         (bmalloc::roundUpToMultipleOfNonPowerOfTwo):
3360         (bmalloc::roundUpToMultipleOfSloppy): Deleted.
3361         * bmalloc/VMHeap.cpp:
3362         (bmalloc::VMHeap::allocateSmallChunk):
3363
3364 2016-05-03  Geoffrey Garen  <ggaren@apple.com>
3365
3366         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3367         https://bugs.webkit.org/show_bug.cgi?id=157047
3368
3369         Reviewed by Filip Pizlo.
3370
3371         The previous fix aligned the guard page sizes correctly but forgot to
3372         align the guard page start address correctly.
3373
3374         * bmalloc/Algorithm.h:
3375         (bmalloc::roundUpToMultipleOfSloppy): Use a new helper method to round
3376         up when not working with a power of two, instead of writing out the
3377         math by hand.
3378
3379         * bmalloc/VMHeap.cpp:
3380         (bmalloc::VMHeap::allocateSmallChunk): Make sure to round up the guard
3381         page start address in addition to its size. Assert at the very end to
3382         try to catch more bugs.
3383
3384 2016-04-27  Geoffrey Garen  <ggaren@apple.com>
3385
3386         Assertion failure in bmalloc::vmRevokePermissions(void*, unsigned long).
3387         https://bugs.webkit.org/show_bug.cgi?id=157047
3388
3389         Reviewed by Darin Adler.
3390
3391         * bmalloc/Chunk.h:
3392         (bmalloc::Chunk::Chunk):
3393         (bmalloc::Chunk::get):
3394         (bmalloc::Chunk::offset):
3395         (bmalloc::Chunk::address):
3396         (bmalloc::Object::Object):
3397         (bmalloc::Object::address):
3398         (bmalloc::Object::line):
3399         (bmalloc::Chunk::object): Deleted.
3400         (bmalloc::Object::begin): Deleted.
3401         * bmalloc/Heap.cpp:
3402         (bmalloc::Heap::allocateSmallBumpRangesByObject):
3403         * bmalloc/Object.h:
3404         (bmalloc::Object::chunk):
3405         (bmalloc::Object::offset): Renamed begin() to address() because this is
3406         not an iterator.
3407
3408         * bmalloc/VMHeap.cpp:
3409         (bmalloc::VMHeap::allocateSmallChunk): Round up pageSize to a vmPageSize
3410         multiple because pageSize might be smaller than vmPageSize, but we
3411         think the VM system requires vmPageSize-aligned values.
3412
3413 2016-04-25  Geoffrey Garen  <ggaren@apple.com>
3414
3415         bmalloc: vm allocations should plant guard pages
3416         https://bugs.webkit.org/show_bug.cgi?id=156937
3417
3418         Rolling back in r199936 with a fix for the memory regression.
3419
3420 2016-04-23  Gavin Barraclough  <barraclough@apple.com>
3421
3422         bmalloc: vm allocations should plant guard pages
3423         https://bugs.webkit.org/show_bug.cgi?id=156937
3424
3425         Rolling out - looks like this is memory regression.
3426
3427         * bmalloc/Object.h:
3428         (bmalloc::Object::operator+):
3429         (bmalloc::Object::operator<=):
3430         (bmalloc::Object::operator-): Deleted.
3431         * bmalloc/VMAllocate.h:
3432         (bmalloc::vmDeallocate):
3433         (bmalloc::vmRevokePermissions): Deleted.
3434         * bmalloc/VMHeap.cpp:
3435         (bmalloc::VMHeap::allocateSmallChunk):
3436
3437 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
3438
3439         bmalloc: vm allocations should plant guard pages
3440         https://bugs.webkit.org/show_bug.cgi?id=156937
3441
3442         Reviewed by Michael Saboff.
3443
3444         * bmalloc/Object.h:
3445         (bmalloc::Object::operator-): Added a - helper.
3446
3447         * bmalloc/VMAllocate.h:
3448         (bmalloc::vmRevokePermissions): Added a helper to revoke permissions on
3449         a VM region. We use this for guard pages.
3450
3451         * bmalloc/VMHeap.cpp:
3452         (bmalloc::VMHeap::allocateSmallChunk): Add guard pages to the start and
3453         end of the chunk.
3454
3455         Note that we don't guard large chunks becuase we need to be able to merge
3456         them. Otherwise, we will run out of virtual addresses.
3457
3458 2016-04-22  Geoffrey Garen  <ggaren@apple.com>
3459
3460         bmalloc: Constify introspect function pointer table
3461         https://bugs.webkit.org/show_bug.cgi?id=156936
3462
3463         Reviewed by Michael Saboff.
3464
3465         * bmalloc/Zone.cpp:
3466         (bmalloc::Zone::Zone): Declaring this function pointer table const puts
3467         it in the read-only section of the binary, providing a little hardening
3468         against overwriting the function pointers at runtime. (We have to
3469         const_cast when assigning because the API declares a pointer to non-const,
3470         but we happen to know it will never try to write through that pointer.
3471         This is not my favorite API.)
3472
3473 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3474
3475         bmalloc: fix up overflow checks
3476         https://bugs.webkit.org/show_bug.cgi?id=156780
3477
3478         Reviewed by Mark Lam.
3479
3480         We used to try to avoid overflow in large object math by setting a very
3481         high limit on the largest large object. But that's a bit error-prone
3482         since the check is far away from the math that might overflow -- and
3483         we were missing some cases.
3484
3485         This patch removes the limit and instead checks at each math site.
3486
3487         * bmalloc/Allocator.cpp:
3488         (bmalloc::Allocator::tryAllocate):
3489         (bmalloc::Allocator::allocate):
3490         (bmalloc::Allocator::reallocate):
3491         (bmalloc::Allocator::allocateSlowCase): Remove the limit. tryAllocateLarge
3492         will check for overflow for us.
3493
3494         * bmalloc/Chunk.h: This ASSERT was just totally wrong.
3495
3496         * bmalloc/Heap.cpp:
3497         (bmalloc::Heap::tryAllocateLarge): Check for overflow when adding.
3498
3499         * bmalloc/Sizes.h:
3500
3501         * bmalloc/VMAllocate.h:
3502         (bmalloc::tryVMAllocate): Check for overflow when adding.
3503
3504         * bmalloc/VMHeap.cpp:
3505         (bmalloc::VMHeap::tryAllocateLargeChunk): Check for overflow when adding.
3506
3507 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3508
3509         Unreviewed, try to fix an ASSERT seen on the bots.
3510
3511         * bmalloc/Heap.cpp:
3512         (bmalloc::Heap::tryAllocateLarge): This ASSERT is supposed to be about
3513         alignment, not size. Oops.
3514
3515 2016-04-19  Geoffrey Garen  <ggaren@apple.com>
3516
3517         bmalloc: Merge the large and xlarge allocators
3518         https://bugs.webkit.org/show_bug.cgi?id=156734
3519
3520         Reviewed by Andreas Kling.
3521
3522         This give us better defense against worst case memory usage:
3523
3524                                               Baseline                Patch                    Δ
3525             Peak Memory:
3526                 nimlang                      198,132kB            181,468kB      ^ 1.09x smaller
3527
3528         It also eliminates inline metadata for large objects, fixing the
3529         regression introduced in r198675, and more:
3530
3531             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3532
3533                                                                   Baseline                          Patch                              Δ
3534             Memory at End:
3535                 big                                               10,880kB                        3,328kB                ^ 3.27x smaller
3536                 facebook                                           3,112kB                        2,868kB                ^ 1.09x smaller
3537                 fragment --parallel                                1,848kB                          760kB                ^ 2.43x smaller
3538                 fragment_iterate --parallel                        4,908kB                          776kB                ^ 6.32x smaller
3539                 big --parallel                                    48,076kB                       11,892kB                ^ 4.04x smaller
3540
3541         Overall memory use looks OK:
3542
3543             run-malloc-benchmarks --memory_warning Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3544
3545                                                         Baseline                               Patch                                   Δ
3546             Memory at End:
3547                 <arithmetic mean>                       13,992kB                            13,987kB                      ^ 1.0x smaller
3548
3549         Overall throughput looks OK:
3550
3551             run-malloc-benchmarks Baseline:~/OpenSource/WebKitBuildBaseline/Release/ Patch:~/OpenSource/WebKitBuild/Release/
3552
3553                                                                   Baseline                          Patch                              Δ
3554             Execution Time:
3555                 <arithmetic mean>                                    103ms                          104ms                 ! 1.01x slower
3556
3557         We're a bit slower on the "all-out large allocations on all cores"
3558         benchmark, but I think that's an OK price to pay:
3559
3560                                                                   Baseline                          Patch                              Δ
3561             Execution Time:
3562                 big --parallel                                       125ms                          136ms                 ! 1.09x slower
3563
3564         This patch net removes 1.5k lines of code. It turns out that large
3565         allocations are rare, and free memory fragments are also rare, so the
3566         combination is super rare, and a simple O(n) algorithm that ensures good
3567         memory behavior is the best option.
3568
3569         Fun fact: In practice, the odds that the old code would save memory
3570         were *worse* than the odds that it would contain a bug that wasted
3571         memory. :)
3572
3573         * bmalloc.xcodeproj/project.pbxproj:
3574
3575         * bmalloc/Allocator.cpp:
3576         (bmalloc::Allocator::tryAllocate): largeMax is the new xLargeMax since
3577         xLargeMax is gone now.
3578
3579         (bmalloc::Allocator::allocate): I moved the rounding code into allocateLarge,
3580         so we don't have to do it here.
3581
3582         (bmalloc::Allocator::reallocate):
3583         (bmalloc::Allocator::allocateSlowCase):
3584         (bmalloc::Allocator::allocateXLarge): Deleted. No more XLarge case.
3585
3586         * bmalloc/Allocator.h:
3587
3588         * bmalloc/BeginTag.h: Removed.
3589         * bmalloc/BoundaryTag.h: Removed.
3590
3591         * bmalloc/Chunk.h:
3592         (bmalloc::ChunkHash::hash): Added a hash function. The best hash function
3593         is a unique and monotonically increasing integer, and that's exactly what
3594         we typically get from the high bits of a Chunk, since the OS allocates
3595         Chunks at unique and increasing addresses.
3596         (bmalloc::Chunk::boundaryTags): Deleted.
3597         (bmalloc::Chunk::objectType): Deleted.
3598         (bmalloc::Chunk::beginTag): Deleted.
3599         (bmalloc::Chunk::endTag): Deleted.
3600
3601         * bmalloc/Deallocator.cpp:
3602         (bmalloc::Deallocator::deallocateSlowCase): We no longer know for sure,
3603         by looking at its bit pattern, whether a pointer is small or large.
3604         Instead, any pointer with large alignment *might* be large, and when
3605         we occasionally encounter such an object, we have to consult a hash
3606         table in the Heap to find out for sure. This turns out to be just as
3607         cheap in practice.
3608
3609         We don't deallocate large objects on the fast path anymore. We can't,
3610         because large objects have out-of-line metadata now.
3611
3612         (bmalloc::Deallocator::deallocateXLarge): Deleted.
3613
3614         * bmalloc/Deallocator.h:
3615         (bmalloc::Deallocator::deallocateFastCase): See deallocateSlowCase.
3616
3617         * bmalloc/EndTag.h: Removed.
3618         * bmalloc/FreeList.cpp: Removed.
3619         * bmalloc/FreeList.h: Removed.
3620
3621         * bmalloc/Heap.cpp:
3622         (bmalloc::Heap::allocateSmallPage): Be sure to track each chunk in
3623         the object type map, so we can distinguish small vs large objects.
3624
3625         (bmalloc::Heap::deallocateSmallLine): No need to check object type
3626         because we know object type now by virtue of being on the small object
3627         path.
3628
3629         (bmalloc::Heap::splitAndAllocate): Be sure to track each chunk in
3630         the object type map, so we can distinguish small vs large objects. Large
3631         objects can split across chunks, so we need to add each large object's
3632         chunk as it is allocated.
3633
3634         (bmalloc::Heap::tryAllocateLarge):
3635         (bmalloc::Heap::allocateLarge):
3636         (bmalloc::Heap::isLarge):
3637         (bmalloc::Heap::largeSize):
3638         (bmalloc::Heap::shrinkLarge):
3639         (bmalloc::Heap::deallocateLarge): Merged in existing XLarge logic for
3640         large objects.
3641
3642         (bmalloc::Heap::scavengeXLargeObjects): Deleted.
3643         (bmalloc::Heap::allocateXLarge): Deleted.
3644         (bmalloc::Heap::tryAllocateXLarge): Deleted.
3645         (bmalloc::Heap::xLargeSize): Deleted.
3646         (bmalloc::Heap::shrinkXLarge): Deleted.
3647         (bmalloc::Heap::deallocateXLarge): Deleted.
3648
3649         * bmalloc/Heap.h:
3650         (bmalloc::Heap::LargeObjectHash::hash):
3651
3652         * bmalloc/LargeObject.h: Removed.
3653
3654         * bmalloc/Map.h: Added.
3655         (bmalloc::Map::size):
3656         (bmalloc::Map::capacity):
3657         (bmalloc::Map::get):
3658         (bmalloc::Map::set):
3659         (bmalloc::Map::remove):
3660         (bmalloc::Map::shouldGrow):
3661         (bmalloc::Map::shouldShrink):
3662         (bmalloc::Map::find):
3663         (bmalloc::Hash>::rehash): Simple hash table.
3664
3665         * bmalloc/Object.h:
3666
3667         * bmalloc/ObjectType.cpp:
3668         (bmalloc::objectType):
3669         * bmalloc/ObjectType.h:
3670         (bmalloc::mightBeLarge): See deallocateSlowCase.
3671         (bmalloc::isXLarge): Deleted.
3672
3673         * bmalloc/SegregatedFreeList.cpp: Removed.
3674         * bmalloc/SegregatedFreeList.h: Removed.
3675
3676         * bmalloc/Sizes.h: Upped smallMax to 64kB. Upping to 32kB is pretty
3677         reasonable, since sizes between 16kB and 32kB share page sizes. I went
3678         all the way up to 64kB because the GC uses 64kB blocks, and also just
3679         for extra padding to ensure that large allocations are indeed rare.
3680
3681         * bmalloc/SortedVector.h: Removed.
3682
3683         * bmalloc/VMHeap.cpp:
3684         (bmalloc::VMHeap::tryAllocateLargeChunk):
3685         (bmalloc::VMHeap::allocateSmallChunk):
3686         (bmalloc::VMHeap::VMHeap): Deleted.
3687         (bmalloc::VMHeap::allocateChunk): Deleted.
3688         * bmalloc/VMHeap.h:
3689         (bmalloc::VMHeap::deallocateSmallPage):
3690         (bmalloc::VMHeap::allocateLargeObject): Deleted.
3691         (bmalloc::VMHeap::deallocateLargeObject): Deleted. Nixed all the boundary
3692         tag logic since metadata is out of line now.
3693
3694         * bmalloc/VMState.h: Removed. Instead of an abstract state, we track
3695         the precise amount of committed physical pages at the head of a VM
3696         range. This allows us to merge aggressively without triggering an madvise
3697         storm most of the time.
3698
3699         * bmalloc/Vector.h:
3700         (bmalloc::Vector<T>::Vector):
3701         (bmalloc::Vector<T>::insert):
3702         (bmalloc::Vector<T>::remove):
3703         (bmalloc::Vector<T>::resize): Filled out some missing helpers.
3704
3705         * bmalloc/XLargeMap.cpp:
3706         (bmalloc::XLargeMap::remove):
3707         (bmalloc::XLargeMap::add):
3708         (bmalloc::XLargeMap::removePhysical):
3709         (bmalloc::XLargeMap::takeFree): Deleted.
3710         (bmalloc::XLargeMap::addFree): Deleted.
3711         (bmalloc::XLargeMap::addAllocated): Deleted.
3712         (bmalloc::XLargeMap::getAllocated): Deleted.
3713         (bmalloc::XLargeMap::takeAllocated): Deleted.
3714         (bmalloc::XLargeMap::shrinkToFit): Deleted.
3715         (bmalloc::XLargeMap::takePhysical): Deleted.
3716         (bmalloc::XLargeMap::addVirtual): Deleted.
3717         * bmalloc/XLargeMap.h:
3718         (bmalloc::XLargeMap::Allocation::operator<): Deleted. We don't track
3719         object sizes anymore -- just free space. (The Heap tracks object sizes.)
3720         We use plain old linear search for free space. (See intro.)
3721
3722         * bmalloc/XLargeRange.h:
3723         (bmalloc::XLargeRange::physicalSize):
3724         (bmalloc::XLargeRange::setPhysicalSize):
3725         (bmalloc::merge):
3726         (bmalloc::XLargeRange::split):
3727         (bmalloc::XLargeRange::vmState): Deleted.
3728         (bmalloc::XLargeRange::setVMState): Deleted. See VMState.h.
3729
3730 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
3731
3732         [CMake] Make FOLDER property INHERITED
3733         https://bugs.webkit.org/show_bug.cgi?id=156460
3734
3735         Reviewed by Brent Fulgham.
3736
3737         * CMakeLists.txt:
3738         Set FOLDER property as a directory property not a target property
3739
3740 2016-04-08  Geoffrey Garen  <ggaren@apple.com>
3741
3742         bmalloc: stress_aligned test fails if you increase smallMax
3743         https://bugs.webkit.org/show_bug.cgi?id=156414
3744
3745         Reviewed by Oliver Hunt.
3746
3747         When size exceeds alignment and is a multiple of alignment and is not
3748         a power of two, such as 24kB with 8kB alignment, the small allocator
3749         did not always guarantee alignment. Let's fix that.
3750
3751         * bmalloc/Algorithm.h:
3752         (bmalloc::divideRoundingUp): Math is hard.
3753
3754         * bmalloc/Allocator.cpp:
3755         (bmalloc::Allocator::allocate): Align to the page size unconditionally.
3756         Even if the page size is not a power of two, it might be a multiple of
3757         a power of two, and we want alignment to that smaller power of two to
3758         be guaranteed.
3759
3760 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
3761
3762         bmalloc: handle aligned allocations on the fast path
3763         https://bugs.webkit.org/show_bug.cgi?id=156302
3764
3765         Reviewed by Michael Saboff.
3766
3767         This helps keep the JavaScriptCore GC on the fast path, and it also
3768         helps avoid fragmentation on our website stress test:
3769
3770             nimlang                      209,584kB            198,076kB      ^ 1.06x smaller
3771
3772         * bmalloc/Allocator.cpp:
3773         (bmalloc::Allocator::allocate): Because we arrange for power-of-two size
3774         classes to allocate at power-of-two alignments, we can allocate any
3775         small aligned request on the small path.
3776
3777         * bmalloc/Chunk.h:
3778         (bmalloc::Chunk::bytes):
3779         (bmalloc::Chunk::lines):
3780         (bmalloc::Chunk::pages):
3781         (bmalloc::Chunk::boundaryTags):
3782         (bmalloc::Chunk::objectType): Moved some code around to provide better
3783         API.
3784
3785         (bmalloc::Chunk::Chunk): Moved this code to VMHeap.
3786
3787         (bmalloc::Chunk::offset):
3788         (bmalloc::Chunk::object): Use our new bytes() helper function.
3789
3790         * bmalloc/VMHeap.cpp:
3791         (bmalloc::VMHeap::allocateChunk): Moved code here from Chunk.
3792
3793         (bmalloc::VMHeap::allocateSmallChunk): Ensure that power-of-two page
3794         sizes always begin allocation at the same alignment. Power-of-two object
3795         sizes always request power-of-two page sizes (since that's the least
3796         wasteful option), so if we also ensure that power-of-two page sizes get
3797         power-of-two alignment, then everything is aligned for all small objects.
3798
3799 2016-04-03  Geoffrey Garen  <ggaren@apple.com>
3800
3801         bmalloc: segregate small and large objects again, and allocate more objects on the small path
3802         https://bugs.webkit.org/show_bug.cgi?id=156152
3803
3804         Reviewed by Sam Weinig.
3805
3806         Microbenchmark data suggested that it was a good idea for small and large
3807         objects to share memory. But r198675 did not improve memory use in
3808         full browser benchmarks.
3809
3810         This patch reverts to segregating small and large objects -- but without
3811         going back to doubled VM usage -- in order to capture a few benefits:
3812
3813         (*) Small pages fragment the large heap. Separating them out saves a lot
3814         of memory in our worst case fragmentation recording:
3815
3816             nimlang                                          276,076kB                      209,636kB                ^ 1.32x smaller
3817
3818         (*) Small objects are common enough that even their slow paths benefit 
3819         from simpler code:
3820
3821         Execution Time:
3822             ...
3823             facebook                                             234ms                          216ms                 ^ 1.08x faster
3824             reddit                                               114ms                          108ms                 ^ 1.06x faster
3825             flickr                                               118ms                          111ms                 ^ 1.06x faster
3826             theverge                                             146ms                          140ms                 ^ 1.04x faster
3827             ...
3828             <arithmetic mean>                                    107ms                          102ms                 ^ 1.04x faster
3829
3830         (*) We can use less metadata:
3831
3832         Memory at End:
3833             ...
3834             list_allocate                                        460kB                          384kB                 ^ 1.2x smaller
3835             tree_allocate                                        492kB                          424kB                ^ 1.16x smaller
3836             tree_churn                                           480kB                          404kB                ^ 1.19x smaller
3837             fragment                                             532kB                          452kB                ^ 1.18x smaller
3838             fragment_iterate                                     712kB                          588kB                ^ 1.21x smaller
3839             medium                                            15,152kB                       11,796kB                ^ 1.28x smaller
3840             big                                               15,044kB                       10,976kB                ^ 1.37x smaller
3841             ...
3842             <arithmetic mean>                                  7,724kB                        7,190kB                ^ 1.07x smaller
3843
3844         This patch also takes advantage of our support for varying the page size
3845         at runtime by allocating more objects on the small object path:
3846
3847             medium                                               178ms                          150ms                 ^ 1.19x faster
3848
3849         Some microbenchmarks report memory use increases from this change -- like
3850         they reported memory use decreases from r198675 -- but I'm ignoring them
3851         for now because I expect our full browser memory benchmarks to confirm
3852         that this patch is fine.
3853
3854         * bmalloc/BumpAllocator.h:
3855         (bmalloc::BumpAllocator::BumpAllocator): Use a full unsigned because we
3856         can allocate objects larger than 16kB - 1, and a full unsigned does not
3857         make BumpAllocator any larger on 64bit systems.
3858
3859         * bmalloc/Chunk.h:
3860         (bmalloc::Chunk::begin):
3861         (bmalloc::Chunk::end):
3862         (bmalloc::Chunk::size):
3863         (bmalloc::Chunk::objectType): Store ObjectType in the Chunk, since it only
3864         varies by Chunk now, and not from page to page within a Chunk. Also,
3865         union together small and large object metadata, since we will only use
3866         one or the other. This saves memory.
3867
3868         (bmalloc::Chunk::Chunk): Conditionalize initialization based on object
3869         type, since only one kind of metadata or the other can be used at runtime.
3870
3871         (bmalloc::Object::Object):
3872         (bmalloc::Object::begin):
3873         (bmalloc::SmallPage::end): Deleted.
3874
3875         * bmalloc/Heap.cpp:
3876         (bmalloc::Heap::Heap):
3877         (bmalloc::Heap::initializeLineMetadata): Save a little space, since we
3878         know that lines are only 256 bytes long.
3879
3880         (bmalloc::Heap::initializePageMetadata): Store a dynamic page size for
3881         each size class. We used to use only one page size (the system page size)
3882         but that limited our ability to allocate objects larger than 1kB on the
3883         small object path. Now we can handle any object size we want by storing
3884         objects of that size in a custom page size.
3885
3886         (bmalloc::Heap::concurrentScavenge):
3887         (bmalloc::Heap::scavenge):
3888         (bmalloc::Heap::scavengeSmallPages): Revert to our old linked list
3889         strategy for storing small pages.
3890
3891         (bmalloc::Heap::splitAndAllocate): Object type is per Chunk now.
3892
3893         (bmalloc::Heap::allocateLarge): Don't nuke the small page list when
3894         allocating a large object because the two don't share memory anymore.
3895
3896         (bmalloc::Heap::allocateSmallPage): Revert to our old linked list
3897         strategy for storing small pages.
3898
3899         (bmalloc::Heap::deallocateSmallLine): Don't return early in the case
3900         where this is the first free object in the page. In the case of large-ish
3901         objects, the first free object might also be the last free object,
3902         since there's one object per page.
3903
3904         (bmalloc::Heap::allocateSmallBumpRangesByMetadata): Split out some helper
3905         lambdas to make this code clearer.
3906
3907         (bmalloc::Heap::allocateSmallBumpRangesByObject): Added a fast scan
3908         for objects larger than the line size. When multiple objects fit in
3909         a single line, it's an optimization to scan a line at a time. But when
3910         it's one object per line, or one object per 64 lines, it's better just
3911         to scan an object at a time.
3912
3913         * bmalloc/Heap.h:
3914         (bmalloc::Heap::allocateSmallBumpRanges):
3915         (bmalloc::Heap::derefSmallLine): Match the changes above.
3916
3917         * bmalloc/LineMetadata.h: We weren't using all those bits.
3918
3919         * bmalloc/List.h:
3920         (bmalloc::List::remove): Put a removed Node fully back into the default
3921         (empty) state it was in before it entered the list. This change is not
3922         observable, but it makes things clearer when you're debugging.
3923
3924         * bmalloc/Object.h:
3925         (bmalloc::Object::Object):
3926         (bmalloc::Object::chunk):
3927         (bmalloc::Object::offset):
3928         (bmalloc::Object::operator+):
3929         (bmalloc::Object::operator<=): Added some helpers for iterating by object.
3930
3931         * bmalloc/ObjectType.cpp:
3932         (bmalloc::objectType): Updated for API change.
3933
3934         * bmalloc/Sizes.h:
3935         (bmalloc::Sizes::maskObjectSize):
3936         (bmalloc::Sizes::objectSize):
3937         (bmalloc::Sizes::pageSize): Support more page sizes.
3938
3939         * bmalloc/SmallPage.h:
3940         (bmalloc::SmallPage::SmallPage):
3941         (bmalloc::SmallPage::objectType): Deleted.
3942         (bmalloc::SmallPage::setObjectType): Deleted.
3943         (bmalloc::SmallPage::smallPageCount): Deleted.
3944         (bmalloc::SmallPage::setSmallPageCount): Deleted. Object type is per
3945         Chunk now, and we can infer page count from size class.
3946
3947         * bmalloc/VMHeap.cpp:
3948         (bmalloc::VMHeap::allocateChunk):
3949         (bmalloc::VMHeap::allocateSmallChunk):
3950         * bmalloc/VMHeap.h:
3951         (bmalloc::VMHeap::allocateSmallPage):
3952         (bmalloc::VMHeap::deallocateSmallPage):
3953         (bmalloc::VMHeap::allocateLargeObject): Support our old behavior of
3954         storing free pages in linked lists.
3955
3956 2016-03-29  Geoffrey Garen  <ggaren@apple.com>
3957
3958         bmalloc: support physical page sizes that don't match the virtual page size (take 2)
3959         https://bugs.webkit.org/show_bug.cgi?id=156003
3960
3961         Reviewed by Andreas Kling.
3962
3963         This is a memory savings on iOS devices where the virtual page size
3964         is 16kB but the physical page size is 4kB.
3965
3966         Take 1 was a memory regression on 16kB virtual / 16kB physical systems
3967         because it used a 4kB page size within a 16kB page size, allowing up to
3968         4 different object types to mix within a physical page. Because objects
3969         of the same type tend to deallocate at the same time, mixing objects of
3970         different types made pages less likely to become completely empty.
3971
3972         (Take 1 also had a bug where it used a platform #ifdef that didn't exist.
3973         Oops.)
3974
3975         Take 2 allocates units of SmallPages equal to the physical page size.
3976
3977         * bmalloc/Heap.cpp:
3978         (bmalloc::Heap::Heap):
3979         (bmalloc::Heap::initializeLineMetadata):
3980         (bmalloc::Heap::allocateSmallBumpRanges):
3981         (bmalloc::Heap::allocateSmallPage):