Tagging subscribers to this area: @agocke, @jeffschwMSFT, @elinor-fung
See info in area-owners.md if you want to be subscribed.

Please have @elinor-fung look at this

What has your testing workflow been @pavelsavara?

So, I'm thinking, what's the current R2R inner dev loop for your team, when you test R2R for windows or iOS ? The VM requesting R2R image would be similar to that, just not dlopen. What is the call stack for loading R2R image on windows ? How can I try ? What command lines you use to build and run it ?

I suggest that I could implement loading of R2R.wasm into corerun in next PR, if corerun is the way ... I will need a sample of R2R.wasm file and a sample app that wants to load it.

I haven't done any testing of R2R so far for windows or ios and so I don't have as much context there. However, it sounds like automated tests are generally executed with corerun so that may also point to corerun being what we want to use here. I believe on windows you can execute an R2R image output from crossgen directly with dotnet or with a locally built corerun, if the image has an entrypoint!

If we implement support in corerun, would we then be able to do something like, node /my/build/corerun.js my-r2r-app.wasm? That's assuming the app has an entry point already. That would be a very nice and simple dev loop! Do you have any pointers on what a sample app might look like here? I am truly thinking of simple, self-contained test assemblies for executing basic generated code, i.e.,

// No external dependencies besides corlib
class WasmTest 
{
  public static void Main()
  {
     CodegenTestEntrypoint();
  }
}

something like, node /my/build/corerun.js my-r2r-app.wasm?

In corerun, we don't have the implementation of external_assembly_probe yet and for loading R2R it would be necessary.
Because it needs to be loaded by the "JS host into JS VM" rather than by "dotnet process into WASM linear memory".
I think should do it, but it is out of scope of this PR, which only matches the Mono functionality.

That said, is there more feedback for this PR ?

In corerun, we don't have the implementation of external_assembly_probe yet and for loading R2R it would be necessary. Because it needs to be loaded by the "JS host into JS VM" rather than by "dotnet process into WASM linear memory". I think should do it, but it is out of scope of this PR, which only matches the Mono functionality.

That said, is there more feedback for this PR ?

Definitely agreed that it is out of scope for this PR! I was mostly just wanting to understand what direction we are heading in on the host loading side and what work is still required, so I appreciate the clarification here. I don't have any more feedback, and I think this looks good for now as a start! Since I have limited expertise in this area though, it would be great if @elinor-fung could take a look before this goes in.

it would be great if @elinor-fung could take a look before this goes in.

As we are waiting for more feedback on native part, I split of JS part, for which I'm pretty confident into #124758 and will merge that first.