Source/bmalloc:
authorsbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 7 Apr 2018 00:00:34 +0000 (00:00 +0000)
committersbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 7 Apr 2018 00:00:34 +0000 (00:00 +0000)
commit66a8eed2fffe4958afa52ec385598948033f5c76
treeb3523049959e8f3450d6ca85bbc02fc29e3b4324
parent168073cb80b70408d44f1e2e9ea579cd70359378
Source/bmalloc:
bmalloc virtual allocation API should not treat memory it vends as dirty with respect to how it drives the scavenger
https://bugs.webkit.org/show_bug.cgi?id=184342

Reviewed by Mark Lam.

Currently, the only user of this API is Wasm. Ideally, Wasm would tell
us exactly which page is dirtied. We should really do that at some point:
https://bugs.webkit.org/show_bug.cgi?id=184207

However, until we do that, it's better to treat none of the virtual memory
we vend as dirty, versus what we do now, which is treat it all as dirty.
This dirty memory tracking helps drive the scavenger, so on iOS, having the
scavenger think its under memory pressure because of memory it can't free isn't
useful.

* bmalloc/bmalloc.cpp:
(bmalloc::api::tryLargeZeroedMemalignVirtual):
(bmalloc::api::freeLargeVirtual):
* bmalloc/bmalloc.h:

Source/WTF:
bmalloc's tryLargeZeroedMemalignVirtual shouldn't treat the entire virtual size as dirty towards its footprint
https://bugs.webkit.org/show_bug.cgi?id=184207

Reviewed by Mark Lam.

* wtf/Gigacage.cpp:
(Gigacage::freeVirtualPages):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@230360 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WTF/ChangeLog
Source/WTF/wtf/Gigacage.cpp
Source/bmalloc/ChangeLog
Source/bmalloc/bmalloc/bmalloc.cpp
Source/bmalloc/bmalloc/bmalloc.h