Open grendello opened 1 week ago
Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.
/cc @vitek-karas
- Code review of native (and maybe some managed?) code needs to be done in order to make sure we don't assume 4k page size anywhere
coreclr should work on variable page sizes. macOS ARM64 uses 16kB pages, we have tested Linux arm64 with 64kB pages in the past too. I am not sure about the x64 though, there might be some stuff expecting 4kB page size for this architecture.
Ah, sorry, this issue is mono specific, right?
Ah, sorry, this issue is mono specific, right?
Yeah, but it's also important to understand how coreclr would behave.
@janvorli CoreCLR is used to build apps that run on Android too, so as @steveisok said, it's important to make sure it works too.
Ok, I am glad the details I have added above are useful then.
Actually, as for x64, the hardware only supports 4kB, 2MB and 1GB large pages. See the Intel® 64 and IA-32 Architectures Software Developer’s Manual.
for x64, the hardware only supports 4kB, 2MB and 1GB large pages
They have kernel that simulates 16kB page sizes on x64 for testing purposes: https://source.android.com/docs/core/architecture/16kb-page-size/getting-started-cf-x86-64-pgagnostic
Wiki: https://github.com/xamarin/xamarin-android/wiki/Android-support-for-devices-with-16k-pages
Summary
Android is moving towards supporting devices with 16k memory page size, for the
x64
andarm64
architectures. This affects all the native components of the application. In our case it means the MonoVM runtime, theBCL
support libraries and .NET for Android native runtime and libraries.Google plan to make support for 16k devices a requirement for Google Play application submissions next year.
A lot of work needs to be done.
Google have an article with more technical details.
How it affects the runtime