Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
1–10 of 60 posts
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#2[deleted]
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#3That's cool. I've written small but less flexible things before based on arrays as used/freed block maps rather than lists, from embedded devices with 128K of RAM.
This seems like it has some nice features. Though a 3K overhead could be important in such a constrained environment (I guess if it's only managing 128k that could reduce).
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#4Looks nifty and simple. Last time I had to work with low mem environment (64k heap for Lua running on MIPS) I ended up implementing something close to TLSF [1] allowing to choose some trade-offs regarding perf/allocation efficiency.
In the end we still had to add one layer of hack^H^H engineering tricks to workaround fragmentation issues in the worst case :-)
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#5Its a nifty tool, but I can't help feeling a little disappointed that we're still having to deal directly with issues such as memory allocation in 2019.
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#6That's cool. I've written small but less flexible things before based on arrays as used/freed block maps rather than lists, from embedded devices with 128K of RAM. This seems like it has some nice features. Though a 3K overhead could be important in such a constrained environment (I guess if it's only managing 128k that could reduce).
3k overhead where you’re trying to reduce from malloc is definitely a lot. One of my products have 8K total, not going to waste 3 of that replacing malloc.
I’m fairly happy that mirsa C forbids malloc. I can’t use it even if I wanted to, so I need to be more careful about how memory is used. Annoying at first, makes a lot of sense later on though.
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#7That's cool. I've written small but less flexible things before based on arrays as used/freed block maps rather than lists, from embedded devices with 128K of RAM. This seems like it has some nice features. Though a 3K overhead could be important in such a constrained environment (I guess if it's only managing 128k that could reduce).
That concept is called a memory pool or storage pool. Very useful, but their greatest disadvantage compared to malloc() is that you waste a lot of memory if your allocation size varies greatly (for example a network protocol where packet size can range from few bytes to KB).
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#8That's cool. I've written small but less flexible things before based on arrays as used/freed block maps rather than lists, from embedded devices with 128K of RAM. This seems like it has some nice features. Though a 3K overhead could be important in such a constrained environment (I guess if it's only managing 128k that could reduce).
3k overhead where you’re trying to reduce from malloc is definitely a lot. One of my products have 8K total, not going to waste 3 of that replacing malloc. I’m fairly happy that mirsa C forbids malloc. I can’t use it even if I wanted to, so I need to be more careful about how memory is used. Annoying at first, makes a lot of sense later on though.
It is quite possible (and it can be reasonable) to deviate from that rule. For example you could write a wrapper for malloc that only allows dynamic allocation in the initialization phase of your program. This can be useful to allocate memory for opaque-pointer-style types.
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#9That's cool. I've written small but less flexible things before based on arrays as used/freed block maps rather than lists, from embedded devices with 128K of RAM. This seems like it has some nice features. Though a 3K overhead could be important in such a constrained environment (I guess if it's only managing 128k that could reduce).
Did similar implementation 15 years ago. I needed a implementation that works in SMP environment and it didn't use lock. I use atomic increment to allocate block index, atomic dec to free the block index. It worked very well with good performance in SMP environment. It was implement as share library and the same code can be link statically in the kernel module. Linux Kernel can allocate the block and pass the pointer (index to the block) as parameter to user space and user space and de reference it directly.
The library was implemented using C++. We also ported that to QNX in addition to Linux Kernel.
I remembered it can do > 1 millions msg block per second between user space programs or similar perf for between user and kernel space.
It did waste some amount of space. That can be config at system startup.
Re: Tinyalloc: replacement for malloc/free in unmanaged, linear memory situations
#10Its a nifty tool, but I can't help feeling a little disappointed that we're still having to deal directly with issues such as memory allocation in 2019.
How do you think we should be dealing with memory allocation instead?