Haibo Luo's weblog : DynamicMethod

Late-bound Array SetValue

Haibo_Luo — Mon, 27 Nov 2006 08:04:00 GMT

The type "System.Array" provides us a set of API for the late-bound array operations, including array creation (Array.CreateInstance), read/write access to array element (Array.SetValue/Array.GetValue). They are convenient to use. Let me start with some code to create an one-dimensional integer array, and set the first 2 elements using early-bind assignment and Array.SetValue, respectively. To simplify my code, this post will only touch the late-bound set value on array (the similar discussion can be applied to get value).

// creation: new int[5]
Array x = Array.CreateInstance(typeof(int), 5);

// 0. early-bind set: explicit cast to int[]
int[] y = (int[])x;
y[0] = 100;

// 1. late-bound set via Array.SetValue
x.SetValue(200, 1);

From the signature of Array.SetValue(object, int), we know that the integer "200" has to be boxed first before passing into this API, which is a performance hit (among others). However, we can take a look at what kind of IL sequence C# compiler generates for the early-bound assignment, and build an equivalent dynamic method to avoid the boxing: C# compiler emits Stelem.I4 to store the 32-bit integer value.

// 2. late-bound set via DynamicMethod/Delegate/OpCodes.Stelem
DynamicMethod dm = new DynamicMethod("SetValueByStelem", typeof(void),
new Type[] { typeof(Array), typeof(int), typeof(int) }, typeof(Test));
ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_0);
ilgen.Emit(OpCodes.Castclass, x.GetType());
ilgen.Emit(OpCodes.Ldarg_1); // index
ilgen.Emit(OpCodes.Ldarg_2); // value
ilgen.Emit(OpCodes.Stelem_I4);
ilgen.Emit(OpCodes.Ret);
MySetValue sv = (MySetValue)dm.CreateDelegate(typeof(MySetValue));

sv(x, 2, 300);

delegate void MySetValue(Array array, int index, int value);

The runtime (so is System.Array) supports non-zero lowerbound array (C# does not). The code snippet below creates a length-of-5 integer array with -3 as its' lower-bound, and then tries to set value for some elements.

We can no longer cast such array to int[].
Array.SetValue works. Note we need use the lowerbound value to access the first element.
The instructions "stelem/stelem.<type>" are for one dimensional array with zero-based index only. So the dynamic method approach with stelem instruction won't work.
For each concrete array type, runtime adds three special methods: Get/Set/Address. With reflection we can hold those MethodInfo, so you can call MethodInfo.Invoke or create another dynamic method wrapper around it. This works for zero-based array too.

// creation: new int[-3..1]
Array x = Array.CreateInstance(typeof(int), new int[] { 5 }, new int[] { -3 });

// 1. late-bound set via Array.SetValue
x.SetValue(200, 1 - 3);

// 3. late-bound set via MethodInfo.Invoke of "Set"
MethodInfo mi = x.GetType().GetMethod("Set");
mi.Invoke(x, new object[] { 3 - 3, 400 });

// 4. late-bound set via DynamicMethod/Delegate/"Set"
DynamicMethod dm = new DynamicMethod("SetValueBySet", typeof(void),
new Type[] { typeof(Array), typeof(int), typeof(int) }, typeof(Test));

ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_0);
ilgen.Emit(OpCodes.Castclass, x.GetType());
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Ldarg_2);
ilgen.Emit(OpCodes.Call, mi);
ilgen.Emit(OpCodes.Ret);

MySetValue sv = (MySetValue)dm.CreateDelegate(typeof(MySetValue));
sv(x, 4 - 3, 500);

Using Vance's CodeTimers class, I measured these 5 approaches' performance on my Vista machine. My scenario is to set value on 1-dimensional zero-based integer array, the action loop contains 10 lines of set-value code (those dynamic method and delegate creation are prepared ahead). The fastest late-bound set approach is DynamicMethod with Stelem, about 90-times slower than the early-bound assignment; but it is 3-times faster than Array.SetValue. Here is the raw output:

Data units of msec resolution = 0.279365 usec
Early-bound assignment : count: 1000000 4.525 +- 1% msec
Late-bound set via Array.SetValue : count: 1000000 1138.182 +- 2% msec
Late-bound set via DynamicMethod/Stelem : count: 1000000 397.005 +- 0% msec
Late-bound set via Set MethodInfo.Invoke: count: 1000000 36352.360 +- 0% msec
Late-bound set via DynamicMethod/Set : count: 1000000 453.956 +- 7% msec

What about multi-dimensional array? Array.SetValue still works; for better performance, we might want use the special "Set" method. By the way, the following ildasm output shows what C# compiler generates for "array[0, 1] = 1000;", which uses "Set". Note "int32[0..., 0...]" is TypeSpec(0x1B).

IL_0009: ldloc.0
IL_000a: ldc.i4.0
IL_000b: ldc.i4.1
IL_000c: ldc.i4 0x3e8
IL_0011: call instance void int32[0...,0...]/* 1B000003 */::Set(int32, int32, int32) /* 0A000020 */

Take Two: IL Visualizer

Haibo_Luo — Fri, 17 Nov 2006 03:55:00 GMT

