Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Did a couple of runs - with the current Main I always got 44k jump stubs in every single run of the benchmark. With this PR it's mostly 0, got 271 at some run.

Hm.. however this PR might regress Managed-to-managed calls if both calls are not withing reach but next to each others. Probably still better than emitting jump-stubs for literally all VMs helpers such as allocators.

So a better fix (as was on arm) is to rewrite Code manager to know the exact place in memory current code will be saved to.
Although, it doesn't seem painful on x64 to use direct addresses... a single instruction to populate it.

Probably still better than emitting jump-stubs for literally all VMs helpers such as allocators.

How does mov rax, XXXXX + call rax sequence work with call target predictor in current CPUs?

IIRC, this sequence consumed precious slots in call target predictor back in the day and going through jump stubs was faster in real workloads since it was better predicted. (Also, the smaller code helps too - instruction caches are often bottleneck in .NET workload since the code is too big.)

@jkotas I've just pushed a change to limit this to Dynamic methods like you suggested in #62302 (comment)

It lowers number of jump-stubs generated from 44k to ~4k every benchmark launch.

However, it relies on a more precise getRelocTypeHint then it's now. But probably still better than what it ends up now - emitting jump-stubs for small temp dynamic methods?

IIRC, this sequence consumed precious slots in call target predictor back in the day and going through jump stubs was faster in real workloads since it was better predicted.

Reminds me this issue on Apple M1: https://twitter.com/dougallj/status/1580826539205496832 🙂

But probably still better than what it ends up now - emitting jump-stubs for small temp dynamic methods?

I expect that it will regress small workloads with dynamic methods.

The current scheme used by the JIT/EE interface is to assume that everything fits into Rel32. Once we hit one situation that does not fit, we will redo JITing of that method and stop returning IMAGE_REL_BASED_REL32 from getRelocTypeHint from then on. It allows small workloads to get full rel32 benefit, and only large workloads with gigabytes of code to pay the overhead.

I think it would be best to extend the current scheme to handle the dynamic jumpstub case.

Once we hit one situation that does not fit, we will redo JITing of that method and stop returning IMAGE_REL_BASED_REL32

Isn't it a rare event and is not supposed to happen normally for small apps?
Btw, if a method reports "I fit into rel32" but it turns out to be not - a jump stub is emitted but the global REl32 is not turned off. My understanding that we stop using REL32 globally once e.g. a memory load doesn't fit

Isn't it a rare event and is not supposed to happen normally for small apps?

Right, it is not supposed to happen for normal apps.

if a method reports "I fit into rel32" but it turns out to be not - a jump stub is emitted but the global REl32 is not turned off.

Right. I am suggesting to change the "a jump stub is emitted" part into "if it is a dynamic method { set a global flag that says to use inlinine call targets for dynamic methods and redo the method } else { a jump stub is emitted }".

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.