• 1 Post
  • 28 Comments
Joined 3 years ago
cake
Cake day: July 7th, 2023

help-circle


  • In theory, moving over to 16KB has quite a few benefits. Each page table maps 4x the memory, resulting in fewer memory accesses and better cache coverage, improving performance and power efficiency. There are trade-offs, however.

    Internal memory fragmentation is slightly worse, resulting in some additional RAM being wasted when apps request small amounts of memory. Android itself has been page size agnostic since Android 15, but that doesn’t mean older applications are. Many older “native code” applications (such as those written in C or using the Android NDK) were built with 4KB pages in mind and need to be rebuilt with 16KB alignment (which remains 4KB-compatible as well). Google expects that most apps built with Kotlin are already compatible, but this is still a potentially significant developer burden. It presents a particular problem for apps that are no longer maintained or use libraries that have not yet been updated.












  • out of context?

    Please coordinate with us before starting any porting work so nobody wastes their time on something we can’t merge.

    If you look at the code, you’ll notice it has a strong “translated from C++” vibe. That’s because it is translated from C++. The top priority for this first pass is compatibility with our C++ pipeline. The Rust code intentionally mimics things like the C++ register allocation patterns so that the two compilers produce identical bytecode.

    that seems reasonable to me