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.
<rdar://problem/36369165>