Skip to content

Conversation

/// Returns the available bytes in the memory block, or 0 if `ptr` was NULL.
///
/// The returned size is always at least equal to the allocated size of `ptr`,
/// and, in the current design, should be less than 16.7% more.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand this, can you elaborate? Does it mean that the result of calling usable_size is overestimated by at most 16.7%?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is copied from the mimalloc docs (see the link above) and is an implementation detail. Other allocators can also overestimate usable_size.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that usable_size might return a size that's 16.7% less than the actual allocation size. But always larger than the size used to request the allocation, right ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnzlbg mmmh, no that's not how I read it. "at least equal to the allocated size", so it never returns less than the actual size, but may overestimate it. If it does overestimate, the error is at most 16.7%. Or am I reading it wrong?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this sentence the same way @dvdplm does, the more part at the end refers to overestimation.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't mean that the size of the allocation is overestimated. What this means is that the memory block where the allocation lives can be greater than the allocation, which is standard practice.

Copy link
Owner

@gnzlbg gnzlbg Jul 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jemallocator provides the same exact same semantics that malloc_usable_size has in all platforms, e.g., glibc says exactly that as well: http://man7.org/linux/man-pages/man3/malloc_usable_size.3.html

Copy link
Owner

@gnzlbg gnzlbg Jul 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The recommendation for using this also for debugging purposes is in glibc as well, because malloc_usable_size is super slow compared with other functions to query the size of an allocation.

Because of its type signature, it needs to find the allocation that a pointer points to in the internal data-structures, which might require jumping around memory around.

Other APIs like mi_good_size are just pure functions that give you the size of the allocation block as a function of its arguments, no memory traversal necessary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks for the clarification. The confusion comes from using the allocated size of 'ptr' wording instead requested size of allocation for 'ptr'.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to send a PR to this crate and/or jemallocator improving the docs to make things clearer. What's clear to each of us in isolation is not necessarily clear to everybody 😆

@gnzlbg gnzlbg merged commit 56f85f5 into gnzlbg:master Jul 3, 2019
@gnzlbg
Copy link
Owner

gnzlbg commented Jul 3, 2019

@ordian @dvdplm FYI #6 removes usable_size from mimallocator - you can use it directly via mimalloc-sys, no need to repeat it there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants