GrapheneOS
consider switching from hash table for large allocations to an arena-based red-black tree to satisfy range requests for malloc_object_size
The current implementation will lead to only being able to provide size results for offsets into the initial page(s) of a large allocation, since with a hash table there isn't a way to find the closest previous match.
This would have a performance cost compared to the hash table for allocation, and would also make malloc_object_size significantly slower. It might make sense as a configuration option, or perhaps it's not worth doing at all.
Hi, I was wondering if this issue has been resolved? If not, I'd be interested to take this issue on. However, I've only created a memory allocator with a first fit policy + segregated free list due to coursework. I have a vague idea of how an arena-based red black tree implementation might work, but are there any papers you could point me to to fully grasp how this might work?
Hi, I was wondering if this issue has been resolved?
No, but it's an extremely low priority and not really useful to GrapheneOS anymore. There are many much higher priority features.
Understood. Are there any other issues I should take a look at and attempt to work on?
For context, my primary background is mostly C and Rust; the former I have done in the context of university coursework with building things like memory allocators, linker, debugger, OS and a bit of Embedded System related stuff and the latter I mostly work on on my own time writing async multithreaded code, command line utilities, and contributing to open source software.