[Webkit-unassigned] [Bug 181425] New: bmalloc allocation should be able to round up to next power of two but not commit everything
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jan 8 22:20:23 PST 2018
https://bugs.webkit.org/show_bug.cgi?id=181425
Bug ID: 181425
Summary: bmalloc allocation should be able to round up to next
power of two but not commit everything
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: bmalloc
Assignee: webkit-unassigned at lists.webkit.org
Reporter: jfbastien at apple.com
CC: fpizlo at apple.com, ggaren at apple.com,
jfbastien at apple.com, keith_miller at apple.com,
mark.lam at apple.com, msaboff at apple.com,
rmorisset at apple.com, sbarati at apple.com
We're currently moving some allocations to be rounded up to the next power of two. That's easy to tell bmalloc and manager ourselves, but it over-commits memory. If we don't touch it, and it wasn't recycled (likely to happen since usually large) then we're fine, it's not actually mapped. But in the use cases we're going for we *dont't* know whether it was recycled memory or not so we have to initialize that extra memory lest there be old data that turns out to be useful in there (say, observable through speculative execution).
It would be great if we could ask bmalloc:
1. Give me `size` memory, rounded up to the next power of 2, and tell me how much of it is actually committed.
2. Reallocate memory that was allocated this way, either committing from the tail (and telling me where the new committed allocation ends), or moving and doing as 1. above.
This would be a new API where the caller can know:
A. The size that they say the would actually use.
B. The committed slack after this size (which must be committed because size isn't necessarily on a page boundary). That slack isn't meant to be used, but the caller wants to manually initialize it so that speculation can be constrained.
C. The virtually-reserved but un-committed tail (which is just the next power of two). This part doesn't need to be initialized to anything because speculation will end when it encounters unmapped pages.
Let's annotate with FIXMEs all places where we just over-allocate for now, and go back to fix them later with this API.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180109/e7d20685/attachment.html>
More information about the webkit-unassigned
mailing list