I was glad to hear many positive feedbacks about the DebuggerVisualizer for DynamicMethod; on the sad side, it shows our lack of good LCG debugging support (on which, Mike Stall is seeking your opinion).

Recently along with the ILReader update, I made a few changes on the visualizer:

Add support to show IL of RuntimeMethodInfo and RuntimeConstructorInfo (besides DynamicMethod). Actually Roy already had a version providing such functionality. Last year, I wanted to enable viewing IL on all MethodBase-derived types. Well, my daily duty and interests changed; I am afraid I won't ever meet that goal.
Add support to show IL of Delegate.MethodInfo, where the delegate might be created from DynamicMethod.
Simplify IL Visualizer UI. When the DynamicMethod IL code is incomplete, those branch instructions' label shown inside the visualizer could be incorrect. However it is easy to identify this fixup failure: they always branch to the next instruction. I removed the label-fix-succeed-failed information as well as the font ComboBox at the bottom of the dialog. Now changing the font is done by the RichTextBox's context menu.
Add another way to view IL: "Send to IL Monitor". DebuggerVisualizer dialog is a modal dialog, which means we have to dismiss it first to continue anything with Visual Studio. I found this is inconvenient when trying to track the whole code-gen process. You can now choose "Send to IL Monitor". Before clicking it, a separate application "ilmonitor.exe" need to be started first. Those IL information is sent to this application with TCP socket (and the listening port number is hard-coded as 22017). For one dynamic method, if we click the magnifying glass "Send to IL Monitor" button a couple of times at different code-gen stages, the same window will show the growing IL with different background colors. As you see from the pictures below, it can also track many dynamic methods' IL.

You may download the attachment and try to build the solutions in your VS. The images below were captured in my Vista box.

Disclaimer: THE CODE IS PROVIDED "AS IS", WITH NO WARRANTIES INTENDED OR IMPLIED. USE AT YOUR OWN RISK.

update (3/7/2008): VS2008 solution can be found at http://blogs.msdn.com/haibo_luo/archive/2008/03/07/8107924.aspx.

Turn MethodInfo to DynamicMethod

Haibo_Luo — Wed, 08 Nov 2006 01:13:00 GMT

I do not know why anyone ever need this :) but few readers did ask me similar questions before. Solving this problem also demonstrates one more ILReader usage.

To build a DynamicMethod, we can choose either DynamicILGenerator or DynamicILInfo. My first impression of using DynamicILGenerator to emit code is slow: you need make calls to emit ILs instruction by instruction. Actually this approach is more difficult, a topic for future post. I already wrote a post about DynamicILInfo. I do not know the motivation behind the DynamicILInfo class (at that time I was not in the CLR team), but I heard this was a feature request from SQL.

To turn a MethodInfo to DynamicMethod, we can not simply call SetCode with the byte array returned by the static method body's GetILAsByteArray. Those tokens (if any) are metadata tokens, meaningful only in the scope of the module where that static method lives. The DynamicILInfo.GetTokenFor overloads are designed to build the relationship between an integer number (the new "token") and the runtime member (type, method, field, string, or signature...) in the scope of the dynamic method. We can first make a copy of the static method's IL byte array, and overwrite the old metadata token with the new token from GetTokenFor for each applicable IL instruction. So here comes ILInfoGetTokenVisitor. As you see, we override 6 visit methods in ILInfoGetTokenVisitor, doing the token replacements; the top-level code to prepare new code array looks simple.

class ILInfoGetTokenVisitor : ILInstructionVisitor {
private DynamicILInfo ilInfo;
private byte[] code;

public ILInfoGetTokenVisitor(DynamicILInfo ilinfo, byte[] code) {
this.ilInfo = ilinfo;
this.code = code;
}

public override void VisitInlineMethodInstruction(InlineMethodInstruction inlineMethodInstruction) {
OverwriteInt32(ilInfo.GetTokenFor(inlineMethodInstruction.Method.MethodHandle,
inlineMethodInstruction.Method.DeclaringType.TypeHandle),
inlineMethodInstruction.Offset + inlineMethodInstruction.OpCode.Size);
}
public override void VisitInlineFieldInstruction(InlineFieldInstruction inlineFieldInstruction) { ... }
public override void VisitInlineSigInstruction(InlineSigInstruction inlineSigInstruction) { ... }
public override void VisitInlineStringInstruction(InlineStringInstruction inlineStringInstruction) { ... }
public override void VisitInlineTokInstruction(InlineTokInstruction inlineTokInstruction) { ... }
public override void VisitInlineTypeInstruction(InlineTypeInstruction inlineTypeInstruction) { ... }
...
}

private static void SetCode(MethodInfo method, MethodBody body, DynamicILInfo ilInfo) {
byte[] code = body.GetILAsByteArray();
ILReader reader = new ILReader(method);
ILInfoGetTokenVisitor visitor = new ILInfoGetTokenVisitor(ilInfo, code);
reader.Accept(visitor);

ilInfo.SetCode(code, body.MaxStackSize);
}

JAY was asking how to set exceptions. Reflection does not provide API to return the exception blob directly, instead the exception information is exposed through the MethodBody.ExceptionHandlingClauses property. With this ExceptionHandlingClause list, we can follow the format described by Ecma 335 (Part 2, 25.4.5 and 25.4.6) and build the exception blob from scratch. To avoid worrying about the restriction of the small version of exception handling clauses, the exception array generated below is with the fat form layout. See some comments inside the code.

