@PulkoMandy, @waddlesplash, @X512, @kallisti5, rpmalloc fork has active development, has improvements, bug fixes, which are not in the original version of rpmalloc, in addition to supporting more architectures.
I don’t really have much interest in looking more into rpmalloc further. It’s become clear to me that using memory allocators not designed or tested as “libc malloc” implementations is just not a good idea, especially ones developed primarily for and on OSes with overcommitting enabled by default.
The only differences there were adjusting rpmalloc to use various Haiku-specific hook functions and then tuning some of its options. There weren’t any actual changes to the allocator’s behavior, I don’t think.
I believe it is problems with the original rpmalloc, development is not so active and problems are not fixed, it would not be problems with the Haiku specific code, many of the problems with the original rpmalloc were fixed in the fork.
The problems we had with it were not in the implementation, but in the design. rpmalloc works OK for 64 bit systems where there is a lot of address space, but doesn’t scale down well to our requirements on 32 bit machines.
I don’t think this will be solved by some changes in the code. It needs a completely different architecture.
Also, software does not necessarily need to have constant changes to be good. The original rpmalloc had a release just 5 months ago, that seems very reasonable to me. This new one is changing a lot of things (new build system, compatibility with old C standards, …) for no real reason in our use case (I guess it makes sense for where they use it).
The fork is tested on 32-bit arm7 architecture, the fork author says there are no problems, but the problem in Haiku occurs on x86, mimalloc has problems on x86, requiring modification of the kernel.
The question is, is it a problem in the allocators, maybe 32-bit code in Haiku or all together?
It is difficult to say if the fork will have the same behavior, like the original rpmalloc, without performing tests.
There is no “problem”, just different goals. Haiku needs an allocator that works for all usages in the OS, allows to return memory to the OS (and other apps) when it is not needed, and works well with several threads and memorythat is shared between threads, typically alnocated in one and freed in another.
Some allocators will make different compromises, for example, use more memory, but be faster. So, it works, it is fast, but applications such as git which need a lo of memory will hit out of memory errors much quicker.
This is not solved with a few changes to the allocator code. In fact, a lot of the changes in rpmalloc latest 1.x versions were done based on our feedback. But at some point we reached the conclusion that it wasn’t the right design. And that is not something you can just “fix”
So wouldn’t it be better to write code for the allocator to work better in 32-bits, mimalloc and original rpmalloc, have problems in 32-bits, OpenBSD allocator, I don’t know if it will have problems, there is no stress/leak test to test in Haiku to have a comparison of allocators.