Investigate impact of method entry alignment

[AndyAyersMS]

Current code alignment strategy seems a bit random. Best I can tell it is:

• on x86 we generally 8 byte align jitted code, but we 16 byte align small methods. When prejitting we 16 byte align IBC hot methods, and otherwise 4 byte align.
• on x64 we always 8 byte align when jitting and 16 byte align when prejitting 16 byte align.

Haven't looked at arm32 / arm64.

Over-aligning leads to wasted code space; under-aligning leads to possible perf issues ,either poor per or just randomly variable perf, as in #9815.

Generally speaking we'd prefer frequently-called methods to be maximally aligned and rarely called methods be minimally aligned. From a jit standpoint it seems like minopts/debug/tier0 code should always have minimum alignment; tier1 code should have maximum alignment, and the alignment of regularly optimized code is open for discussion.

Also note method entry alignment constrains loop top alignment (#11607).

category:cq
theme:basic-cq
skill-level:expert
cost:large
impact:small

[briansull]

FYI: There might be subtle reasons for some of these choices such as "we 16 byte align small methods" on x86. Because of IP to MethodDesc look ups using a Nibble Map we may not allow more than 1 method per 16-byte region on x86.

[AndyAyersMS]

We are already 16 byte aligning on x64, see notes in dotnet/coreclr#21518.

[AndyAyersMS]

We're now 32 byte aligning Tier1 code, see #2249.

[adamsitnik]

We're now 32 byte aligning Tier1 code, see #2249.

@billwert @DrewScoggins this change might affect microbenchmarks. I hope that it's going to improve both the stability and perf

[kunalspathak]

Also note method entry alignment constrains loop top alignment (#11607).

I believe when you say #11607, you really meant #8108.

[AndyAyersMS]

I believe when you say #11607, you really meant #8108.

Yep. Unfortunately a number of issue links didn't get updated when we migrated from coreclr to runtime repo -- 11607 is the issue number over in coreclr.

[kunalspathak]

With #42909, we align method entries containing loops with 32-bytes.

[DrewScoggins]

This is a query that contains tests that we have seen marked as either regressions or improvements that had bimodal behavior, but after #42909, seemed to have stabilized. We should continue to track these and see if that is true.

https://github.com/DrewScoggins/performance-2/issues?q=is%3Aopen+is%3Aissue+label%3AAlignment

[kunalspathak]

@AndyAyersMS - have you seen example of non-loop methods whose performance was affected because of misalignment? If not, I propose to close the issue.