private static void SetExceptions(MethodBody body, DynamicILInfo ilInfo) {
IList<ExceptionHandlingClause> ehcs = body.ExceptionHandlingClauses;
int ehCount = ehcs.Count;
if (ehCount == 0) return;

// Let us do FAT exception header
int size = 4 + 24 * ehCount;
byte[] exceptions = new byte[size];

exceptions[0] = 0x01 | 0x40; //Offset: 0, Kind: CorILMethod_Sect_EHTable | CorILMethod_Sect_FatFormat
OverwriteInt32(size, 1, exceptions); // Offset: 1, DataSize: n * 24 + 4

int pos = 4;
foreach (ExceptionHandlingClause ehc in ehcs) {
// Flags, TryOffset, TryLength, HandlerOffset, HandlerLength: all size 4
OverwriteInt32((int)ehc.Flags, pos, exceptions); pos += 4;
OverwriteInt32(ehc.TryOffset, pos, exceptions); pos += 4;
OverwriteInt32(ehc.TryLength, pos, exceptions); pos += 4;
OverwriteInt32(ehc.HandlerOffset, pos, exceptions); pos += 4;
OverwriteInt32(ehc.HandlerLength, pos, exceptions); pos += 4;

// ClassToken or FilterOffset
switch (ehc.Flags) {
case ExceptionHandlingClauseOptions.Clause:
int token = ilInfo.GetTokenFor(ehc.CatchType.TypeHandle);
OverwriteInt32(token, pos, exceptions);
break;
case ExceptionHandlingClauseOptions.Filter:
OverwriteInt32(ehc.FilterOffset, pos, exceptions);
break;
case ExceptionHandlingClauseOptions.Fault:
throw new NotSupportedException("dynamic method does not support fault clause");
case ExceptionHandlingClauseOptions.Finally:
break;
}
pos += 4;
}

ilInfo.SetExceptions(exceptions);
}

If you are interested in the details, you may download the attachment and read the whole source code closely.

A related question is how to build a dynamic method from other sources. DynamicMethod is not Serializable, .NET framework built-in serializing/deserializing support will not work. One approach I can think of is to preserve the code array, the members/strings/... (in order to call GetTokenFor to get new tokens) used and their matching offsets (with one scan of the ILs). MethodInfo, FieldInfo, Type are marked "Serializable", but not sure whether this is the right way to save/restore those members. If the method handles exception, we can save the pre-calculated exception blob, and remember where we need replace token for what exception type.

Finally, let us play with the turn-static-method-to-dynamic-method call, and show off some IronPython code. The first 3 lines bring in the DynamicMethodHelper class. Then we use Reflection to get DateTime.get_Now's MethodInfo (sGetNow), and convert it to DynamicMethod (dGetNow) with "DynamicMethodHelper.ConvertFrom". The last part of the code is interesting: it converts the method "DynamicMethodHelper.ConvertFrom" to DynamicMethod (dConvert), and use that dynamic method (dConvert) to convert sGetNow to another dynamic method (dGetNow2). Just fyi: DateTime.get_Now has 5 instructions, DynamicMethodHelper.ConvertFrom has ~80 instructions and exception handlings clauses.

>>> import clr, System
>>> clr.AddReference('ClrTest.Reflection.DynamicMethodHelper.dll')
>>> from ClrTest.Reflection import *
>>>
>>> clr.GetClrType(System.DateTime).GetMethod("get_Now")
<System.Reflection.RuntimeMethodInfo object at 0x000000000000002B [System.DateTime get_Now()]>
>>> sGetNow = _
>>> DynamicMethodHelper.ConvertFrom(sGetNow)
<System.Reflection.Emit.DynamicMethod object at 0x000000000000002C [System.DateTime get_Now()]>
>>> dGetNow = _
>>> dGetNow.Invoke(None, None)
<System.DateTime object at 0x000000000000002D [11/7/2006 11:40:49 AM]>
>>>
>>> clr.GetClrType(DynamicMethodHelper).GetMethod("ConvertFrom")
<System.Reflection.RuntimeMethodInfo object at 0x000000000000002E [System.Reflection.Emit.DynamicMethod ConvertFrom(System.Reflection.MethodInfo)]>
>>> sConvert = _
>>> DynamicMethodHelper.ConvertFrom(sConvert)
<System.Reflection.Emit.DynamicMethod object at 0x000000000000002F [System.Reflection.Emit.DynamicMethod ConvertFrom(System.Reflection.MethodInfo)]>
>>> dConvert = _
>>>
>>> dConvert.Invoke(None, System.Array[object]([sGetNow]))
<System.Reflection.Emit.DynamicMethod object at 0x0000000000000030 [System.DateTime get_Now()]>
>>> dGetNow2 = _
>>> dGetNow2.Invoke(None, None)
<System.DateTime object at 0x0000000000000031 [11/7/2006 11:40:59 AM]>
>>>

System.Reflection-based ILReader

Haibo_Luo — Mon, 06 Nov 2006 23:02:00 GMT

Compared to what I posted previously here (or what was used in the DynamicMethod visualizer), this new version introduced the Visitor pattern.

