Capability APIs for runtime code generation

[morganbr]

We believe we need to add reflection emit to .NET Standard.

We already have features in .NET Standard that imply support for dynamic code generation, for example Assembly.Load(byte[]), RegexOptions.Compiled, and LambdaExpression.Compile().

Today, developers have no way to test whether runtime code generation is actually supported -- the runtime might throw PlatformNotSupported. Furthermore, even if it is supported, it might be slower as the runtime is interpreting the code (for example, by walking the expressions trees or interpreting the IL). While that ensures that scenarios that depend on code generation just work, it makes it hard to support scenarios that use code generation as a performance optimization. In those cases, not using code generation is usually faster.

Hence, we need an API that allows developers to check for the support of code generation as well as an API that allows developers to check using runtime code generation as a performance optimization is sensible.

API Proposal

namespace System.Runtime.CompilerServices
{
    public static class RuntimeFeature
    {
        public static bool IsDynamicCodeSupported { get; }
        public static bool IsDynamicCodeCompiled { get; }
    }
}

The semantics are:

• If the runtime supports loading and running dynamic code, IsDynamicCodeSupported returns true. This doesn't tell developers whether the code is interpreted or compiled.
• If the runtime supports loading and running dynamic code by using a just-in-time compiler, IsDynamicCodeCompiled returns true.
• RuntimeFeature.IsSupported(string) also returns the appropriate value when called with the strings "IsDynamicCodeSupported" and "IsDynamicCodeCompiled".

Affected features

• Loading assemblies from bytes (Assembly.Load(byte[]))
• Linq expression trees
• Reflection emit
• DynamicMethod (lightweight code generation, LCG)
• DispatchProxy
• Regex

Scenarios

Failing early with RuntimeFeature.IsDynamicCodeSupported

In some scenarios, performance isn't the primary goal but use to get stuff to work, for example, mocking. A mocking framework might provide an API like Proxy.Create<TInterface>() that returns you a type that implements TInterface. In this case, performance isn't the higher order and the only thing that matters is that the runtime supports generating code on the fly. Some environments, for example, iOS, disallow actual JITs. For that reason, the Xamarin team is considering providing an IL interpreter to make the scenarios work.

The author of the mocking framework could just use reflection emit and rely on the implementation of it to throw PlatformNotSupported but a much better developer experience would be to check early & fail early with a descriptive error message. For example:

public static class Proxy
{
    public static Proxy<TInterface> Create<TInterface>()
    {
        if (!RuntimeFeature.IsDynamicCodeSupported)
            throw new PlatformNotSupportedException("We cannot create proxies on your runtime because it doesn't allow dynamic code generation.");

        return UseReflectionEmitToCreateImplementation();
    }
}

Accelerating using RuntimeFeature.IsDynamicCodeCompiled

In most cases, dynamically generating code is meant as a performance optimization. This

var options = RegexOptions.IgnoreCase | RegexOptions.Singleline;

// We only want to use compiled regexes if the underlying runtime
// supports compiling IL with a JIT. Otherwise it's likely much slower
// than walking the state machine.

if (RuntimeFeature.IsDynamicCodeCompiled)
{
    options |= RegexOptions.Compiled;
}

Similar areas include using expression trees to accelerate setting properties and calling constructors in IoC systems.

[jkotas]

We have duplicate issues of this:

https://github.com/dotnet/corefx/issues/13535
https://github.com/dotnet/corefx/issues/25530

The preferred design for API availability checks in earlier discussions was to just add static IsSupported property to the relevant API, like AssemblyBuilder.IsSupported, DynamicMethod.IsSupported or Registry.IsSupported. This pattern scalles well to 3rd party APIs.

RuntimeFeature.HasJit makes sense to me.

[morganbr]

The IsSupported pattern would make this proposal look like this (with an IsSupported method for all entrypoint classes for reflection emit). What do folks think?

namespace System.Runtime.CompilerServices
{
    public class RuntimeFeature
    {
        public static bool HasJit { get; }
    }
}

namespace System.Reflection.Emit
{
    public class AssemblyBuilder
    {
        public static bool IsSupported { get; }
    }

    public class DynamicMethod
    {
        public static bool IsSupported { get; }
    }

    public class CustomAttributeBuilder
    {
        public static bool IsSupported { get; }
    }
}

[jkotas]

LGTM.

I am not sure whether we need CustomAttributeBuilder.IsSupported. Can CustomAttributeBuilder be ever meaningfully used without AssemblyBuilder?

[morganbr]

We could probably do without CustomAttributeBuilder.IsSupported. On closer inspection, the only thing it does by itself is build a binary representation of the custom attribute. While it's not in CoreRT right now, it could be as long as we drop the internal methods used by other parts of reflection emit.

After a bit of digging, we could potentially need more IsSupported APIs to cover downstream usage refemit. For example, Regex and System.Composition have APIs that depend on it. Would we want some sort of support check on those as well?

[morganbr]

CC @davidfowl, who could hopefully use this in ASP.NET.

[jkotas]

Yes, I think having a property like bool Regex.IsCompiledSupported would make sense.

[davidfowl]

We should walk through the flow chart on what this would look like for our DI container. Today we have a couple of different modes (https://github.com/aspnet/DependencyInjection/blob/943ffa1187399ad4c2af0d23641af9804eacd4e6/src/DI/ServiceProviderMode.cs#L6):

• Dynamic - Use reflection the first 2 times somebody asks to resolve a service, then switch then compile it in the background after that using the most efficient method (Ref Emit, or Compiled expressions)
• Runtime - Always use reflection when resolving services
• Expressions - Compile the expression tree before resolving service
• ILEmit - Compile a dynamic method before resolving service

Here's what I'm thinking the flow control would be:

// Set the default mode to runtime if there's no JIT
https://github.com/aspnet/DependencyInjection/blob/06e2de235ce5b27b425e823d9dcbd045811ba48e/src/DI/ServiceProviderOptions.cs#L21

Mode = RuntimeFeature.HasJit ? ServiceProviderMode.Dynamic : ServiceProviderMode.Runtime;

https://github.com/aspnet/DependencyInjection/blob/06e2de235ce5b27b425e823d9dcbd045811ba48e/src/DI/ServiceLookup/ServiceProviderEngine.cs#L23

// This name should be CompiledBuilder
ExpressionBuilder = DynamicMethod.IsSupported ? new ILEmitResolver(...) : new CallSiteExpressionBuilder(...);

/cc @pakrym for DI
/cc @JamesNK (he originally asked for this) for JSON.NET

[morganbr]

@davidfowl, now that I think about it a bit more, is DynamicMethod.IsSupported useful or should we only have RuntimeFeatures.HasJit? In other words if refemit is interpreted, would you ever want to use it?

[davidfowl]

@davidfowl, now that I think about it a bit more, is DynamicMethod.IsSupported useful or should we only have RuntimeFeatures.HasJit? In other words if refemit is interpreted, would you ever want to use it?

No we'd never want to use it if it was interpreted in this scenario unless it was faster than reflection.

[JamesNK]

I want a way to figure out the fastest way to do reflection.

Compiled expressions are faster than traditional MethodInfo.Invoke reflection
But MethodInfo.Invoke reflection is faster that interpreted expressions.

A runtime way to figure out which to choose out of the two - basically are expressions going to be compiled or interpreted - is what I want.

[morganbr]

Ok, let's just go with RuntimeFeatures.HasJit until/unless we see a useful scenario for using RefEmit with no JIT.

[morganbr]

I incorrectly thought RuntimeFeatures was public. Would System.Runtime.InteropServices.RuntimeInformation be the right public class @stephentoub?