I did a smoke test yesterday with the increased reported page size on top of current master and the following are the links to the test runs:

• https://dev.azure.com/dnceng/public/_build/results?buildId=977738
• https://dev.azure.com/dnceng/public/_build/results?buildId=978052

The test originally failing in #42023 was failing in those test runs as well.

@dotnet/jit-contrib The change is ready to be reviewed, please take a look.

Since the CI testing was non-functioning yesterday I manually validated the change by running superpmi on libraries and tests collections with win_arm64_x64 clrjit. In order to simulate larger page size I made eeGetPageSize() returning 0x10000 (since the VM changes would not affect superpmi replay). I confirmed that without the change there are two assertions in the JIT related to un-encodable immediate value (one is it seen in #42023) and there are no assertions with the change.

I think it might be beneficial to add a complus variable (e.g. COMPlus_ForcePageSize) that would be active during altjits and force the JIT to use a different page size than reported by VM. Having such variable and a corresponding test scenario would've allowed to catch an issue like #42023 earlier in product cycle.

Sounds like a rare scenario to me and I don't think we have an appropriate pipeline for such testing, because if I understand correctly we can't run code generated with a bigger page size?

You are right, we don't run altjit pipelines anymore. But we could try running with an increased page size on Linux anyway. And if we had M1 machines in CI those, presumably, would run with 16KB page size.

Given the recent developments with the SuperPMI collections pipelines I wonder if it's worth adding a pipeline replaying the collections with different altjits that would allow not to only validate the SuperPMI replay function/harness but also validate altjit infrastructure.

arm64 mac tests passed (3 failures are expected):

Total tests run    : 10383
Total passing tests: 10380
Total failed tests : 3
Total skipped tests: 0

@sandreenko Thank you for confirming!

I am not convinced this is the right fix. Why aren't we just hard coding the probing size to 4K for local alloc. How will we handle when crossgen occurs on a 64K page machine and generates code to run on a 4K page machine.

Is the extra complexity and register usage really worth it?

How will we handle when crossgen occurs on a 64K page machine and generates code to run on a 4K page machine.

The crossgen will always use the hardcoded 4K page - see the changes in src/coreclr/vm/jitinterface.cpp

Is the extra complexity and register usage really worth it?

The temporary register usage would happen at most once. On a 4K page machine the register is never going to be used. On a 16K or 64K page machine allocation of a local heap would be done in a page size decrements (that size can encoded by sub) until the remaining space is smaller than a page. Now, if the remaining space is larger than allowed range of sub instruction immediate then this is when the register is going to be used.