A do-nothing visitor ILInstructionVisitor is included; the users can focus on their domain-specific logic by simply inheriting from it and overriding few methods.

public abstract class ILInstructionVisitor {
    public virtual void VisitInlineBrTargetInstruction(InlineBrTargetInstruction inlineBrTargetInstruction) { }
    public virtual void VisitInlineFieldInstruction(InlineFieldInstruction inlineFieldInstruction) { }
    ...
}

The abstract class ILInstruction now has an abstract method "Accept"; each derived ILInstruction class provides the override "Accept" method, which dispatches the call to ILInstructionVisitor's corresponding visit method. It saves a long switch statement when an ILInstruction is about to be processed.
The class ILReader has a shortcut to traverse all IL instructions: the instance method "Accept".

Class ILReader has 2 overload constructors. There are many mscorlib types derived from MethodBase (see the picture at the right side, from Reflector); only RuntimeMethodInfo or RuntimeConstructorInfo instance is supposed to pass into the first constructor. Internally it uses MethodBase.GetMethodBody and token resolution APIs from System.Reflection.Module. DynamicMethod does not provide public APIs to access the method body, nor the token resolution APIs. IILProvider and ITokenResolver are designed for easy plug-in of other IL Streams. If you are familar with the DynamicMethod visualizer source code, you already know, for tool authoring purpose, we could use Reflection to reflect some private members (which so depends on the implementation details, and could be likely broken in the future runtime version), and then come up dynamic method related classes (which implement both interfaces). We could figure out how Reflection.Emit manages those tokens at the bake time, but I have not gotten enough time on solving it.

public ILReader(MethodBase method);
public ILReader(IILProvider ilProvider, ITokenResolver tokenResolver);

Let us check out how we can build something "useful" with the ILReader. Instead of demo'ing with C# code, I'd like to write some Python code here (well, to promote IronPython ...).

The first IronPython code examines which System.String's public methods could throw ArgumentOutOfRangeException directly. For that, I can write a ILInstructionVisitor-derived class ThrowExceptionHunter, having one override method VisitInlineMethodInstruction, which checks whether the instructions's operand "Method" belongs to one of ArgumentOutOfRangeException's constructors. In order to stop hunting after hitting the ArgumentOutOfRangeException constructor, I need write a tailored loop, instead of using ILReader.Accept. From the output, we see 11 methods could throw ArgumentOutOfRangeException "directly", and they always call the constructor which requires 2 string arguments (i.e., paramName, message);

class ThrowExceptionHunter(ILInstructionVisitor):
    def __init__(self, method, exceptionType):
        self.method = method
        self.ctors = exceptionType.GetConstructors()
        self.found = False
    def VisitInlineMethodInstruction(self, instruction):
        if instruction.Method in self.ctors:
            print instruction.Method, '|', self.method
            self.found = True

clrStringType = clr.GetClrType(System.String)
exceptionType = clr.GetClrType(System.ArgumentOutOfRangeException)
for method in clrStringType.GetMethods():
    h = ThrowExceptionHunter(method, exceptionType)
    for il in ILReader(method):
        il.Accept(h)
        if h.found: break

Output:
Void .ctor(System.String, System.String) | System.String Join(System.String, System.String[], Int32, Int32)
...
Void .ctor(System.String, System.String) | System.String Remove(Int32)

Next visitor is to find callees (methods called by the current method). Early-bind method calls happen with either InlineMethodInstruction or InlineSigInstruction. Suppose you unlikely write code using "calli", only one ILInstructionVisitor method need to be overridden: to put the called method together into a python set (therefore there is no duplicate). The results shows String.StartsWith(String, StringComparison) internally used 10 different methods (including constructor call, property access).

class CalleeFinderNoDup(ILInstructionVisitor):
    def __init__(self):
        self.callees = set()
    def VisitInlineMethodInstruction(self, instruction):
        self.callees.add(instruction.Method)

method = clrStringType.GetMethod('StartsWith', System.Array[System.Type]([str, System.StringComparison]))
reader = ILReader(method)

v = CalleeFinderNoDup()
reader.Accept(v)
print 'How many:', len(v.callees)
for x in v.callees:
    print x, '/', x.DeclaringType

Output:
How many: 10
Void .ctor(System.String) / System.ArgumentNullException
...
Int32 CompareOrdinalIgnoreCaseEx(System.String, Int32, System.String, Int32, Int32) / System.Globalization.TextInfo

We can think of many scenarios related to IL code disassembly; the attached ILReader library provides 2 visitors for that purpose: ReadableILStringVisitor and RawILStringVisitor. Along the visit, we pass in IILStringCollector. ReadableILStringToTextWriter, which implements IILStringCollector, can be used to dump the readable IL string to the specified TextWriter (shown below). We can write customized ILStringCollectors to collect those IL strings in other manners.

v = ReadableILStringVisitor(ReadableILStringToTextWriter(System.Console.Out))
reader.Accept(v)

Output:
IL_0000: ldarg.1
IL_0001: brtrue.s IL_000e
IL_0003: ldstr "value"
IL_0008: newobj Void .ctor(System.String)/System.ArgumentNullException
IL_000d: throw
...
IL_00f7: call System.String GetResourceString(System.String)/System.Environment
IL_00fc: ldstr "comparisonType"
IL_0101: newobj Void .ctor(System.String, System.String)/System.ArgumentException
IL_0106: throw

