Ability to request the current(/approximate?) allocated size (ideally both, consumed by allocs and consumed by the slabs)

[Licenser]

Since this will likely add some overhead I suspect that this would need to be feature gated but it can be very helpful for an application to ask "How much memory have I allocated right now?". Jemalloc has this API and I've reached for it more than once for instrumenting an application.

[zooko]

Hm.... that information is not currently stored anywhere in smalloc's state. smalloc has a quite minimal amount of state: basically just one linked list (a "free list") per slab.

So, I can think of two possible ways to implement this:

1. Just add state. Interestingly, this could be done as a wrapper around smalloc or any other implementation of Rust's GlobalAlloc trait! Here's a sketch implementation:

pub struct AccountingAlloc {
    inner: &GlobalAlloc,
    allocated: usize,
}

impl AccountingAlloc {
    pub fn new(inner: &GlobalAlloc) -> Self {
        inner: inner,
        allocated: 0
    }

unsafe impl GlobalAlloc for AccountingAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        self.allocated += layout.size();
        self.inner.alloc(layout)
    }

    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        self.allocated -= layout.size()
        self.inner.dealloc(ptr, layout);
    }

    unsafe fn realloc(&self, ptr: *mut u8, layout: Layout, reqsize: usize) -> *mut u8 {
        self.allocated += (reqsize - layout.size());
        self.inner.realloc(ptr, layout, reqsize)
    }
}

That probably doesn't compile, doesn't handle various error cases, isn't threadsafe, etc., but you get the idea.

Option 2:

2. Traverse the entirety of all 2048 of smalloc's free lists every time someone calls the "how much space have I allocated?" function. At first I thought that was stupid, but then I was like "actually if they only need it occasionally it might be fast enough!". And then I remembered that I've just started implementing that anyway as an experiment in supporting the Windows Heap API: https://learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapwalk .

So, I think someone should implement that accounting wrapper allocator and see if it is ergonomic in practice in Rust. :-)

(Note: "how much memory I'm preventing other processes from using" is actually not a defined thing in the modern world with virtual memory. The super simple accounting wrapper proposed above will undercount it by a factor between 1 and 2 in smalloc and probably in other memory allocators, when the requested size is < the platform's page size, and overcount it a bit when the requested size is >= the platform's page size. But that probably doesn't matter that much for your use case. "How much memory I've requested and can use" is a defined thing, and that's what this simple proposal measures.)

[Licenser]

I used to use almost exactly that code a while ago 😅 (using a atomicusize instead of a normal one) there was a reason I stop but I don't quite remember the why but I'll give that another try.

[zooko]

Oh, good idea to solve the thread-safety issue by using AtomicUsize. Use fetch_add to make updates to it threadsafely without having to get a lock/mutex.

[zooko]

I used to use almost exactly that code a while ago 😅 (using a atomicusize instead of a normal one) there was a reason I stop but I don't quite remember the why but I'll give that another try.

If you try it, please let me know how it goes!