<story><title>Adding 16 kb page size to Android</title><url>https://android-developers.googleblog.com/2024/08/adding-16-kb-page-size-to-android.html</url></story><parent_chain><item><author>dotancohen</author><text>Yes, but the context here is Java or Kotlin running on Android, not embedded C.&lt;p&gt;Or do some Android applications run embedded C with only a Java UI? I&amp;#x27;m not an Android dev.</text></item><item><author>o11c</author><text>The fundamental problem is that system headers don&amp;#x27;t provide enough information. In particular, many programs need both &amp;quot;min runtime page size&amp;quot; and &amp;quot;max runtime page size&amp;quot; (and by this I mean non-huge pages).&lt;p&gt;If you call `mmap` without constraint, you need to assume the result will be aligned to at least &amp;quot;min runtime page size&amp;quot;. In practice it is &lt;i&gt;probably&lt;/i&gt; safe to assume 4K for this for &amp;quot;normal&amp;quot; systems, but I&amp;#x27;ve seen it down to 128 bytes on some embedded systems, and I don&amp;#x27;t have much breadth there (this will break many programs though, since there are more errno values than that). I don&amp;#x27;t know enough about SPARC binary compatibility to know if it&amp;#x27;s safe to push this up to 8K for certain targets.&lt;p&gt;But if you want to call `mmap` (etc.) with full constraint, you must work in terms of &amp;quot;max runtime page size&amp;quot;. This is known to be up to at least 64K in the wild (aarch64), but some architectures have &amp;quot;huge&amp;quot; pages not much beyond that so I&amp;#x27;m not sure (256K, 512K, and 1M; beyond that is almost certainly going to be considered huge pages).&lt;p&gt;Besides a C macro, these values also need to be baked into the object file and the linker needs to prevent incompatible assumptions (just in case a new microarchitecture changes them)</text></item><item><author>a1o</author><text>&amp;gt; The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix&lt;p&gt;&amp;gt; once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices&lt;p&gt;I am curious about this. When could an app NOT be agnostic to this? Like what an app must be doing to cause this to be noticeable?</text></item></parent_chain><comment><author>david_allison</author><text>The Android Native Development Kit (NDK) allows building native code libraries for Android (typically C&amp;#x2F;C++, but this can include Rust). These can then be loaded and accessed by JNI on the Java&amp;#x2F;Kotlin side&lt;p&gt;* Brief overview of the NDK: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developer.android.com&amp;#x2F;ndk&amp;#x2F;guides&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developer.android.com&amp;#x2F;ndk&amp;#x2F;guides&lt;/a&gt;&lt;p&gt;* Guide to supporting 16KB page sizes with the NDK &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developer.android.com&amp;#x2F;guide&amp;#x2F;practices&amp;#x2F;page-sizes&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developer.android.com&amp;#x2F;guide&amp;#x2F;practices&amp;#x2F;page-sizes&lt;/a&gt;</text></comment>
<story><title>Adding 16 kb page size to Android</title><url>https://android-developers.googleblog.com/2024/08/adding-16-kb-page-size-to-android.html</url></story><parent_chain><item><author>dotancohen</author><text>Yes, but the context here is Java or Kotlin running on Android, not embedded C.&lt;p&gt;Or do some Android applications run embedded C with only a Java UI? I&amp;#x27;m not an Android dev.</text></item><item><author>o11c</author><text>The fundamental problem is that system headers don&amp;#x27;t provide enough information. In particular, many programs need both &amp;quot;min runtime page size&amp;quot; and &amp;quot;max runtime page size&amp;quot; (and by this I mean non-huge pages).&lt;p&gt;If you call `mmap` without constraint, you need to assume the result will be aligned to at least &amp;quot;min runtime page size&amp;quot;. In practice it is &lt;i&gt;probably&lt;/i&gt; safe to assume 4K for this for &amp;quot;normal&amp;quot; systems, but I&amp;#x27;ve seen it down to 128 bytes on some embedded systems, and I don&amp;#x27;t have much breadth there (this will break many programs though, since there are more errno values than that). I don&amp;#x27;t know enough about SPARC binary compatibility to know if it&amp;#x27;s safe to push this up to 8K for certain targets.&lt;p&gt;But if you want to call `mmap` (etc.) with full constraint, you must work in terms of &amp;quot;max runtime page size&amp;quot;. This is known to be up to at least 64K in the wild (aarch64), but some architectures have &amp;quot;huge&amp;quot; pages not much beyond that so I&amp;#x27;m not sure (256K, 512K, and 1M; beyond that is almost certainly going to be considered huge pages).&lt;p&gt;Besides a C macro, these values also need to be baked into the object file and the linker needs to prevent incompatible assumptions (just in case a new microarchitecture changes them)</text></item><item><author>a1o</author><text>&amp;gt; The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix&lt;p&gt;&amp;gt; once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices&lt;p&gt;I am curious about this. When could an app NOT be agnostic to this? Like what an app must be doing to cause this to be noticeable?</text></item></parent_chain><comment><author>fpoling</author><text>Chrome browser on Android uses  the same code base as Chrome on desktop including multi-process architecture. But it’s UI is in Java communicating with C++ using JNI.</text></comment>