By the way, you may think those method names inside the ILInstructionVisitor class are way too long - they all can simply be named "Visit". I agree, actually that was my first try; however to be dynamic language friendly, I renamed them by adding the matching instruction class name. When all methods are named "Visit", static language compiler (like C#) can still decide which method to bind based on the parameter type, while IronPython has to surrender itself to classes derived from such visitor: If we wrote one customized "Visit" method for ThrowExceptionHunter, which base "Visit" method is supposed to override? If you need to override several "Visit" methods from ILInstructionVisitor, there is no way to implement it in Python - defining any amount of "Visit" methods only keeps the last one alive.

TryILReader.py can be viewed here.

More tools (and discussion) related to this ILReader coming soon. Hope one day this could become System.Reflection.ILReader ...

Disclaimer: THE CODE IS PROVIDED "AS IS", WITH NO WARRANTIES INTENDED OR IMPLIED. USE AT YOUR OWN RISK

Always Peverify IL Code of your Dynamic Method

Haibo_Luo — Wed, 01 Nov 2006 07:39:00 GMT

Current dynamic method implementation does not have built-in support to pre-check whether the dynamic method code is verifiable. With bad IL sequence, very often you will get "System.InvalidProgramException: Common Language Runtime detected an invalid program" when it gets executed. See the code example below, where C1, C2 are 2 simple reference types. Btw I understand only me write such "fun" IL code.

LocalBuilder lb = ilgen.DeclareLocal(typeof(C2));
ilgen.Emit(OpCodes.Newobj, typeof(C1).GetConstructor(Type.EmptyTypes));
ilgen.Emit(OpCodes.Stloc_0, lb);
ilgen.Emit(OpCodes.Ldc_I4_0);
ilgen.EmitWriteLine("I got called");
ilgen.Emit(OpCodes.Ret);

Even if you did not get InvalidProgramException, it does not mean the code-gen is correct. When the following code get invoked, "I got called too" will be printed; but the code is not verifiable. When the SkipVerification permission is refused, executing this dynamic method causes JIT to verify first: "System.Security.VerficationException: Operation could destabilize the runtime" throws.

LocalBuilder lb = ilgen.DeclareLocal(typeof(C2));
ilgen.Emit(OpCodes.Newobj, typeof(C1).GetConstructor(Type.EmptyTypes));
ilgen.Emit(OpCodes.Stloc_0, lb);
ilgen.EmitWriteLine("I got called too");
ilgen.Emit(OpCodes.Ret);

However both exception messages contain no much useful information: they do not tell which instruction could be blamed. For any production code using DynamicMethod, to ensure the code-gen quality, it is a good practice to have another implementation which have Reflection.Emit to emit the same IL code to disk, and call Peverify.exe to verify it. IronPython's code-gen has both approaches: at the beginning when we enforced this check, we caught several code-gen issues. This is what peverify.exe shows for the 2 scenarios above:

[IL]: Error: [D:\snippets.dll : Sample::M][offset 0x00000005][found ref 'C1'][expected ref 'C2'] Unexpected type on the stack.
[IL]: Error: [D:\snippets.dll : Sample::M][offset 0x00000011] Stack must be empty on return from a void function.
----
[IL]: Error: [D:\snippets.dll : Sample::M][offset 0x00000005][found ref 'C1'][expected ref 'C2'] Unexpected type on the stack.

ILGenerator.EmitCall Mainly For vararg Methods

Haibo_Luo — Mon, 14 Aug 2006 02:18:00 GMT

Vararg (variable arguments) methods accept argument lists of unknown length and type. CLR supports this by the IL instruction (arglist) and other BCL types, such as System.ArgIterator. C# compiler has undocumented keyword "__arglist" to support defining vararg methods, accessing variable arguments and calling them, as shown below.

static void VarargMethod(string headline, __arglist) {
ArgIterator ai = new ArgIterator(__arglist);

Console.Write(headline);
while (ai.GetRemainingCount() > 0)
Console.Write(TypedReference.ToObject(ai.GetNextArg()));
Console.WriteLine();
}

static void CallVarargMethod() {
VarargMethod("Hello world from ", __arglist(Assembly.GetExecutingAssembly()));
VarargMethod("Current time: ", __arglist(DateTime.Now, " (UTC ", DateTime.UtcNow, ")"));
}

Two MemberRef tokens are needed to specify each vararg method call site. The blob each MemberRef points to specifies the methodref signature: types of both fixed and variable arguments.

MethodName: VarargMethod (06000001)
MemberRef #1 (0a00000c)
2 Arguments
Argument #1: String
Argument #2: <ELEMENT_TYPE_SENTINEL> Class System.Reflection.Assembly
MemberRef #2 (0a00000f)
5 Arguments
Argument #1: String
Argument #2: <ELEMENT_TYPE_SENTINEL> ValueClass System.DateTime
Argument #3: String
Argument #4: ValueClass System.DateTime
Argument #5: String

ILGenerator.EmitCall(OpCode opcode, MethodInfo methodInfo, Type[] optionalParameterTypes) is designed for emitting call to such vararg method (for both Reflection.Emit and dynamic method scenarios). The optionalParameterTypes argument is passed in to create different MethodRef tokens.

Assume the MethodInfo of "VarargMethod" is miVarargMethod, the following code creates a DynamicMethod to perform the same functionality as previous "CallVarargMethod" does:

DynamicMethod dm = new DynamicMethod("CallVarargMethod", typeof(void), Type.EmptyTypes, typeof(object));
ILGenerator il = dm.GetILGenerator();

il.Emit(OpCodes.Ldstr, "Hello world from ");
il.Emit(OpCodes.Call, typeof(Assembly).GetMethod("GetExecutingAssembly"));
il.EmitCall(OpCodes.Call, miVarargMethod, new Type[] { typeof(Assembly) });

il.Emit(OpCodes.Ldstr, "Current time: ");
il.Emit(OpCodes.Call, typeof(DateTime).GetMethod("get_Now"));
il.Emit(OpCodes.Ldstr, " (UTC ");
il.Emit(OpCodes.Call, typeof(DateTime).GetMethod("get_UtcNow"));
il.Emit(OpCodes.Ldstr, ")");
il.EmitCall(OpCodes.Call, miVarargMethod, new Type[] { typeof(DateTime), typeof(string), typeof(DateTime), typeof(string) });

il.Emit(OpCodes.Ret);

As you see in the attached C# code (which uses ILGenerator.EmitCall for both Reflection.Emit and DynamicMethod), Type.GetMethod (and other APIs) can return MethodInfo of vararg methods; however MethodInfo.Invoke currently does not support to invoke on them. It is easy to get around with this: just create a dynamic method, and use EmitCall, and invoke on the dynamic method.

Although EmitCall can be used to emit a call to non-vararg method, you are encouraged to use ILGenerator.Emit(OpCode, MethodInfo) for that scenario, and use EmitCall mainly for vararg methods. With that said, the naming of this API does sound somewhat misleading.

Hello World with DynamicILInfo

Haibo_Luo — Tue, 31 Jan 2006 04:50:00 GMT

The following "Hello World" program shows how to use APIs in the class DynamicILInfo. MSDN documentation will have more details on this class in the next release.

using System;
using System.Reflection;
using System.Reflection.Emit;

class Demo {
static void Main() {
    DynamicMethod dm = new DynamicMethod("HelloWorld", typeof(void), Type.EmptyTypes, typeof(Demo), false);
    DynamicILInfo il = dm.GetDynamicILInfo();

    SignatureHelper sigHelper = SignatureHelper.GetLocalVarSigHelper();
    il.SetLocalSignature(sigHelper.GetSignature());

  byte[] code = { 0x00, 0x72, 0x01, 0x00, 0x00, 0x70, 0x28, 0x04, 0x00, 0x00, 0x0a, 0x00, 0x2a };
    int token0 = il.GetTokenFor("Hello world");
    int token1 = il.GetTokenFor(typeof(Console).GetMethod("WriteLine", new Type[] { typeof(string) }).MethodHandle);
    PutInteger4(token0, 0x0002, code);
    PutInteger4(token1, 0x0007, code);
    il.SetCode(code, 8);

    dm.Invoke(null, null);
}

static void PutInteger4(int value, int startPos, byte[] array) {
   array[startPos++] = (byte)value;
    array[startPos++] = (byte)(value >> 8);
    array[startPos++] = (byte)(value >> 16);
    array[startPos++] = (byte)(value >> 24);
}
}

> csc.exe demo.cs
> demo
Hello world

The DynamicILInfo class is different from ILGenerator. It directly uses byte arrays to set IL code, exception, and the local signature. So how can we get those byte arrays?

If the dynamic method we are going to create is based on a static method in some existing assembly, we can view the IL code (bytes) of the static method via ildasm or by using MethodBody.GetILByteArray. We can then build the byte array for SetCode from there. For all tokens used in the original static method, be sure to replace them (bold, as shown above and below in this example) with those generated from GetTokenFor.

.method public hidebysig static void HelloWorld() cil managed
// SIG: 00 00 01
{
// Method begins at RVA 0x2050
// Code size 13 (0xd)
.maxstack 8
IL_0000: /* 00 |             */ nop
IL_0001: /* 72 | (70)000001 */ ldstr "Hello world"
IL_0006: /* 28 | (0A)000004 */ call void [mscorlib]System.Console::WriteLine(string)
IL_000b: /* 00 |             */ nop
IL_000c: /* 2A |             */ ret
}

To build the byte array for SetException, I'd suggest taking a couple of minutes to read ECMA spec partiton II (25.4.6) first. The Flags/TryOffset/TryLength/HandlerOffset/HandlerLength ... can be retrieved from MethodBody.ExceptionHandlingClauses programatically. Be aware the exception type token (ClassToken) has to be obtained from GetTokenFor as well. Do you know Ildasm can show the raw exception information? I did not know this until I learned about it recently from Peli.:) Uncheck View->Expand try/catch and check show bytes; we will see something like the following at the bottom of the method IL:

// Exception count 1
.try IL_002e to IL_0051 finally handler IL_0051 to IL_0065
// HEX: 02 00 00 00 2E 00 00 00 23 00 00 00 51 00 00 00 14 00 00 00 00 00 00 00
}

