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

41–50 of 70 posts

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

#41

Post by izacus »

extraduder_ire wrote: post #14
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?

They've mentioned this requirement before, last hn post I see is from early may. They only added support in android 15, in august 2024. https://android-developers.googleblog.com/2024/08/adding-16-... I don't know what "targetting Android 15+" means specifically. Does that include anything with a lower API level?

Android apps have a flag in their manifest which tells the OS "this app was built with Android X (API level X) in mind".

This allows the OS to selectively enable backwards compatibility and change certain behaviors (e.g. selectively enforce new permissions so old apps aren't broken).

Play Store requires apps to target new OSes and port APIs within certain time of an OS launching (usually ~2 years).

This avoids apps targeting older OSes to avoid new security and privacy enhancements (e.g. asking for permisisons to show notifications, asking for permisisons to access microphone, being allowed to show a fullscreen popup ad, etc. Those restrictions were all gated behind the target check.)

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

#43

Post by FullyFunctional »

ohdeargodno wrote: post #36
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.

Completely false. The 4 KiB page size came from a machine with a total of 512 KiB (1962 Atlas, 3072B pages, 96k 48b words). It hasn’t scaled at all for inertia reasons and it has real and measurable costs. 64 KiB would have been the better choice IMO, but 16 is better than 4.

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

#44

Post by rwmj »

majke wrote: post #32
HPsquared wrote: post #24

Earlier quoted context omitted.

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.

Also quite a lot of kernel drivers allocate whole pages (sometimes the device being driven requires it).

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

#45

Post by londons_explore »

murderfs wrote: post #37
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?

It would likely have better performance for similar power and silicon area, because a hierarchical TLB will have a higher hit rate for the same number of transistors.

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

#46

Post by londons_explore »

ohdeargodno wrote: post #36
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.

My proposed design has many page sizes - nothing stops a software developer making all mappings multiples of 4kb and not using the byte sized pages.

My example was 1mb, 4kb and 1 byte pages - but a real design would probably use every power of two, or every even power of two to get best use of the TLB space.

It hasn't been done before because of a chicken and egg problem. CPU designers don't build it because no OS has the ability to use it, and no OS uses it because no CPU supports it. It would be a substantial amount of work for both parties.

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

#47

Post by ohdeargodno »

FullyFunctional wrote: post #43
ohdeargodno wrote: post #36

Earlier quoted context omitted.

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.

Completely false. The 4 KiB page size came from a machine with a total of 512 KiB (1962 Atlas, 3072B pages, 96k 48b words). It hasn’t scaled at all for inertia reasons and it has real and measurable costs. 64 KiB would have been the better choice IMO, but 16 is better than 4.

Hence the "minimum" part. The thread is literally about Android being compiled for 16KB pages, CPU support for larger pages has grown, easily up to 4MB for most consumer CPUs.

Going down _lower_ than 4KB is purely a waste of memory and performance.

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

#48

Post by londons_explore »

rwmj wrote: post #27
londons_explore wrote: post #23

If you're making the migration at all, you really ought to be going for fully variable page sizes, otherwise 5 years from now there'll be a 64K page size CPU and suddenly everyone has to recompile everything again and there is another compatibility wall...

Is there a such a thing? Page size gets baked into things like executable layouts, plus any place that uses the PAGE_SIZE constant (instead of sysconf(_SC_PAGESIZE)).

Indeed it would take redesigning a bunch of things to make runtime variable page size an option.

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

#49

Post by mapt »

ryao wrote: post #5
nubinetwork wrote: post #4

I can understand the desire for google to want devs to recompile their apps, but I don't see the need to dump old apps from the app store... who cares if an old app that works wastes 12k if it only needs a single 4k page?

I am not familiar with Android, but Linux ELF binaries that specify 4KB alignment will not work on systems with 16KB page sizes, since the ELF interpreter will refuse to load them. This hit me recently when trying to run a 32-bit binary on a Linux ARM system that had 16KB size pages, since the 32-bit OpenSSL libraries specified 4KB alignment. Presumably, this was done for maximizing entropy available to ASLR, but it…

As a user not involved in android or linux development: I don't care. Fix it. You just don't break the entire ecosystem of unmaintained apps for a 3% performance improvement.

We maintained win32-x86 executable compatibility for decades. Keeping things working might require some sort of emulation layer, and it might impact performance substantially, and that's fine. I can accept that.

"Everything just stops working" is not an option for a real operating system. I don't expect to put my workshop tools away and wake up in the morning to find the toolchest manufacturer sent them to the landfill because they didn't efficiently fit their new drawers.

One of the areas that Android is common in that I couldn't possibly recommend is home automation. Your light switches are 50-year purchases. Odds that the app based light switches are working in five years are 50/50... Compound odds of longer are miniscule.

Post reply on HN