Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

"In Android 11, Scudo [1] replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap"

I am curious about the performance impact of this change.

[1] https://source.android.com/devices/tech/debug/scudo

View on HN

I found this [0] 2019 blog post from what looks to be one of the people credited in the blog post (Kostya). It's not directly comparing Android+jemalloc vs Android+Scudo, but it does compare the two allocators and others.

[0] http://expertmiami.blogspot.com/2019/05/what-is-scudo-harden...

So according to these figures, scudo is the best allocator out of all the options tested? That's pretty decent.

Most Android apps probably allocate more with the JVM than they do malloc, right? My intuitive guess is that they could regress the performance of libc malloc and many people wouldn't notice.

Yes, the NDK main goal is for writing native libraries, not full blown applications.

Although native memory allocations can happen via ByteBuffer, HardwareBuffer, image decoders, or native libraries.

Many games are written in C/C++ with the minimal amount of Java.

Games are usually written to allocate memory upfront and keep the per-frame allocation cost from affecting performance, by re-using buffers.

So I would expect a well written game to also not be a workload in which you can recognize a poor performing malloc.

Same with media code for similar reasons.

Reply on news.ycombinator.com