Class SignatureHelper offers a convenient way to construct the local variable signature, if each local variable type is known. We can just make calls of SignatureHelper.AddArgument.

Are there any scenarios in your mind where using DynamicILInfo could be better than using DynamicILGenerator? How'd you like to construct those byte arrays? I am thinking about writing and sharing a tool, which, based on an existing method, generates C# code to define the equivalent dynamic method (using DynamicILInfo) (if this turns out to be a popular scenario).

Activator.CreateInstance and beyond

Haibo_Luo — Thu, 17 Nov 2005 21:55:00 GMT

Q: Assume we have 2000 unknown types; (however) we know each type has a constructor with integer as its' only parameter type. How to create objects 10000 times for each type (and make such late-new fast)?

Activator.CreateInstance comes to my fingers first. It is just so convenient to use: calling Activator.CreateInstance(type, new object[] {100}) in a loop. Done... I already heard somebody is yelling "this API is slow" ;) Yeah, each time it need figure out the right ConstructorInfo (by calling GetConstructors to get all ctors, parsing the constructor method signature/comparing, and binding to the most matched one). If you happen to have Visual Studio Team System installed, you can use this code to do a sample profiling and see what is going on there.

Activator.CreateInstance(type, 100);

Reflection Emit can optimize this scenario a bit: we create an in-memory module and a helper class "ClassFactory", then define one helper method for each type with the early-bind call (strong typed new, see OpCodes.Newobj below); the emitted method is equivalent to "public static Type TypeName(int arg1){ return new Type(arg1); }" in C#.

