Haibo Luo's weblog : Reflection.Emit

DebuggerTypeProxy for IronPython Old-style Class and Instance

Haibo_Luo — Fri, 03 Aug 2007 22:37:00 GMT

First I want to make it clear that this post means nothing related to IronPython's plan about debugging python code in the future; it serves more as an interesting example to demonstrate DebuggerTypeProxyAttribute and how types can be created dynamically and be used in the VS debugger windows to display information the end users are interested in.

The python code below shows one old style class and some operations on the instance. After downloading the binary zip of IronPython 2.0 Alpha 3, we can create a solution, set it to launch ipy.exe for debugging, and step through the code inside Visual Studio; the locals window may show something like this after hitting the breakpoint.

The local variable alpha3's .NET type is IronPython.Runtime.Types.OldInstance, the way this object is displayed in the locals window is based on that type's fields and properties, which exposes many implementation details. While debugging, what the python users really want to know is the object attributes. My goal is to make python object attributes look like C# object's public fields; how can I achieve this?

DebuggerTypeProxyAttribute allows us to specify a proxy type for the target type. VS debugger uses the proxy type to display the target object. We already see such proxy types a lot: when viewing objects of most collection types, we are actually viewing their proxy type layouts.

In current IronPython implementation, every old style instance is of type I.R.T.OldInstance, so my first step is to define a proxy type "OldInstanceProxy" to expose the object attributes only. Clearly old style instances can have different attribute set of different names; but I can only specify one proxy type for the I.R.T.OldInstance type. [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)] is part of the solution to achieve the look-and-feel. The proxy type (OldInstanceProxy) has an object field (m_oldInstance) decorated with that attribute so that m_oldInstance will be hiden in the debugger window, but the fields m_oldInstance has will be shown. What should m_oldInstance look like? A .NET type (let me call it the "real" proxy type) with as many public fields as python object attributes, each having the same name as the attribute name, and we are going to create such types on the fly. Also the "real" proxy type's constructor is emitted with the code to assign these public fields properly. We then instantiate the new type with the original OldInstance object, and assign it to m_oldInstance.

[assembly:DebuggerTypeProxy(
typeof(IronPython.DebuggingSupport.OldInstanceProxy),
  TargetTypeName = "IronPython.Runtime.Types.OldInstance, IronPython, Version=2.0.0.300, ...")
]

