Live data from Hacker News

Why malloc always does more than I asked for?

ssenthilnathan3.github.io

51–52 of 52 posts

Re: Why malloc always does more than I asked for?

#51
post #48
post #42

Earlier quoted context omitted.

You mean 4 bytes? You can't even address 4 bits. Small allocations can be handled by a slab allocator. Most likely implemented via a free list. A general purpose malloc should have that feature. TBH, I would consider allocating such tiny amounts of memory as a programmer error.

No, I meant 4 bits. Assume I have only a small amount of memory, but I need to use an allocator and I don't want to use a custom allocator. > You can't even address 4 bits. This is not true, you can use a pointer plus extra offset data, etc.

As I said, a slab allocator is included as part of general purpose malloc implementations. Rust is not going to be smarter here. I would bet it uses malloc underneath anyway.

Using a fat pointer to address individual bits is a waste of memory. You'd need an offset and length, and you'd have to deal with byte boundaries when accessing data. The only way I see this working is if you had a language that natively supported sub byte types and could deal with alignment of such types natively. Your best bet would be bit fields, which Rust doesn't support natively.

Dynamically allocating tiny amounts of data is a niche issue. You don't want a genetic solution to this anyway, because the efficiency will come from the constraints specific to your problem.

Re: Why malloc always does more than I asked for?

#52

Earlier quoted context omitted.

There is no reason an allocation needs to contain any inline metadata. And even if it does, the allocator could choose to make it unalined, and pay the cost of an unalined access on de-allocation.

This is explained in TFA, where it is mentioned that you can replace inline metadata with a pointer to metadata (or an index), which may be unaligned, if necessary. However, the pointer to metadata is not really necessary. The associated metadata could be stored in a table, and the index of the metadata could be computed from the offset of the pointer returned by malloc to the start of the heap (possibly using a hash…

I consider an inline-pointer a form of inline-metadata. When I mentioned that inline metadata isn't necessary I was referring to the kind of external lookup you describe.
Post reply on HN