What does HackerNews think of mimalloc?

mimalloc is a compact general purpose allocator with excellent performance.

Language: C

Memory management for C is not itself a solved problem, not only is there a lot of performance to squeeze out of malloc itself (the benchmarks on https://github.com/microsoft/mimalloc exemplifies the variance between the implementations), but it's up to the programmer to implement memory management in the large in an efficient way, which is not an easy task. One sure mark of a slow C program is one with a ton of mallocs and frees strewn all over.
Newer allocators like mimalloc[0] don't even support sbrk (I think jemalloc still does). Mimalloc seems to have some interesting features.

[0] https://github.com/microsoft/mimalloc

The in-place update work in Koka [1] is super impressive. One of my co-workers, Daan Leijen leads the Koka project and hearing his talks about it have been such a privilege. The work around Koka is really convincing me that functional languages will eventually lead the pack in the effort-to-performance trade-off.

Something that came out of the Koka project that everyone should know about is mimalloc [2]: if your built-in malloc is not doing it for you, this is the alternative allocator you should try first. Mimalloc is tiny and it has consistently great performance in concurrent environments.

[1]: https://koka-lang.github.io/koka/doc/index.html

[2]: https://github.com/microsoft/mimalloc

How does this compare mimalloc, the other allocator from Microsoft? https://github.com/microsoft/mimalloc
Yes, I am currently writing a masters thesis about it! It is a "research language that [is] currently under heavy development" as the README says so I don't recommend using it for anything other than a research/toy project. But you would be surprised how well it works: Algebraic effects can give you 98% the power of monads while being much faster and easier to understand. And then Koka uses mimalloc [0], Perceus [1] and tail recursion modulo cons which make Koka programs almost as fast as C++. For example, in the benchmarksgame, Haskell takes 5x as much time on the binarytrees benchmark as the fastest implementation, while Koka is 50% slower (similar to other C/C++ and Rust implementations).

[0]: https://github.com/microsoft/mimalloc [1]: https://news.ycombinator.com/item?id=25464354

Indeed, and not only did they develop the Perceus technique for the Koka language, but the immediately practical mimalloc allocator came out of that work as well.

https://github.com/koka-lang/koka https://github.com/microsoft/mimalloc

Microsoft's 'mimalloc' MIT-licensed allocator is lock-free. Perhaps there's something in there that'd be interesting to read.

  https://github.com/microsoft/mimalloc
  https://github.com/microsoft/mimalloc/blob/master/include/mimalloc-atomic.h
It has gone through testing with Clang's TSAN and (at least some with) the GenMC model checker.

  https://plv.mpi-sws.org/genmc/
Interesting article -- thanks! I see they used the `key ^ P` encoding where the `key` is `L >> PAGESHIFT` to use the ASLR randomized bits from the free list position `L`.

In [mimalloc](https://github.com/microsoft/mimalloc) we use a similar strategy to protect the free list in secure mode. However, there are some weaknesses associated with using a plain _xor_ -- if the attacker can guess `P` that reveals the key immediately (`P^key^P == key`) or even if there is a read overflow, and the attacker can read multiple encodings, they can xor with each other, say `(P1^key)^(P2^key)` and then we have`(P1^P2)` which may reveal information about the pointers (like alignment).

What we use in _mimalloc_ instead is two keys `key1` and `key2` and encode as `((P^key2)<<Just some thoughts. Of course, this may be too much for the use-case. However, we found just little extra overhead for the extra operations (as most programs are dominated by memory access) so it may be of benefit.