AssemblyBuilder asmBldr = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("InMemory"), AssemblyBuilderAccess.Run);
ModuleBuilder modBldr = asmBldr.DefineDynamicModule("helper");
TypeBuilder typeBldr = modBldr.DefineType("ClassFactory");

MethodBuilder methBldr = typeBldr.DefineMethod(type.Name, MethodAttributes.Public | MethodAttributes.Static, type, new Type[] { typeof(int) });
ILGenerator ilgen = methBldr.GetILGenerator();
ilgen.Emit(OpCodes.Nop);
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Newobj, type.GetConstructor(new Type[] { typeof(int) }));
ilgen.Emit(OpCodes.Ret);

Type baked = typeBldr.CreateType();

MethodInfo mi = baked.GetMethod(type.Name);

mi.Invoke(null, new object[] { 100 });

The code in italic need be put in a loop to repeat on 2000 types. We cache the MethodInfo (after baked) to a Dictionary<Type, MethodInfo> so that we can quickly retrieve the MethodInfo for massive consequent Invoke calls.

With DynamicMethod in CLR 2.0, we can avoid that lengthy preparation and bake steps (yes, light-weight codegen). For each type, simply create one dynamic method with the early-bind newobj, and cache it for future use.

DynamicMethod dm = new DynamicMethod("MyCtor", type, new Type[] { typeof(int) }, typeof(LateNew).Module);
ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Newobj, type.GetConstructor(new Type[] { typeof(int) }));
ilgen.Emit(OpCodes.Ret);

dm.Invoke(null, new object[] { 100 });

Do not forget ConstructorInfo.Invoke. This approach caches the RuntimeConstructorInfo of the exact constructor which we can then invoke on directly; on the other hand, previous Emit/DynamicMethod approaches seemly add one more layer late-invocation.

ConstructorInfo ci = t.GetConstructor(new Type[] { typeof(int) });

ci.Invoke(new object[] { 100 });

If you subsribe Joel Pobar's blog , you may already notice "delegate call in whidbey is close to callvirt in term of performance". Instead of caching the baked MethodInfo (or DynamicMethod), we should spend a bit more time on the preparation stage: to create the delegate (function pointer) for those on-the-fly methods and cache them . Assume I already defined such helper delegate type as follows:

public delegate object CtorInt32Delegate(int arg);

Let's call next approach as Reflection.Emit+Delegate, we can leverage those codes for the Reflection Emit approach above, and add one line of code to create the delegate:

...
Type baked = typeBldr.CreateType();
MethodInfo mi = baked.GetMethod(type.Name);

CtorInt32Delegate d = (CtorInt32Delegate)Delegate.CreateDelegate(typeof(CtorInt32Delegate), mi);

d(100); // C# syntax shortcut to d.Invoke(100);

We do the similar thing for the DynamicMethod + Delegate approach :

DynamicMethod dm = new DynamicMethod("MyCtor", type, new Type[] { typeof(int) }, typeof(LateNew).Module);
// get ILGenerator, and Emit call squences

CtorInt32Delegate d = (CtorInt32Delegate)dm.CreateDelegate(typeof(CtorInt32Delegate));

d(100);

The following table lists the result of these 6 approaches (no doubt there are other good solutions to the original question) when running the test code at my machine: the 2nd column shows the preparation time (code in the first box of each pair); the 3rd column is the object creation time cost (the second box). Among them, the last 2 approaches show the best performance. If you are wondering the early-bind cost for the same task, it is roughly 1 second at my machine.

