CoreCLR: use ARM64 reach for preferred code placement - #134220
AndyAyersMS wants to merge 1 commit into
Conversation
Use a 128 MiB reach, less a 64 KiB margin, on Windows ARM64 to reduce jump stubs for calls to runtime helpers. Leave other targets unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6bd43e03-841f-47ee-80f4-4da985b32a67
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Tagging subscribers to this area: @agocke |
|
@davidwrighton ptal data from a large app on windows arm64 (with the two code heaps). App has around 10MB of Tier1 code, 
|
There was a problem hiding this comment.
🔵 Needs a closer look
ARM64 runtime behavior was not executed in the main-branch build and requires human validation.
Pull request overview
Updates Windows ARM64 executable placement to keep runtime helper calls within direct branch reach, reducing jump stubs while preserving other targets.
Changes:
- Uses a 128 MiB reach minus a 64 KiB margin on ARM64.
- Retains existing behavior for non-ARM64 targets.
File summaries
| File | Description |
|---|---|
src/coreclr/utilcode/executableallocator.cpp |
Adds the ARM64-specific preferred-range constant. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
| // helpers and R2R images loaded close to coreclr.dll. | ||
| // | ||
| #if defined(TARGET_ARM64) | ||
| // ARM64 B/BL instructions have a +/-128 MiB reach; leave a 64 KiB margin. |
There was a problem hiding this comment.
Does this materially increase chances of ASLR .dll placement colliding with our code heap and causing expensive .dll relocations?
ASLR used to place all .dlls together, so reserving memory close the native .dll was likely to conflict with address chosen by ASLR. I am not sure whether this problem still exists (on Windows).
There was a problem hiding this comment.
Good question. Let me see if I can find a way to assess the chances this could happen.
Use a 128 MiB reach, less a 64 KiB margin, on Windows ARM64 to reduce
jump stubs for calls to runtime helpers. Leave other targets unchanged.
In a local Windows ARM64 experiment on 10.0.11 with separate Tier1 heaps,
helper distances fell from about 1.5 GiB to 67-85 MiB, and captured Tier1
helper call sites switched from long branch stubs to direct branches.
Note
This pull request description was generated with GitHub Copilot.