Why is JIT_MethodAccessAllowedBySecurity taking so

Question

I'm working on a C# application that allows users to basically import tables of data, and then enter their own formulas in a mini-language to compute new columns from the underlying data.

These formulas are compiled into LINQ expression trees in the engine, which the .NET 4.0 expression tree library then presumably compiles into IL so they can be executed.

We've started using our engine for some high-volume ticking data recently, and we're finding the speed of these compiled expression trees to be a real bottleneck - the speed is pretty slow when re-calculating all these columns on the fly. Hitting it with the built-in Visual Studio 2010 profiler reveals half of all our execution time is being spent in clr.dll, in a method called JIT_MethodAccessAllowedBySecurity.

Cursory googling of this string hasn't yielded anything, so I'm wondering if there's anyone out there who can tell me what this method is, and whether there's a way to keep it from eating up all my cycles? Maybe there's a way to compile this code and explicitly give it permission to do whatever it wants so the clr can stop these checks? Perhaps the temporary assemblies being generated by the expression tree engine do not have full trust?

Anyhow, I'm pretty much at a loss and I'm very interested to hear if any other StackOverflow'ers have come across this issue in the past. Thanks in advance!

Answer 1

I think this has something to do with CAS (Code access security).

CAS is assembly based. When you code calls a protected method, the .NET framework runtimes checks your assembly to see if it has been granted on or more permissions necessary for the method. The .NET Framework rutime then walks the stack to check every assembly in the stack for these ermissions. If one assembly does not have all of the required permissions, a securityexception is raised and the code is run.

The below is what I think is happening to your code.

... a stack walk occurs and policy check is preformed every time that the method is called. This is a particular problem for components in a class library, which may be called many times. In this situation, you can use link demand to indicate that the permission set check is performed on at link time as part of the JIT compliction process. To do this, you decorate the method by using a permission attribute that has a parameter of the value SecurityAction.LinkDemand.

I hope this helps, it looks like all you need to do is set the SecurityAction.LinkDemand attribute. The quoted text comes from Advanced foundations of Microsoft .NET 2.0 Development.

Regards

Answer 2

The solution is to use LambdaExpression.CompileToMethod(MethodBuilder method) instead of LambdaExpression.Compile().

I think Jethro was on the right track when he posited that CAS was involved. In testing, the profiler only started showing calls to JIT_MethodAccessAllowedBySecurity when I used expression trees to call functions that weren't dynamically defined in the generated assembly (i.e. using Expression.Call to invoke a library method rather than a piece of generated code.) This suggests that the slowdown was caused by CAS checking that my generated code had access to the methods it was invoking. It seems to follow that by applying declarative security modifications to the functions I wished to call, I could avoid this overhead.

Unfortunately, I wasn't able to get rid of the JIT_MethodAccessAllowedBySecurity overhead through any use of declarative security (PermissionSet, SecurityAction.LinkDemand, and the like). At one point I had literally every method in my project marked with [PermissionSet(SecurityAction.LinkDemand, Unrestricted = true)], with no results.

Luckily, when looking for ways to add attributes to the generated delegates, I stumbled upon the solution - using a MethodBuilder to compile the expression tree rather than the built-in LambdaExpression.Compile method.

I've included the bit of code that replaced .Compile() and led to elimination of the JIT_MethodAccessAllowedBySecurity calls and a >2x speedup in our calculation engine:

// T must be of delegate type (Func<T>, Func<T1, T2>, etc.)
public static T GetCompiledDelegate<T>(Expression<T> expr)
{
    var assemblyName = new AssemblyName("DelegateHostAssembly") { Version = new Version("1.0.0.0") };

    var assemblyBuilder = 
        AppDomain.CurrentDomain.DefineDynamicAssembly(
            assemblyName, 
            AssemblyBuilderAccess.RunAndSave);
    var moduleBuilder = assemblyBuilder.DefineDynamicModule("DelegateHostAssembly", "DelegateHostAssembly.dll");
    var typeBuilder = moduleBuilder.DefineType("DelegateHostAssembly." + "foo", TypeAttributes.Public);
    var methBldr = typeBuilder.DefineMethod("Execute", MethodAttributes.Public | MethodAttributes.Static);

    expr.CompileToMethod(methBldr);

    Type myType = typeBuilder.CreateType();

    var mi = myType.GetMethod("Execute");

    // have to box to object because .NET doesn't allow Delegates as generic constraints,
    // nor does it allow casting of Delegates to generic type variables like "T"
    object foo = Delegate.CreateDelegate(typeof(T), mi);

    return (T)foo;
}

This code is consistently >2x faster when using any code that uses Expression trees to call functions that are not themselves defined by Expression trees. Thanks for everyone's help, and I hope this saves someone else some cycles.