public class OldInstanceProxy{
[DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
public object m_oldInstance;

public OldInstanceProxy(object target) {
try {
   OldInstance obj = target as OldInstance;
TypeBuilder tb = CodeGen.CreateTemporaryType();
ConstructorBuilder cb = tb.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, new Type[] { typeof(OldInstance) });
ILGenerator il = cb.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Call, typeof(Object).GetConstructor(Type.EmptyTypes));

foreach (KeyValuePair<object,object> pair in obj.Dictionary) {
    string key = pair.Key.ToString();
    Type fieldType = pair.Value == null ? typeof(object) : pair.Value.GetType();
    FieldBuilder fb = tb.DefineField(key, fieldType, FieldAttributes.Pub.Public);

        // emit code for the ctor ...
      }
      il.Emit(OpCodes.Ret);

      m_oldInstance = Activator.CreateInstance(tb.CreateType(), obj);

Few discussions:

The attached solution also includes another proxy type: OldClassProxy for IronPython.Runtime.Types.OldClass. With that, viewing class attributes feels like viewing C# class static fields. Such coding pattern can be applied to other similar scenarios.
It is a bit hard to apply this for IronPython new style instances. For each new style class, IronPython creates a new type on the fly. For example, "class C(object): pass" generates a IronPython.Runtime.NewTypes.Object_1. The proxy type (which will create the "real" proxy type) need be created at the same time.
Types created by Reflection.Emit are not GC-collectible. In my proxy type implementation, a simple caching mechanism is implemented to reuse those "real" proxy types; but considering the python dynamism, object attributes can be added, removed, their values' type can be changed; such "real" proxy type may have to be created frequently, each click to expand in the debugger window could cause one type creation, so use wisely if you use such proxy type in real world scenarios.
Unlike DebuggerVisualizer where VS provides a way to debug it, it is a bit inconvenient to debug DebuggerTypeProxy code. So I found having the constructor code wrapped inside try-catch and saving the exception if thrown is useful. The exception object can be viewed in the debugger window if the type proxy dll is compiled with the "Debug" configuration. The messages from Debug.WriteLine are helpful too.
The proxy type implementation depends on the rapidly changing code of the DLR/IronPython project. It is not surprising that the attached solution could be broken in the future. .

The following pictures show the proxy type in action. Compared to the previous picture, now you can easily check out the values of the attribute "url" and "version", as well as the class attribute "project_name" (shown in the first picture). The new attribute "release_date" appears in the second picture after stepping through the breakpoint line.

To use the attached solution, you need download IronPython 2.0 alpha 3 binary zip, and I assume you unzip it to C:\. Your comments are welcome.

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.

Reflection.Emit and Resources

Haibo_Luo — Thu, 27 Apr 2006 03:18:00 GMT

Reflection.Emit is relatively new to me. Recently I had a chance to deal with a resource related emit issue and had a tough time wading through so many emit APIs with "resource" in their names. Seems they are kind of messy, and I feel the API naming is not as good as it can be.

The Windows Portable Executable (PE) file format has a .rsrc section; we normally call this section the standard Win32 resources or unmanaged resources section. Reflection.Emit was designed to support emitting the unmanaged resources to a PE file; however our customers recently told us that AssemblyBuilder.DefineUnmanagedResource and ModuleBuilder.DefineUnmanagedResource are broken in some aspects. We will have to wait for the next major release to get them fixed.

CLR extends the PE file format to contain CIL header and data sections (which reside in PE file's .text section). Managed resources are stored in this section too. For a better understanding of metadata, I review the ecma spec 335, particularly these 2 paragraphs:

From Partition II, section 6.2.2

A manifest resource is simply a named item of data associated with an assembly. A manifest resource is introduced using the .mresource directive, which adds the manifest resource to the assembly manifest begun by a preceding .assembly declaration.

From Partition II, section 22.24

The ManifestResource table has the following columns:

Offset (a 4-byte constant)
Flags (a 4-byte bitmask of type ManifestResourceAttributes)
Name (an index into the String heap)
Implementation (an index into a File table, a AssemblyRef table, or null; more precisely, an Implementation coded index)

There are some important points in the fine print at the end of section 22.24, which I'll reprint here:

These rows in the ManifestResouce table are the result of .mresource directives
The Offset specifies the byte offset within the referenced file at which this resource record begins;
The Implementation specifies which file holds this resource. It can be null or non-null:
- if null, it means the resource is stored in the current file;
- if not null, the resource is in another file. That whole file or part of that file can be resource.

Based on the Implementation value, we can split manifest resources into 2 categories: embedded or linked (in terms of C# compiler’s vocabulary). Check out part of C# compiler help message (via csc /?) and ILdasm output below; foo.cs is a simply C# file with only 1 Main method inside a class; any.file is a plain text file with a couple of characters inside.

/resource:<resinfo>
   Embed the specified resource (Short form: /res)
/linkresource:<resinfo>
   Link the specified resource to this assembly (Short form: /linkres)
   Where the resinfo format is <file>[,<string name>[,public|private]]</body>

csc /out:embedded.exe /res:any.file,anyname,private foo.cs
csc /out:linked.exe /linkres:any.file,anyname,public foo.cs

.mresource private anyname
{
// Offset: 0x00000000 Length: 0x0000000E
}
.module embedded.exe

.file nometadata any.file
.hash = (C8 C5 4E 11 B1 CB 27 C3 37 6F A8 25 20 D5 3E F9 // ..N...'.7o.% .>.
93 2A 02 C0 ) // .*..

.mresource public anyname
{
.file any.file at 0x00000000
}
.module linked.exe

From the ildasm output, we can guess the implementation value of embedded.exe's .mresource is null; on the contrary, linked.exe's .mresource directive shows its manifest resource "anyname" is associated with any.file.

From another aspect, BCL provides several classes (such as ResourceManager) in the System.Resources namespace to help create and manipulate resources; Reflection.Emit, as part of .NET library, is consistent. Different APIs are designed for the following 2 scenarios:

the user does not have .resources file ready, and will emit each resource item one by one during the emit procedure;
the user has .resources file (created with ResourceWriter, or generated by resgen.exe) or any other format files (such as Crystal Report (.rpt), logo (.gif)) ready to integrate.

To be consistent with the MSDN reflection emit documentation, I will call these 2 scenarios emitting "managed resource" and "resource blob" from now on.

We now know that we have 2 approaches to integrate a resource into an assembly: embedded or linked; we also have 2 emit scenarios: emitting "managed resource" or "resource blob". These 4 combinations are all supported in .NET 2.0. Note in v1.x, we were unable to embed the "resource blob", which has been fixed by the newly added API ModuleBuilder.DefineManifestResource(a good doc, btw).

The following list shows Reflection.Emit APIs to use for each combination:

Embed "managed resource": Get IResourceWriter fom ModuleBuilder.DefineResource; follow with a series of IResourceWriter.AddResource or AddResourceData calls;
Embed "resource blob": use ModuleBuilder.DefineManifestResource;
Link "managed resource": Get IResourceWriter from AssemblyBuilder.DefineResource; follow with a series of IResourceWriter.AddResource or AddResourceData calls;
Link "resource blob": use AssemblyBuilder.AddResourceFile;

If the .resources file is generated already, certainly we can use AssemblyBuilder.AddResouceFile to directly link it or ModuleBuilder.DefineManifestResource to embed it to the assembly being emitted.

Attached you can find a sample code that I used to explore these APIs. After downloading the sample, you can take a look at the code and try compiling and running it. "temp.exe" is emitted with some resources; I suggest using Ildasm to check its Manifest. You can then run "temp.exe" to examine some resource information of its' own. I already see a couple of strange spots from the output ...

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