[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


            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