Skip to content

On Stack Replacement Next Steps #33658

Open
@AndyAyersMS

Description

@AndyAyersMS

Possible next steps now that #32969 is merged, in rough order of priority.

Issues and fixes after OSR was enabled

Performance Regressions

Other ideas: enhancements or optimizations

  • Update arm64 to use the same split callee-save technique we now use on x64, and pass Tier0 FP to the OSR method. This gives arm64 methods standard epilogs.
  • Revise Arm64 frame layout to put PSPSym above callee-saves, so that OSR method can share Tier0 PSP, and OSR funclets don't need to pad their frames with the Tier0 frame (see notes starting here) and (more notes). Or, revise the OSR method so it shares the PSP slot with the TIer0 frame (requires split callee-save above). (PSP sym no longer exists: Abolish PSPSym from ABI #114630)
  • look into enabling more independent promotion in OSR methods. Right now we use the Tier0 address exposure data and this is very conservative. Also see JIT: block some struct promotion for OSR #67131.
  • support OSR in methods with stackalloc (see note 2 below) and [further notes]
  • support OSR for reverse pinvoke methods (see note 3 below)
  • support OSR from methods that make explicit tail calls (see note 5 below)
  • implement aggressive frame trimming (reduce original method frame to just live extent)
  • look into viability of backpatching the patchpoint call with a jump to the OSR method instead
  • look into how to support limited Tier0 opts with OSR
  • look into emitting more compact patchpoint code sequences
  • look into emitting more compact patchpoint info blobs
  • think about asynchronous creation of OSR methods
  • look into the feasibility of having one OSR method cover all the patchpoints
  • look into using the "mutator" tool in jitutils to inject loops into methods that don't have them, so that we can trigger OSR in more cases.
    • Note that random patchpoint placement and fast OSR triggers can accomplish something similar without needing to alter tests. There's nothing saying a patchpoint has to be within a loop. JIT: yet another OSR stress mode #62980
  • OSR + GS -- perhaps OSR method should have its own cookie (if needed) in addition to the Tier0 cookie, and check them both on exit? Currently we just check the Tier0 cookie, but if the OSR frame holds saved LR/FP we might miss an overrun. Note: not needed if we move arm64 to the new x64 plan, as there's just one save area that gets restored, and it is in the Tier0 frame.
  • update runtime strategy to support "slow" OSR method creation, but quick transitions when OSR methods exist
  • support for mid-block patchpoints (where IL stack is empty). Among other things, this would let us do "source" patchpoint targeting more often.
  • support for patchpoints at non-stack empty IL offsets. Would require custom per-site patchpoint descriptors and more.
  • defer altering control flow for OSR until much later. Currently we do it very early and need to protect the original method entry specially in case we want to branch there during morph (see JIT: Improve local assertion prop throughput #94597 (comment)).

cc @dotnet/jit-contrib

category:cq
theme:osr
skill-level:expert
cost:extra-large

Metadata

Metadata

Assignees

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions