Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transition to using 16 KB page sizes for Android apps and games

android-developers.googleblog.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Transition to using 16 KB page sizes for Android apps and games

#31

Post by dwattttt »

yjftsjthsd-h wrote: post #10
dwattttt wrote: post #9

Earlier quoted context omitted.

Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.

> 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare. I would natively imagine the kernel could trap that and remap on the fly, at the tiny cost of murdering performance. Is that untrue, or is the perf so bad that it's not worth it?

It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract.

In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders of magnitude worse (e.g. a hot cache hit vs trapping into kernel, wiping caches, at the very least hundreds more accesses).

EDIT: I see you suggested remapping the page permissions. Maybe that helps! But maybe it adds the cost of the remapping onto the worst case, e.g. the first 4kb are instructions that write into the second 4kb.

Re: Transition to using 16 KB page sizes for Android apps and games

#32

Post by majke »

HPsquared wrote: post #24
mkw5053 wrote: post #8

I used to work closely with the Android team at Unity, and in my experience, shifting large native codebases to a new page size often uncovers subtle runtime assumptions beyond just replacing hardcoded constants like PAGE_SIZE. I’m optimistic Google’s tooling will help a lot, but interested about how effectively it catches these more nuanced compatibility issues like custom allocators or memory pooling tuned for 4K b…

Could they find those by setting page size to some absurdly large value like 1MB?

A lot of software wont work if you do that. Many jits and memory allocators have opinions on page size. Also tagged pointers are very common.

Re: Transition to using 16 KB page sizes for Android apps and games

#33

Post by junon »

nephanth wrote: post #18

From my noobish standpoint, it feels like most code shounldn't care what the page size is? Why does it need te be recompiled? What typically tends to break when changing it?

Performance, safety and IO critical code must care, because the page size affects TLB caching and is the finest granularity for security flags such as read-only, no execute, etc. which are critical for e.g. guard pages.

If your code that created two guard pages sandwiching a security critical page to make sure that under/overruns caused a page fault and crashed that assumed the boundary was at 4KiB, but is really now at 16KiB, that means that buffer overruns now will not get caught.

Further, code that assumed it was on a page boundary for some reason, for performance reasons, will now have only a 25% chance of being so.

It also means that MMIO physical pages that were expected to be contained within a 4KiB page such that when mapped into a sensitive user space driver context, neighboring MMIO control blocks wouldn't be touched, might be affected too since you'll get up to 3 neighboring blocks in either direction. This probably doesn't happen so often, I don't know Android internals much, but still something to consider.

This is in large part because PAGE_SIZE in a lot of C code is a macro or constant, rather than something populated at runtime depending on the system the code is running - something I've always felt is a bit problematic.

That being said, code that's hard coding PAGE_SIZE won't run anyway if using e.g. mmap() because it validates the page size and will error on mismatch.

This is going to wreak general havoc for a while no matter how you spin it.

Re: Transition to using 16 KB page sizes for Android apps and games

#34

Post by [deleted] »

londons_explore wrote: post #28

This is dumb. The abstraction is at the wrong level. Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video). At the hardware lev…

[deleted]

Re: Transition to using 16 KB page sizes for Android apps and games

#35

Post by ohdeargodno »

AnonC wrote: post #11

> Starting November 1st, 2025, all new apps and app updates that use native C/C++ code targeting Android 15+ devices submitted to Google Play must support 16 KB page sizes. I realize that most apps wouldn’t need to make changes and that a recompilation would suffice, but is this time frame enough for the apps that do need code changes?

If you, yourself have native code you're trying to build, it only required bumping the NDK (which is automatically bumped when you upgrade the android gradle plugin), so that's mostly an automatic step (provided you're not stuck on old, AGP7 build scripts).

If you depend on a package that uses a native library, you wait for them to update. Or you fork, bump AGP and rebuild.

It's a very minor change, unless you depend on unmaintained code.

Re: Transition to using 16 KB page sizes for Android apps and games

#36

Post by ohdeargodno »

londons_explore wrote: post #28

This is dumb. The abstraction is at the wrong level. Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video). At the hardware lev…

Dozens of years of kernel building, dozens of OSes, dozens of physical architectures, all having settled on minimum 4KB pages being a right balance between performance and memory usage, wiped away by a single offhand comment with no knowledge about the situation. Now that's HN.

Just the sheer TLB memory usage and performance implication of doing single byte pages would send CPU performance back to the stone age.

Re: Transition to using 16 KB page sizes for Android apps and games

#37

Post by murderfs »

londons_explore wrote: post #28

This is dumb. The abstraction is at the wrong level. Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video). At the hardware lev…

Your response to a change that's motivated by performance improvements is to suggest switching to a scheme that'll have catastrophically worse performance?

Re: Transition to using 16 KB page sizes for Android apps and games

#38

Post by pjc50 »

londons_explore wrote: post #28

This is dumb. The abstraction is at the wrong level. Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video). At the hardware lev…

If you're going to go that far, you might as well move malloc() into hardware and start using ARM-style secure tagged pointers. Then finally C users can be free of memory allocation bugs.

Re: Transition to using 16 KB page sizes for Android apps and games

#39

Post by notepad0x90 »

nephanth wrote: post #18

From my noobish standpoint, it feels like most code shounldn't care what the page size is? Why does it need te be recompiled? What typically tends to break when changing it?

most code shouldn't but you don't know what the library you're using is doing behind the scenes. the few code that do care, if a lot of people use them as a dependency, that could get real messy real fast.

Re: Transition to using 16 KB page sizes for Android apps and games

#40

Post by croemer »

rwmj wrote: post #26

From the experience implementing 64K page sizes on aarch64 in Fedora & RHEL, this is not going to be a simple transition. All sorts of things will break in subtle, strange and interesting ways. Good luck to the Android team :-)

I think you meant "Android developers" that are forced to switch their apps.
Post reply on HN