So, do 4 KB page size apps work on these 16 KB page size phones? There are plenty of legacy apps (especially games I'd imagine) that will never updated for one reason or another. I would want to know if I was buying a phone that won't support those...
That ship already sailed, most legacy Android games were killed by 32bit support being phased out both in hardware (newer SOCs are 64bit only) and software (Android 14 doesn't support 32bit apps even when running on an older SOC). They've done it before and they'll do it again.
Which is a shame, a modern SoC is fast enough to emulate 32-bit in userspace with same-or-better performance than the real 32-bit SoCs from that period.
> Android 14 doesn't support 32bit apps even when running on an older SOC
Huh? Tell that to my phone. Maybe Google dropped support from their own OS builds even for older phones, but I don't think AOSP as such has dropped 32-bit-compatibility yet, and other OEMs have kept 32-bit-support for those phones whose hardware still supports it.
(And at least one or two Chinese OEMs have been shipping some sort of compatibility layer for phones without hardware support, though possibly only for the domestic market, not export models/OS builds.)
It's true though that Google isn't too heavily invested in binary compatibility for native code, though to some extent their hand might have also been forced by the SOC manufacturers, because apparently 32-bits hardware compatibility is more expensive to provide on ARM.
WearOS devices are still predominantly 32bit. Android hasn't stopped supporting those in any way. They are trying to entice phones to no longer support 32bit but the support on Android still exists.
There's probably something that'll break, but iOS switched to 16KB pages with zero publicity or warning and it caused very few problems. The vast majority of applications don't care about what the page size is at all, and cross-platform native code already has to handle different page sizes so hopefully people didn't do the stupid thing of hardcoding it for Android and only dynamically checking on iOS.
Isn’t the biggest issue that compiled binaries have segments aligned only to 4kb, and those segments must be on different pages (because they have different memory protections) and can’t be slid relative to each other? I’m not sure how iOS dealt with this (maybe arm64 binaries always had 16kb aligned segments?), but apparently this is an issue on Android and requires all binaries to be recompiled.
I suspect it would depend on if they have problematic native code.
The executable format (if it’s native code) doesn’t actually specify what page size it wants right? So there would be no way for the OS to block 4 KB page apps.
I guess they could block stuff that targets an older API version, but that would block a lot of things that would otherwise work just fine.
The executable format defines a number of segments, which must be on separate pages because they have different permissions, and can’t be slid relative to each other. So the page size can’t be larger than the segment alignment chosen at link time, though it can be smaller.
I'm wondering if it will not make the apps overall memory usage explode a little bit more by having a lot of objects bound to a single page with more empty space unused inside most pages for common cases.
The underlying problem is that there are several different things, and many of them currently don't have APIs:
* the known-constant page size that must be passed so you won't get failure from `mmap(MAP_FIXED)`, `mprotect`, etc. (even if you don't call these directly, ELF relies on them and traditionally 4K was used on many platforms; raising it requires a version of ld.so with proper support). There is no macro for this. On platforms I know about, it varies from 4K to 64K. Setting it to a higher multiple of 2 is by design always safe.
* the known-constant page size that unconstrained `mmap` is guaranteed to return a multiple of. There is no macro for this. This is 4K on every platform I know about, but I'm not omniscient. Setting it to a lower multiple of 2 is by design always safe.
* the dynamic page size that the current kernel is actually using. You can get this using `getpagesize()` or `sysconf(_SC_PAGESIZE)` (incidentally the man page for `getpagesize(2)` is outdated by assuming page size only varies by machine, not at boot time)
The macro `PAGESIZE` is traditionally provided if the upper/lower bounds are identical, and very many programs rely on it. Unfortunately, there's no way to ask the kernel to increase the alignment that unconstrained `mmap` returns, which would safely allow defining PAGESIZE to the largest possible value.
Note that it is possible to get compiler errors for incompatible definitions of constants (or ranges thereof) by relying on `ld` magic (each value pulls in variable definied in a distinct object file that also defines an additional shared variable, causing multiple-definition errors), but this would need to be done by whoever provides the macros (which should be libc).
Also various performance characteristics graphs will have steps around the multiples of page sizes. People would find out anyway. (Although maybe the runtime detection is not a bad idea)
the mprotect API could have been designed more like malloc() - ie. you don't protect a preexisting memory range - instead the API returns a new memory range with the protections you've asked for, possibly copying a load of data into it for you incase you asked for a readonly range.
And that 'copy' might be zero-overhead remapping of the original pages.
you can simulate arbitrary sized mprotect() by having the kernel do the closest it can using the hardware, and then any pages crossing the boundary will be handled by page faults. The performance hit should be small as long as most mprotect regions are large (which they typically are).
Absolutely. Breaking apps for all users when the system's page size changes is much better than inconveniencing the handful of developers that would have to work around a more abstracted page size.
Same reason why I think electron is great. Devex for 3 people is so much more important than ux for the 30M users.
But realistically, you only need to know the lower bound for the page size, so pages larger by an unknown multiple are not a problem. Or use masked loads, and don't even worry about pages.
Readit News
Completely untrue and can be entirely circumvented by one ADB flag (--bypass-low-target-sdk-block) or a third-party .apk installer.
Huh? Tell that to my phone. Maybe Google dropped support from their own OS builds even for older phones, but I don't think AOSP as such has dropped 32-bit-compatibility yet, and other OEMs have kept 32-bit-support for those phones whose hardware still supports it.
(And at least one or two Chinese OEMs have been shipping some sort of compatibility layer for phones without hardware support, though possibly only for the domestic market, not export models/OS builds.)
It's true though that Google isn't too heavily invested in binary compatibility for native code, though to some extent their hand might have also been forced by the SOC manufacturers, because apparently 32-bits hardware compatibility is more expensive to provide on ARM.
https://source.android.com/docs/core/architecture/16kb-page-...
The executable format (if it’s native code) doesn’t actually specify what page size it wants right? So there would be no way for the OS to block 4 KB page apps.
I guess they could block stuff that targets an older API version, but that would block a lot of things that would otherwise work just fine.
On top of that, adding 4kb (or 16kb) pages sprinkled across adds more to the TLB cache.
Imagine a world where the page size is secret to userspace. Anything that needs page size alignment will be chosen by the kernel.
That in turn allows mixed page size, variable page size, heirarchical pages, etc.
* the known-constant page size that must be passed so you won't get failure from `mmap(MAP_FIXED)`, `mprotect`, etc. (even if you don't call these directly, ELF relies on them and traditionally 4K was used on many platforms; raising it requires a version of ld.so with proper support). There is no macro for this. On platforms I know about, it varies from 4K to 64K. Setting it to a higher multiple of 2 is by design always safe.
* the known-constant page size that unconstrained `mmap` is guaranteed to return a multiple of. There is no macro for this. This is 4K on every platform I know about, but I'm not omniscient. Setting it to a lower multiple of 2 is by design always safe.
* the dynamic page size that the current kernel is actually using. You can get this using `getpagesize()` or `sysconf(_SC_PAGESIZE)` (incidentally the man page for `getpagesize(2)` is outdated by assuming page size only varies by machine, not at boot time)
The macro `PAGESIZE` is traditionally provided if the upper/lower bounds are identical, and very many programs rely on it. Unfortunately, there's no way to ask the kernel to increase the alignment that unconstrained `mmap` returns, which would safely allow defining PAGESIZE to the largest possible value.
Note that it is possible to get compiler errors for incompatible definitions of constants (or ranges thereof) by relying on `ld` magic (each value pulls in variable definied in a distinct object file that also defines an additional shared variable, causing multiple-definition errors), but this would need to be done by whoever provides the macros (which should be libc).
And that 'copy' might be zero-overhead remapping of the original pages.
https://developer.android.com/ndk/guides/stable_apis
Same reason why I think electron is great. Devex for 3 people is so much more important than ux for the 30M users.
How would you have had users handle SIMD tails?
But realistically, you only need to know the lower bound for the page size, so pages larger by an unknown multiple are not a problem. Or use masked loads, and don't even worry about pages.
Deleted Comment