It's kind of too bad Linux to doesn't just support multiple base page sizes.
Transition to using 16 KB page sizes for Android apps and games
51–60 of 70 posts
Re: Transition to using 16 KB page sizes for Android apps and games
#52Earlier quoted context omitted.
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" i…
Is anything industrial is going to be built on Android.
There are no ATM's, no manufacturing CNC machines etc.
One my say everything that runs on Android is throw away. It is only recently Samsung and Google started to aim at 7 year life spans. At 7 years for an industrial piece of equipment, I may not have even paid it off as yet, then again is the software on these things even updated?
Re: Transition to using 16 KB page sizes for Android apps and games
#53Earlier quoted context omitted.
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" i…
Is anything industrial is going to be built on Android. There are no ATM's, no manufacturing CNC machines etc. One my say everything that runs on Android is throw away. It is only recently Samsung and Google started to aim at 7 year life spans. At 7 years for an industrial piece of equipment, I may not have even paid it off as yet, then again is the software on these things even updated?
Point of sale systems, like Toast. Media systems on airplanes. Infotainment systems in cars.
In fact, NCR does sell an Android-based ATM solution. [1]
Android is actually used somewhat widely in embedded systems that need to provide a nice GUI to the user.
[1]: https://www.zdnet.com/article/ncr-launches-kalpana-an-androi...
Re: Transition to using 16 KB page sizes for Android apps and games
#54> This table describes who needs to transition and recompile their apps information design is my passion
Table added as image, alt text vaguely explains table contents and has a spelling error. Great.
Re: Transition to using 16 KB page sizes for Android apps and games
#55Earlier 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.
This just provides yet another example of why tagged pointers are a terrible idea and shouldn't be used. Someday, more of the address space will get used and your software will break.
Re: Transition to using 16 KB page sizes for Android apps and games
#56I 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?
Tangent, but 1Mb pages aren't that absurd really. The x86-64 has hardware support for 4k, 2MB, and 1GB page sizes (because each level of the pagemap cuts 9 bits from the virtual address). Luckily it supports all 3 mixed together so normally you just keep most of your data in 4kb pages and use 2Mb/1Gb occasionally. But from my understanding nothings prevents you from forcing 2Mb on all userspace code even though Linux kernel doesn't support it.
Re: Transition to using 16 KB page sizes for Android apps and games
#57I 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?
What if you have a data structure that straddles the 4k boundary?
Re: Transition to using 16 KB page sizes for Android apps and games
#58Earlier 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.
Memory page size should be transparent for tagged pointers (any pointers, really), I don't see how they can be affected. You have an object at address 0xAB0BA, does the size of underlying page matter?
Re: Transition to using 16 KB page sizes for Android apps and games
#59Earlier quoted context omitted.
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" i…
I think most apps are written in Java, and according to the blog post will not be affected.
It's only the apps written in c++ that need to be compiled, and those are probably large games and heavily performance critical apps.
Re: Transition to using 16 KB page sizes for Android apps and games
#60I 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…
Someone I collaborate with has been having all sorts of fun with a 4k->64k page transition for stuff running on Arm. Among some of the fun has been discovering memory leaks that really weren't noticeable or a big deal at 4k, but now that the page is 16x larger, suddenly becomes noticeable and can even cause problems.