[GR-41487] Add runtime pagesize validation.

[graalvmbot]

No description provided.

[mkurz]

Is that GR-41487 public? If so, can you provide a link please?

[mkurz]

...to set appropriately.

To set what appropriately? The image page size or the page size at run-time?

[mkurz]

Right I can produce a native image with -H:PageSize=16384 (16k) or -H:PageSize=65536 (64k) for aarch64 linux (arm64) and I am able to run it successfully on a system that runs an aarch64 linux kernel with a pagesize of 4096 and also on another machine with a pagesize of 16384.
Will this pull request disallow that by failing early? (Which would be not so good...)

[teshull]

Yes, the page size at image creation (either the host page size or size set via -H:PageSize) is allowed to be a multiple of the runtime page size. That will still be allowed in the version of this PR which will be merged.

We are currently exploring how practical it is to make the image further agnostic to the runtime page size.

[mkurz]

@teshull Thanks!
So, to confirm, when building an aarch64 image (Linux), it is valid, ok and will work to just set -H:PageSize=65536 at image creation time and the image will then correctly work, no matter if the target machine's kernel that executes the binary, has a page size of 4k, 16k or 64k? I kind of understand that is not 100% ideal, since a page size of 64k is not optimized for a kernel that uses 4k (which most of them do), but other than more memory usage, its fine?
I try to figure out a solution for coursier/coursier#2636 (comment) - so basically I want a binary that runs on either 4k or 16k kernels.

Thanks!

[teshull]

Yes, setting -H:PageSize=65536 will work when the page size is 4K, 16K, or 64K, which will be the common case. It won't work when something like huge pages is used.

In terms of the tradeoffs of using 64K pages on a 4K machine, yes, there might be a little waste, but its impact should be minimal

[mkurz]

@teshull Thanks, that's what I wanted to hear! Happy holidays!