Approach	Preparation Time(sec)	Object Creation Time (sec)
Activator.CreateInstance	--	00:09:28.4796646
Reflection.Emit	00:00:01.5781553	00:02:28.7684813
DynamicMethod.Invoke	00:00:00.0781265	00:02:04.3930133
ConstructorInfo.Invoke	00:00:00.0468759	00:00:56.0167005
Reflection.Emit+Delegate	00:00:01.4218750	00:00:04.2968750
DynamicMethod+Delegate	00:00:00.1093771	00:00:05.7031250

What if the constructor is parameterless? Here is the result (side by side with previous scenario, the object creation cost listed):

Approach	Parameterless	Parameter
Activator.CreateInstance	00:00:54.1729151	00:09:28.4796646
Reflection.Emit	00:02:10.3775032	00:02:28.7684813
DynamicMethod.Invoke	00:01:37.6581250	00:02:04.3930133
ConstructorInfo.Invoke	00:00:44.1883484	00:00:56.0167005
Reflection.Emit+Delegate	00:00:04.3125000	00:00:04.2968750
DynamicMethod+Delegate	00:00:05.5313562	00:00:05.7031250

We noticed:

Activator.CreateInstance approach is actually not that bad here: this API has different path to handle parameterless scenarios.
No significant differences between these 2 scenarios for other 5 approaches.

Furthermore, if only less than 16 types are frequently used, Activator.CreateInstance is "fast" API: internally it creates some sort of delegate directly on the type's parameterless constructor (no dynamic generated methods involved), and cache them. However, the cache size is 16, and 'Least Recently Used'-like cache algorithm is applied. The table below shows the time cost for creating objects of 16 or 17 different types sequentially 2000000 times.

# types used	Call Activator.CreateInstance(Type type)	Reflection.Emit+Delegate
16	00:00:10.8439582	00:00:01.5156541 + 00:00:04.2344563
17	00:01:27.6110571	00:00:01.5312794 + 00:00:04.4844611

DebuggerVisualizer for DynamicMethod (Show me the IL)

Haibo_Luo — Wed, 26 Oct 2005 00:23:00 GMT

Have you ever tried DynamicMethod, one of the coolest features in the .NET 2.0? Hope you have; otherwise, you can try it now with the examples 1, 2.

Like emitting IL to MethodBuilder, we first get ILGenerator from a DynamicMethod, and make a series of ILGenerator.Emit calls to emit the IL instructions. If the emit sequence/logic is complicated, we are likely to wanna check the on-the-fly IL content when debugging. (In fact, class DynamicILInfo provides an alternative way to set the IL code for dynamic method.)

It is not straightforward to find out this information and show it. Those instructions are stored in a byte array, so we need an ILReader to parse it; if the ILDasm-style output is preferred, we need to resolve type/field/method back from tokens (DynamicMethod has its own token management mechanism). By the way, Yiru wrote an excellent post "Debugging LCG", where windbg + SOS were used, and !dumpil was called with the DynamicMethod's MethodDesc (which is not available until jit'ting)

What if we want to live with the nice-looking Visual Studio 2005 environment, and still be able to see what has been emitted by far while we are debugging the dynamic method? Peli (our CLR team member and also an active Emit/LCG user) proposed that DebuggerVisualizer is a good solution. If you are interested in DebuggerVisualizer in general, some references can be found at Scott's blog (or msdn: how to write a visualizer)

Introducing my DynamicMethod DebuggerVisualizer... here are some visualizer-in-action pictures:

We can launch the visualizer dialog by clicking the magnifying glass visualizer button, from the local/watch windows or any DynamicMethod variable's data tip.

This is my DynamicMethod DebuggerVisualizer dialog window. The main area shows the IL we emitted so far. "Show bytes" checkbox allows us to specify whether we want to see the raw byte data. The window size/position and other settings are saved in the registry (unfortunately).

It contains two dlls:

DynamicMethodVisualizer: Just some routine debugger visualizer code here. Since DynamicMethod is not serializable, I have to prepare all necessary info in the debuggee side first, and save them into my MethodBodyInfo class. All IL instructions turn into the string format. No doubt, there are some side-effects on the the debuggee side.
ILReader: I mentioned a Reflection-based ILReader implementation in my previous post. In addition we need know some DynamicMethod implementation details (you can sleuth it using Reflector or Rotor 2.0 source code in the future): the internal m_ILStream field in class DynamicILGenerateor is used to store IL instructions; another class DynamicScope is to keep track of those used tokens. In order to retrieve the byte array and to resolve those tokens to some meaningful members, reflection APIs (such as FieldInfo.GetValue, PropertyInfo.GetValue etc) are used to explore those internal fields;

LEGAL NOTE: All source code is provided as is, with no warranties intended or implied. Use at your own risk.

Also, the implementation depends on internal DynamicMethod implementation, and does not ensure continuing working in the future. Such approach is not recommended for any production code either.

You may download the source code and binaries here at gotdotnet.com (which also includes a visualizer test program). To let this visualizer help your DynamicMethod debugging, (build &) copy DynamicMethodVisualizer.dll and ILReader.dll to your "My Documents\Visual Studio 2005\Visualizers" folder (or follow this search result).

Any comments are welcome.

Update (December 30, 2005): As Toby and others pointed out below, there was some issue around branch instructions. I fixed it and updated the source code at gotdotnet site. Also this version avoids using registry to keep the application settings.

Update (December 1, 2006): New version can be found here.