Feature: Allocate at Fixed Address

[paniq]

Would it be a good fit for tlsf to support attempting to allocate memory at a desired address within the available range? (Sort of mimicking the behavior of mmap with MAP_FIXED) Or is that categorically impossible / prohibitively expensive?

Background: For a compiler project where I need a deterministic allocator operating on a fixed address range to improve offline caching behavior, the recursive allocation features of TLSF are quite useful to compartmentalize the allocations of individual modules, and reproduce local allocation behavior on every run. But if the subranges themselves are allocated in a different order, then the address mapping changes, busting the cache, even though nothing else within the modules has changed.

How I'd expect this feature to work would be to have a function such as void* tlsf_malloc_at(tlsf_t tlsf, void *ptr, size_t bytes);, which allocates size bytes at ptr if possible; if that fails, it tries any address larger than ptr (allowing us to allocate by desired starting offset); if that fails, it regresses to regular tlsf_malloc.

[zeromus]

Seems like a more generally useful tool that would get you the same thing possibly might be to serialize the state of the TLSF instance. Note, in your case, since there's an assumption the pools are at the same base address through subsequent runs, this would be trivial simply by dumping the pool's entire memory. To get things at the same offset in the pool when it's based on another address, you'd have to serialize the TLSF state along with a list of offsets relative to the pool base of each of your objects; then, deserialize the tlsf state (to a different base address) and simply poke each of your objects at the required rebased address (at which point, as far as TLSF or anyone else is concerned, the object is happily situated at a legally-allocated address)

[paniq]

@zeromus first of all, I can not rebase allocations because their contents are opaque. If we can not guarantee that we can map them into the same module segment as last time, then that's a cache miss and the underlying module must be run again to populate the new segment. But thinking about it a bit more, I realized that since the segments themselves all have the same preallocated size, and TLSF supports multiple instances as well as chaining pools (very useful when the segment is OOM), I can write a much simpler (pinnable) pool allocator just for the segments, and do not need to use TLSF recursively.

Secondly, it's still cool to be able to allocate at a desired address. But having now read (and ported) the source in its entirety, I see how that is possible but O(N) slow.