Runtime: System.Runtime.ProfileOptimization is missing from .NETCore

[ericstj]

I came across some desktop apps that use ProfileOptimization to tune the JIT. Per https://github.com/dotnet/coreclr/issues/18202 we have similar APIs on AssemblyLoadContext. We should redirect ProfileOptimization to those and avoid an unnecessary break unless we have a good reason for not providing Static access to such APIs. /cc @brianrob @jkotas

[brianrob]

The main reason for this is that on .NET Core, you have to know the AssemblyLoadContext as using Multi-Core JIT can trigger assembly loads. This is the reason that the APIs were moved when enabling Multi-Core JIT on .NET Core. It's possible to have an implementation of these static methods that uses the default AssemblyLoadContext if we feel this is improtant enough. I'm open to this - though I would like to understand how we've handled similar situations with differences between .NET Core and .NET Framework so that we can try to be reasonably consistent.

[brianrob]

@noahfalk

[noahfalk]

though I would like to understand how we've handled similar situations with differences between .NET Core and .NET Framework so that we can try to be reasonably consistent.

Unless there is evidence to the contrary I'm happy to assume Eric made the suggestion to be consistent with similar situations already. It seems pretty reasonable to me. Did you have any specific concerns or alternatives in mind? I think the unlikely worst case is the API review comes back saying the PR is no good, and then we pivot to a better approach.

[brianrob]

Nope, no specific concerns.

[MarcoRossignoli]

Is this simply to wrap AssemblyLoadContext.Default.XProfileX in a ProfileOptimization class on System.Runtime namespace(maybe testable with RemoteExecutor)?

[brianrob]

Yes, that's right @MarcoRossignoli.

[MarcoRossignoli]

I could work on it if you want!

[danmosemsft]

@brianrob I'm going to assume you don't see why not? Assigned!

[brianrob]

Sounds great!

[MarcoRossignoli]

@danmosemsft @brianrob ProfileOptimization.cs goes to shared folder(corefx mirror) on coreclr?Can you explain to me when put files on shared?

[brianrob]

Generally, files go into the shared directory when we want to use them across CoreCLR, CoreFX and/or CoreRT. The change you're making to implement this API in CoreCLR should probably just go into the src directory since it isn't needed anywhere in CoreFX and isn't applicable to CoreRT.

[jkotas]

This is applicable to CoreRT as well. We maintain same public surface across between different .NET Core runtimes.

Since this is just a trivial forwarder to another API, I think it can go to https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Extensions/src/System/Runtime .

[MarcoRossignoli]

Since this is just a trivial forwarder to another API, I think it can go to https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Extensions/src/System/Runtime .

no coreclr, right?

[jkotas]

Right