Yesterday, I gave an overview of the problems that async solves, and how it actually solves them. As we saw in that post, async is remarkably cunning, and can become remarkably tricky to follow when applied in a real application, which naturally makes any decompilation a bit of a challenge. If you haven’t read the previous post on how async works already, I recommend you at least skim through it so that you know what examples we’ll be working with, and so that we’re all working with the same understanding of state machines.

Now, with that introduction done, we should have a look at some real code.

We are currently implementing support for the decompilation of async inside .NET Reflector, so all the code you’ll see in this post will be generated by Reflector, both before and after the translation phase that deals with the async state machines.

You need to be aware that there are several implementations of async in the code that we’ll see, because there are different implementations of async in the code that you find in the .NET 4.5 framework libraries compared with code that is compiled using the Dev11 C# 5 compiler.  For our Reflector work we are currently working on the former, mainly because the fundamental part of the work (the processing of the state machine) is the same in both cases, and the framework libraries contain hundreds of potential test cases.

Real code

If you look at the ReadAsyncInternal method in the .NET 4.5 version of mscorlib, you’ll see that it has the following code:

Click for an enlarged version

Remember, from our earlier example of the simple string-reader program, the compiler generates a class which implements the state machine, setting the various fields corresponding to the arguments and the local variables, which get lifted into this class. The <>t__builder is an instance of AsyncTaskMethodBuilder, which is used to do the plumbing between the client and the implementation of the async method, and we’ll see it used in the MoveNext method.

The compiler-generated class has the following form:

Click for an enlarged version

Notice the state value field <>1__state, and the field <>4__ this which allows access back to the original instance of StreamReader which constructed this instance of the state machine.

For us, the really interesting part is the code in the MoveNext method:

Click for an enlarged version

The outer Try has a body that ends with the code:

Let’s take a quick walk through the implications of this.

Stepping through the code

In the exception case we set the state to -1, which is a state that causes the MoveNext to return instantly while remaining in that state. In the success case, we store the function result value using the SetResult, which ends up setting the value into the Task associated with this invocation of the method. Likewise, the SetException sets the Exception property of the Task object, taking care to specially handle the OperationCanceledException, which is used by the Task library to communicate that a synchronous cancellation request was successfully honoured. After this, anyone waiting on the Task will be notified that they can continue running via the usual implementation in the Task class.

It’s fairly easy to follow the code around while keeping an eye on the state transitions, but the most interesting thing that happens occurs when we call out to some asynchronous method, such as in the following code fragment:

Click for an enlarged version

Our method is calling into the ReadAsync method:

Click for an enlarged version

This returns a Task which will eventually contain a count of the number of bytes read, potentially also modifying the arrays that were passed in as arguments.

We now get a slight complication. In order to control whether the synchronization context and other information needs to be preserved, the Task is passed through the .ConfigureAwait method before its GetAwaiter is called. This result of the call to GetAwaiter() supports the Await pattern; it is expected to have certain methods implemented on it, much like an Enumerable is expected to have a GetEnumerator method. Let’s take a look at how this process can proceed.

First we have the quick path: when IsCompleted returns true to say that the result is already available, we can jump straight to label 03AD. Otherwise, things get a little more complicated: we need to save any state we’re going to need later into a field in the current object, set up the OnCompleted action of the task so that the MoveNext method is going to be called again, set the state field to the next state, and return. At some point, assuming no exceptions, we’ll be called back, the state value will ensure that we reach label 0390, where we can get back the values that we saved away, and then continue to the same place that we’d have gone in the fast path.

At that location, we’ll get the result of the asynchronous operation using GetResult and carry on as if we had been running all the time. Notice that all of the thread transitions (if any are required) are hidden away inside the object that is returned by GetAwaiter, which is responsible for getting us to the right place before it calls the delegate that was passed into OnCompleted.

Not one compiler, but two

As I mentioned earlier, part of the challenge in understand all this comes as a result that we’re targeting at least two, subtly different, compilers. Thus far we’ve been looking at the results of the compiler used to generate the .NET 4.5 framework libraries, so how does this all change if you use the compiler that ships with the latest Dev11 beta?

First there is now an interface, IAsyncStateMachine, that constrains the interface between the state machine and the code that uses it:

This is implemented by the compiler generated type which is now a struct instead of a class:

The initialization code also looks a little different:

The body of the MoveNext is still surrounded by a Try Catch block as before, though the code to fire off an asynchronous call now has slightly fewer lines to it, using the builder to do more of the work. As before, if the operation doesn’t instantly complete, the state is set, and we set up a notification from the called method so that we’ll be brought back after the operation completes. In order to do this, we need to pass in the awaiter and the state machine object by using the ref modifier on the call:

Click for an enlarged version

The idea is the same as the previous implementation, though the mechanics of capturing the relevant synchronization and execution contexts is a little different. If you want to see what I mean, take a look at the code in the AsyncTaskmethodBuilder class in System.Runtime.CompilerServices in the .NET 4.5 version of mscorlib.dll.

By looking out for the pattern of Async code, Reflector can fold code back into the form using async/await. So, for example, the above example will be displayed as:

Click for an enlarged version

Summary

Async is implemented using a compiler transform to implement code as a state machine, though this requires a few support classes in the runtime library, and that a set of methods need to be implemented on types that support asynchronous calls following the Await pattern. No changes are required to the CLR, though some support has been added inside mscorlib, and extra methods have been added to the Task<…> type to support the calls of the Awaiter pattern.

From the point of view of a tool like Reflector, having the compiler do a transform, rather than implementing the feature as something built into the CLR, unsurprisingly makes life harder for a decompiler. There’s no metadata to say some set of IL instructions are here as the result of the translation of an await, so instead the decompiler needs to look for the pattern of calls that is generated by the C# compiler. This is exactly the kind of thing that is already done to recognise lambda expressions and iterator blocks, which are also implemented by the compiler rather than the CLR. Given that, as we saw in the previous post, a basic state machine can be lashed together using lambda expressions and iterator blocks, the similarities in the both the implementation and our solution are no surprise.

Async really seems to have hit the sweet spot for a technology that allows you to fairly transparently run non-blocking code on a single thread, and user code looks very much like it would for a straightforward blocking implementation. In fact, you can almost write it that way first, and then change it into non-blocking code by just changing the method’s return type to Type<…>, marking it with async, and then using await and asynchronous versions of methods that you call.

Naturally, it isn’t quite that simple in practice. For example, having a function return too early might not interact well with constructs such as locks and exception handlers, and potentially offers the chance of re-entrancy in cases that were previously safe. Nevertheless, async is not as opaque as perhaps it first seems, and you could learn a huge amount by using .NET Reflector to start investigating C#5 as soon as possible.

C# 5 has finally arrived, and the biggest new feature in the language is async, and its associated Await (contextual) keyword. Naturally, there’s been a lot of discussion from a lot of different points of view, and we’ve been working hard to make sure .NET Reflector can accurately decompile asynchronous code so that you can start investigating C#5 code right away. Just understanding how async actually works at the front end is no mean feat, and when you bear in mind that we’re juggling up to 3 different compilers, it’s been a fascinating challenge.

Before we dive into how we’re handing async code in Reflector, it’s worth grounding ourselves first. Let’s start with a quick look at what async is designed for, and then we’ll take a deeper dive into the nuts and bolts, and how they apply to us.

Solving a problem

This much-anticipated Async feature is designed to solve a problem that every developer has run into when writing a GUI application – GUI locking & freezing. Most windowing libraries avoid the need to take locks by having all of the GUI code run on a single thread, with this thread using some kind of mailbox to prevent asynchronous message arrival.

We obviously want to prevent asynchronous message arrival because, when the string of a TextBox is being updated to “fred”, we don’t want to get a message telling us to update it to “joe” while we are still in the middle of processing the change to “fred”. The key to this enforcement of linear processing is that the GUI is only going to respond to user interaction if the single GUI-owned thread is available to do processing of incoming events. If we need to do a blocking operation, like hitting a web service, and we do it on the GUI-owned thread, then the GUI is going to feel dead, with screen updates and actions not having any effect until the blocking operation finishes.

This is unacceptable, particularly on touch controlled devices, where the feedback has to be quick to be effective. Visiting some sites on my iPhone’s web browser can be painful, as I often touch to cause some kind of action, but then find that Safari is still busy processing the page. Frustratingly, this leaves me in a state where I don’t know if Safari is going to do something when it gets less busy, or whether my earlier interaction has just been ignored. WinRT is going to be designed for touch from day one, and its designers have apparently paid careful attention to existing touch Operating Systems, and learned some valuable lessons. As a result, WinRT requires all operations that are going to take more than 50 milliseconds to offer an asynchronous version (and, in lots of cases, only an asynchronous version), as a means of keeping the user experience of Metro applications slick and intuitive. The question then becomes how to make it easy for developers to use this new functionality.

New tricks

In the past we’ve been able to defer work to a later point in time by capturing the context as a closure, passing this closure to some object that is responsible for doing the wait, and then having that closure called when the code should continue running. This continuation-passing style makes the code very complicated to read, and makes it very hard to follow the control flow of the code.

Let’s take a look at an example of this using a very simplistic example. Suppose we want to read two strings from the Console, and write their total length in characters to the Console. If at any point a blank line is entered, then we don’t want to read any more data, but we still want to print the total number of characters:

       int totalCharacters = 0;
       string input = Console.ReadLine();
       if (!string.IsNullOrEmpty(input))
       {
           Console.WriteLine("First string: {0}", input);
           totalCharacters += input.Length;
           input = Console.ReadLine();
           if (!string.IsNullOrEmpty(input))
           {
               Console.WriteLine("Second string: {0}", input);
               totalCharacters += input.Length;
           }
       }
       Console.WriteLine(totalCharacters);
 

The trouble with the above code is that it is blocking the main thread, which doesn’t matter in this case, but would if it were an operation on the GUI. The thread also sits inside Console.ReadLine, consuming the resources that a thread requires (such as 1mb of stack space), without doing any useful work. If this was some kind of (web) server application, then this would be wasteful and would inhibit scalability. Ideally, we’d really like to record the state of the program, but then pass the thread back to the runtime, only grabbing it later when we have more work to do.

Let’s say we were provided with some kind of asynchronous version of Console.ReadLine, such as a function of the following form, which takes responsibility for getting data from the console and then calling an action function with that data when it is available on some available thread:

static void ReadLineAndThenDo(Action<string>action)
            {
            ThreadPool.QueueUserWorkItem(
               delegate
                   {
                        string line = Console.ReadLine();
                        action(line);
                   });
        }

In that situation, it would be possible for the outer function to release the thread it is running on, knowing that the action function is going to be called on a suitable thread when the result is available.

There are two ways that you might implement the new program. You might use the continuation-passing style we briefly mentioned earlier, using lambda expressions to capture the state of the local variables, which we can use for later parts of the computation:

static void ReadLineAndThenDo(Action<string>action)
        {
            ThreadPool.QueueUserWorkItem(
               delegate
                   {
                        string line = Console.ReadLine();
                        action(line);
                   });
        }

In that situation, it would be possible for the outer function to release the thread it is running on, knowing that the action function is going to be called on a suitable thread when the result is available.

There are two ways thatyou might implement the new program. You might use the continuation-passingstyle we briefly mentioned earlier, using lambda expressions to capture thestate of the local variables, which we can use for later parts of thecomputation:

static void Attempt2()
{
   int totalCharacters= 0;
      ReadLineAndThenDo(
         input =>
            {
               if (!string.IsNullOrEmpty(input))
               {
                   Console.WriteLine("First string: {0}",input);
                   totalCharacters += input.Length;
                   ReadLineAndThenDo(
                     input2 =>
                       {
                         if (!string.IsNullOrEmpty(input2))
                         {
                           Console.WriteLine(“Second string: {0}”,input2);
                           totalCharacters += input2.Length;
                         }
                         Console.WriteLine(totalCharacters);
                       });
               }
             });
}

In this instance, the change has been localised to our function, but what a change it is! Every time we want to do an asynchronous call, we have had to pass in the rest of the code as a lambda expression (input => …) or (input2 => …). The indentation gets deeper and deeper, and things become very complicated if we have a loop construct of any kind in the code. The logic of the code has been obfuscated in order to fit into the programming language.

However, if we take another look at the very first version of our string reader, we can see that there are distinct sections of code, with a new section starting each time we pass control to a ReadLine. For example, we start in state one, which does the initial setup of the local variables, and we then do a ReadLine and assume we enter state two when this has finished. As we enter state two, we know that there is new input available, and we can process this until we get to the next ReadLine, which starts state three:

            /*State 0 */
            inttotalCharacters = 0;
            string input = Console.ReadLine();
           /* State 1 */
            if (!string.IsNullOrEmpty(input))
            {
               Console.WriteLine("First string: {0}",input);
               totalCharacters += input.Length;
               input = Console.ReadLine();
               /* State 2 */
               if (!string.IsNullOrEmpty(input))
               {
                   Console.WriteLine("Second string: {0}",input);
                   totalCharacters += input.Length;
               }
            }
     /* State 3 */
            Console.WriteLine(totalCharacters);
 

This feels very much like what is known as a state machine in Computer Science parlance, which is the second way we can implement this program. We’ve seen such implementations used before, in the compilation of iterator blocks by the C# compiler, so there is already existing compiler technology for implementing such transformations.

We can implement the state machine using a new compiler generated class, Attempt3Machine. This will have a state variable, m_State, recording the state of the machine as one of its fields. We’ll lift the local variables of the method into the fields of the state machine (necessary because they live between the calls into our state machine), and we’ll implement the machine in a way that uses a single method to transition it from its current state to the next state. We call this method MoveNext, in the spirit of iterator blocks implementation.

Implementing a state machine

We’ll now need to change our asynchronous version of ReadLine to interact with our state machine. For the moment, the ReadLine will read a line from the Console, set this into the m_Input field which corresponds to the local variable input in the original code, and will then force the machine to make a transition:

        static void ReadLineAndThenDo2(Attempt3MachinestateMachine)
        {
            ThreadPool.QueueUserWorkItem(
               delegate
                   {
                        string line = Console.ReadLine();
                        stateMachine.m_Input= line;
                        stateMachine.MoveNext();
                   });
        }

This then leaves us with a state machine with the following implementation:

        class Attempt3Machine
        {
            intm_State = 0;
 
            private int m_TotalCharacters= 0;
            public string m_Input;
 
            public void MoveNext()
            {
               switch (m_State)
               {
                   case 0:
                        m_State= 1;
                        ReadLineAndThenDo2(this);
                        return;
 
                   case 1:
                        if (!string.IsNullOrEmpty(m_Input))
                        {
                            Console.WriteLine("First string: {0}",m_Input);
                            m_TotalCharacters+= m_Input.Length;
                            m_State= 2;
                            ReadLineAndThenDo2(this);
                            return;
                        }
                        goto case 3;
 
                   case 2:
                        if (!string.IsNullOrEmpty(m_Input))
                        {
                            Console.WriteLine("Second string: {0}",m_Input);
                            m_TotalCharacters+= m_Input.Length;
                        }
                        goto case 3;
 
                   case 3:
                        Console.WriteLine(m_TotalCharacters);
                        return;
               }
            }
        }

And with a method that uses this of the form:

        static void Attempt3()
        {
            new Attempt3Machine().MoveNext();
        }
 

Results

So where has this got us? Well, the translation between the code above and something that started out like the following is fairly mechanical:

            int totalCharacters = 0;
            string input = await Console.ReadLine();
            if (!string.IsNullOrEmpty(input))
            {
                Console.WriteLine("First string: {0}", input);
                totalCharacters += input.Length;
                input = await Console.ReadLine();
                if (!string.IsNullOrEmpty(input))
                {
                    Console.WriteLine("Second string: {0}", input);
                    totalCharacters += input.Length;
                }
            }
            Console.WriteLine(totalCharacters);

The position of the Await expressions tells us where we need to have new states for the state machine, and we simply need to push the code in-between into the relevant state transition blocks.

By using the Await in the above code, we have kept the code in a state where it is easy to follow the control flow, even though the method stops running at the point where the await is called.

Tidying up with Tasks

There are, of course, several loose ends to tidy up. First, it looks easy in the above code to split the code into the transitions on a line by line basis, but in reality you can put multiple Await expressions in a single statement:

            int x = await f() + await g();

This means we may need a new field location to store the result of the first Await while we are waiting for the second Await to complete. We could use several locations, or just have a single location that stores the intermediate value typed as an object, and then cast as necessary when wanting to use this value. The current semantics of await only allow a single outstanding call at any time, so we need to wait for f() to finish before g() is launched.

If we have an async function, then the caller needs to have something that they can use to get the value when it is finally calculated. .NET 4 included the rather brilliant Task<> abstraction, which reflects a computation that may still be running. A Task<int> object, for example, represents a calculation that may eventually return an integer. Using its Result property, a client can fish out the result value, blocking until it is available, and find out details of any exceptions that were thrown. Tasks support a number of very powerful operators, such as a ContinueWith (which allows you to schedule the execution of one task when some other task completes), and a means of waiting for one or many tasks to finish. Tasks also support a model of synchronous cancellation, with the user function being expected to regularly check for a demand for cancellation, and throwing an exception if this is required. As a result, any method that uses await must either return void or Task<…>.

Some Considerations

Threading always adds complication to any design, and our current example doesn’t really have a good threading model. Some operations need to be called on certain threads, so our code would really need to transition back onto one of these threads before it is called, probably by using the Post operation of the synchronization context that was active when we launched the asynchronous call. .NET also has a notion of an execution context which may need to flow across to any worker threads that are launched. We may need to capture these values when we launch a call, and then get back to the correct state before we restart in the next transition.

Exceptions also need to handled and stored away in the Task object associated with the current method, so that callers can later get the correct details of what went wrong. If the method finishes successfully, we’re also going to need to store the result away in the task, or at least mark the task as finished if there is no return value. This will allow callers to wait on our method finishing.

There are also several missing pieces in the story of the communication between the state machine (when it fires off the asynchronous work) and the object that is going to do the work. The example above hacked this, by having the asynchronous method we were calling (DoReadLineAndThenDo) know lots of detail about the caller, such as the field in which to write the return value. This code is obviously too specific, and is purely for demonstration purposes. We get around this by adding indirection, having the asynchronous ReadLine return a Task, and then hook an OnCompletion action to the returned task which causes the state machine to move to the next state.

Also, the action may complete really quickly, or might even have finished already. In that case it is a real waste of effort to go through the mechanism of returning from MoveNext and then having a MoveNext transition called by an external party. We could have simply jumped to the new state in the MoveNext implementation itself, without going through the capture state and then restore process. This is handled, as we’ll see in my next blog post, by having an Awaiter pattern which includes the asynchronous object, providing a property called IsCompleted which can be used to allow the MoveNext to instantly transition to the next state. The result will be fetched using GetResult.

Wrapping up

So asynchronous code is clearly incredibly useful, and remarkably cunning in its implementation, which means that we’ve had to work twice as hard to unravel it at the other end (as I’ll demonstrate shortly). Hopefully you can see how quickly async code can start to become convoluted, and how backtracking the various calls and state transitions in a real application poses a challenge. Now that we’re all on the same page, let’s take a look at how we’re handling async in .NET Reflector decompilation.

The team is finally back under the same roof (back from assorted conferences and holidays), and we’ve been forging ahead with our Dev11 theming and C#5 async support. We also took the time to do a little house-keeping, which I’ll get out of the way first. So here’s what we’ve been working on for .NET Reflector v7.6.0.356EAP4…

House-keeping

• The “about” box in the standalone component of Reflector has been given an overdue lick of paint. It’s now the same as what the Visual Studio extension displays.
• We’ve made the availability of the niche languages more configurable. Going through the Tools > Options > Languages menu in the standalone tool, you can now control whether Delphi and Oxygene are available in the languages drop-down menu as decompilation targets.

(click for a larger, clearer image)

• The End-of-EAP dialog has had a refresh, and now gives you clear instructions on how to submit your feedback, jump up to the latest Early Access build, or uninstall the EAP entirely.
• Clive fixed a bug in the WinMD support, so that WinMD files are now discoverable on both 32-bit and 64-bit machines.

Visual Studio 11 theming

Nigel’s been unravelling how theming works in VS11, and how to make the .NET Reflector components that extend into Visual Studio play nicely with the Dev11 beta. This has involved a certain degree of re-plumbing in the Reflector UI, but Nigel is taking it all in his stride.

• We’ve got to a point where the Reflector Object Browser and context menus accept the Dev11 theme tones & background colours, so the Reflector extension should feel pretty natural inside Visual Studio.
• At the moment, we are aware of a minor bug when using the dark theme; some text in the ROB is rendered lighter than expected. We’re tracking this down, and will get it tidied up soon.

Async decompilation

Clive & Ruchika are continuing to work down the list of 192 new async methods, making sure we emit sensible decompiled code in each case. Ruchika has got her head around how to effectively test async decompilation, which should start to speed things up.

• Taking a look at our current coverage, we support most of the new async methods in the System.IO namespace & some of the new methods in System.Xml. We don’t yet support the new methods in System.net or System.Web, but these are on the list for the next sprint.
• At the moment, we know Reflector doesn’t handle nested try blocks very well, and we’ve also taken steps to make sure we don’t emit anything totally mad. Essentially, anything that we’re not sure we can do right for .NET 4.5, we fail back to emitting in .NET 4.0 (I’ll come back to this in a moment).

Click on the image for an enlarged, more readable version

If you’re interested to know a bit more about the challenge Clive & Ruchika are facing, it boils down to the fact that they’re trying to update Reflector to have coverage across not one, but 2 new compilers: one for the framework, and a separate (newer) one in Dev11.

At the moment they’ve achieved partial coverage, but they’re working hard to improve that. If the final release of .NET 4.5 is built using a more up-to-date compiler, then we’ll move as fast as we can to cover that, but we want to make sure you can start experimenting with the latest technology right now.

Feedback

Any and all feedback about the latest build of Reflector is gratefully received! We’d particularly like to know about any issues you encounter with our async code and Dev11 theming.

In fact, with regards to the async feedback we’d love to see, let me explain that a little more. As I mentioned earlier, we’re trying to graciously fail back to .NET 4.0 code when we know we can’t decompile some async method you’ve targeted. So, any async code we’re displaying, we think we’re handling well.

As such, we’ve love to hear any feedback about async decompilation that has clearly failed in some way (i.e. where we’ve tried to generate async code, and it’s just not right).

Download the latest Early Access build of .NET Reflector, and let us know what you think. If you have any comments about the latest build, just send an email to EAP@reflector.net – we really appreciate your help.

Given that .NET 4.5 is available as part of the beta for Dev11, we have added some new support functionality to .NET Reflector (this is already available in our EAP releases).

First, Reflector will now notice if you have .NET 4.5 installed on the machine. As 4.5 is an in-place installation, we notice the presence of certain files to trigger this.

This then populates the assembly list with a set of useful assemblies.

Click for the full screenshot

.NET 4.5 has led to a lot of rearrangement of the assemblies – there are a lot more assemblies, and using the type forward attributes you can see what has moved. For example, in System.Core, various types (such as LockRecursionException) have been moved elsewhere.

Click for the full screenshot

Using Reflector, we can see that LockRecursionException has a TypeForwardedAttribute, and by clicking on the type you can find where it has moved to. In this case, it has moved to mscorlib.

Click for the full screenshot

The other interesting feature added to the language is the CallerMemberName, CallerFilePath and CallerLineNumber attributes that can be added to optional arguments to get information about the caller of a given function. This is implemented, like optional arguments themselves, by baking extra information into the call site.

Click for the full screenshot

Using Reflector, we can decompile this to see the inlined arguments at the call sites.

We have some partial support for the new C# async/await construct, but we don’t yet have Reflector decompiling that perfectly. However, Reflector is proving to be a useful tool for investigating the new assemblies that make up the latest release of the .NET framework.

Click for the full screenshot

If you’re using the Early Access release of .NET Reflector to decompile C#5 async constructs, it would be great to know what kind of results you’re getting.

The CLR is a canny beast that takes liberties with optimising your code using several different mechanisms, which can make debugging retail builds of software an ungainly experience. I’ve been doing some investigation into how to make this process as similar as possible to “normal’ debugging, which I’d like to share with you. But first, let’s look at those liberties the CLR is taking.

First, there’s the ahead-of-time ngen process. If we’re not jitting the IL, then there’s nothing waiting for a quick result, and so we can apply more of the traditional compiler optimisations to generate tighter code. The results are saved as dll files which can be loaded later into the process.

Second, there’s the JIT compiler itself, which can see if there’s a debugger attached to the process at the point that the code is jitted. If there is a debugger present, then the JIT compiler can decide to generate code which is more debuggable. In this case, it makes sense that the CLR tries to keep a more accurate mapping between the machine code and the initial IL, which is, in turn, related to the original source code using a pdb file.

Unfortunately, there is a tradeoff between optimisation and one’s ability to debug the running code. In the old days, the amount of effort a compiler spent improving the generated code was controlled using compiler flags, which in turn were set very differently between retail and debug builds.

Most of the information about the optimisations that the CLR applies is sparsely threaded through independent blogs posts and MSDN documentation. For quite some time I’ve wanted to sit down and look at the effects of various techniques which people have described as giving the user the best debugging experience. With Reflector VSPro, we really need to know this kind of information – our users typically want to attach to a retail build of a product and debug it, and we’d like to keep the experience as close as possible to the initial debugging experience you get with a debug build.

With that in mind, this post describes just some of the experiments I did to get confidence with the steps that are needed to keep the debugging experience good. Without a definitive description of the workings of the CLR, experiments are all that we have and, as with all experiments, you can develop a model that doesn’t accurately reflect what’s happening. I welcome any feedback.

In case you just want the result and don’t want to read any further, the debugging experience seems to be best if you have the environment variable COMPLUS_ZAPDISABLE set from the time that anything gets jitted, and you also have a suitable ini file placed against one or more assemblies (by suitable I mean “contains suitable control flags to turn off the optimisations’). I’d naturally still recommend that you read on, as there are deeper details which are worth knowing!

I fully intend to get these settings into Reflector VSPro, so that it’s the tool rather than the user that sets up the necessary files and environment. At the very least, we intend to have the tool give the user enough information for them to do the work themselves (if Reflector can’t automate the process). Of course, user intervention is always going to be needed in the case of, for example, an IIS web application which is going to be started before a debugger is attached to it.

Initial Experiments with Optimization

For some initial investigation, we’ll start with the following simple C# console application:

The small method is designed to provoke inlining by the jit compiler, as a way to tell if such optimisations have been disabled. The never-ending loop gives us time to retrospectively attach, while at the same time taking enough processor cycles for the application to show up in process Explorer.

We’ll compile this code into both debug and release builds. In the case of a debug build we get the following IL

And the following attributes on the Assembly:

(click on the image above for to enlarge)

The NOPs are present to allow a better mapping, via the pdb file, back to the original source code. I believe it is this long DebuggableAttribute that turns off some of the optimisations (as we’ll soon see).

In release build, we get the following code:

And the following attributes

We first run the release version, letting it get into the code which does the printing so that we can be sure the methods are jitted. We can then attach using windbg and look at the loaded modules.

I believe the CLR currently doesn’t re-jit methods – this has been added as a feature in .NET 4.5 so that an attached profiler can demand the re-jit of methods. However, the CLR doesn’t yet do the kinds of work that a Java HotSpot compiler does using on-stack replacement and adaptive compilation to specialise the code, depending on dynamic call patterns. What it does do is optimised interface dispatch using dynamically generated stubs after a slow path has been executed a number of times, but that doesn’t affect our example here.

In Windbg, we see the following modules have been loaded:

The mscorlib.ni.dll is the result of the ngen processing of the assembly.

If we do the same thing with the debug version, letting it run and then attaching, we see that the following modules were loaded:

We see that the debug version of our compiled method doesn’t load the ngen version of mscorlib. I’ll attempt to show below that this has led to a better debugging experience.

Better Debugging

In the release case, we can attach with Visual Studio after the warm-up period described above. Using the disassembler pane, we see that the code for our method looks like this:

(click on the image above for to enlarge)

We can see that the small method which calls WriteLine has been inlined, and that the stack trace doesn’t show the call into Console.WriteLine.

If we now run the Debug version, we see that there is no inlining happening, and mscorlib is less heavily optimised, so the stack trace is more accurate. This lack of optimisation is essential for being able to accurately debug with a minimum of hassle.

(click on the image above for to enlarge)

The big question is this: can we take the Release build and get the same debugging experience?

First, we can try setting COMPLUS_ZAPDISABLE, which prevents the system loading ngen’ed assemblies. This needs to be set before the point that the loading is triggered by the jit.

This leads to the following set of loaded modules, which I got by letting the release build run and then attaching windbg:

(click on the image above for to enlarge)

And if we attach from Visual Studio, we see the following:

(click on the image above for to enlarge)

We can see that the ngen’ed image hasn’t been loaded, but inlining has still taken place.

The second trick is to set up an ini file to control the optimization for jitted code. In this case, we’ll be setting it against the top level application – it has the same name as the file but with the exe or dll extension replaced with ini. Into it, we can put some configuration options; one saying that we’d like to track the machine-code-to-IL relationship, and another to turn off optimisations.

Adding this .ini file has a dramatic effect on the debugging experience.

(click on the image above for to enlarge)

Notice that no inlining has happened inside the user code, and we now get a faithful stacktrace for mscorlib.

Back to the lab!

As a further experiment, we can unset the COMPLUS_ZAPDISABLE, which leads to the ngen’ed mscorlib being reloaded, though the inlining has still been turned off:

(click on the image above for to enlarge)

If we take a small example project, the COMPLUS_ZAPDISABLE noticeably changes the behaviour so that there are many more places where we can effectively set the next statement in the code. For a simple project using the in-built WebDev webserver, if the devenv.exe that launches it was launched in a COMPLUS_ZAPDISABLE environment, then stepping into something like mscorlib is a lot better. Unfortunately, the experience doesn’t become “full’ until you put an .ini file next to the mscorlib to ensure proper stepping and ‘move next statement’ behaviour. Hence we seem to need both the environment variable and the ini file to get the best results.

We should also point out that, in the above experiments, we have been improving the behaviour when we attach the debugger after the application has been running for a while, and so jitting has already taken place. If you are debugging into a project by launching it from Visual Studio, then the fact that the debugger is attached when the jitting happens also improves the debugging experience. The extra complication in that scenario is that there is a hosting process which is used by Visual Studio to provide debugging – turning this off can also be useful.

I was also interested to see how to improve the experience for debugging a web application running under IIS, so I wrote a simple web application with a simple button on the main page, and the following code behind. Console.WriteLine is a common theme in these examples because it gives us an easy way to get into mscorlib.dll, and the WriteLine method makes a call to another method, so we can see if this call gets inlined (allowing us to see if optimisation is happening).

The loop is handy, because we can easily identify the w3wp.exe process that is hosting the application by seeing which one starts consuming CPU after the button is hit in the ASP.NET application.

A little help from Microsoft

I was a little worried about tweaking the setting for the w3wp.exe process, which is used by IIS to host the CLR running the web application. However, while looking around, I came across a script that Microsoft provides to aid with the profiling of .NET Web Applications:

c:/Program Files (x86)/Microsoft Visual Studio 8/Team Tools/Performance Tools/VSPerfCLREnv.cmd

This also sets various environment variables to control loading of the CLR Profiler around a re-launch of the application. The CLR loads a profiler dll as a COM component, if directed to do so at startup time by environment variable settings.

The script also controls the environment variables for services using the following part of the registry.

(click on the image above for to enlarge)

With this in mind, I went into the registry, added a setting of COMPLUS_ZAPDISABLE to 1, and then killed the w3wp.exe process, and the svchost process that was its parent. I did this using the process explorer tool from SysInternals, which allows you to easily see the relationship between running processes, and which also allows you to see the environment variable settings for a given process. This tool makes it easy to check that the changes have taken effect.

When I hit the web page again, w3wp.exe is re-launched and process explorer shows that the setting has taken effect:

(click on the image above for to enlarge)

Attaching windbg to the w3wp shows that there is no ngen loading for the IIS process:

(click on the image above for to enlarge)

Using Process Monitor, you can also see the process probing for .ini files next to all of the assemblies that it jits. Going into the GAC and placing a suitable .ini file against the relevant assembly, in this case mscorlib.dll, allowed me to later attach with Visual Studio and get a good debugging experience – stepping was accurate, variable values were always available, and ‘set next statement’ worked effectively.

Whereas in the case of the simple windows forms application, placing an .ini file against the top level assembly seemed to affect the behaviour of the jit for the loaded modules, in the case of the w3wp.exe, the only .ini files that are probed are the ones that are next to the loaded assemblies (included those that are dynamically generated by ASP.NET)

The final question is whether we need to set the debug property in the Web.Config:

<system.web>

<compilation debug=“true” targetFramework=”4.0″ />

And I don’t yet have a particularly good answer for that, though I imagine it affects at least the setting of the compiler when ASP.NET generates the application assemblies. Setting it and then attaching windbg to the resulting w3wp.exe shows that the ngen images are being loaded:

(click on the image above for to enlarge)

… So it certainly doesn’t turn off all optimization. I’ll need to do more work to find out exactly what it does do.

The Takeaway

In summary, if you want to get a better debug experience for debugging retail builds, you need to make sure that COMPLUS_ZAPDISABLE is set, and probably place .ini files in the right place (which is most likely next to all of the assemblies your process is going to load). This needs to be done in advance, or at least before the assembly is loaded in order to get the best experience.

Hopefully you’ll be able to use this method right away, and we’re working on getting as much of this automated in .NET Reflector as possible. And as I said at the start, this is all rather experimental, so all feedback is welcome.

We released a patch for EAP build 2 this afternoon, and we recommend you grab it.

Due to an entertaining quirk, the async functionality Clive was working on didn’t actually play nicely on our users machines. Luckily, Clive very quickly figured out why, and today’s build fixes the issue. So, with the latest release, you’ll be able to see the very early async support we’ve been working on (please bear in mind that we’re only talking about a small subset of async functionality at this stage).

As an added bonus, Nigel has also been busy, so you’ll see some small enhancements to the Dev11 theming as well.

Take the new build for a spin, please let us know what you think, and have a great weekend

Cheers,

Chris

Visual Studio Dev 11 looks…. different.  If you’ve not seen it, then you’re in for a surprise (you can download the latest VS11 Beta from a link at the bottom of this post). It’s gone monochrome, with no colour in most of the icons, and colour is only used when you really need to look at something (apparently). The other new addition to the look is the idea of Themes. Dev 11 ships with a light theme and a dark theme (Must. Resist. Force. Comparisons.), which basically amount to light grey or dark grey.

When I first started coding, it was always light text on a dark background (my amstrad CPC had a monochrome green screen – we couldn’t afford the colour version), and later my xemacs editor was set to roughly the same. So when I first came to visual studio, I hated the sea of white burning my eyes; and now I’m not sure if I want to go back. On a more immediately pressing note, as we have the Reflector object browser inside visual studio, it stuck out like a sore thumb with its white background, so I was tasked with investigating how to hook into the new Dev 11 themes, so it doesn’t look so out of place.

Dev 11, like 2010 before it, uses WPF. At least, if you’re writing an extension and add a new tool window, you’re invited to fill it with some XAML. In theory then, there are ways to just pick up the default theme colours (and ways to create new ones if needed).

However, most of the reflector UI was written some time ago in WinForms, and whilst we’d like to replace it with glorious WPF, that isn’t on the cards for this version.  Luckily, the Dev 11 SDK adds an API call to ask about various theme colours, and a hook to know when it’s changed.

So in this EAP, the Reflector object browser now at least changes its basic text and background colour to try and blend in. There is more to do here, but I had other investigations to look at before finishing that work (around the upgrade/update process, which in parts, quite frankly, currently sucks a bit).

Clive has been much more productive – he’s added basic C# 5 async support (I can’t wait to actually be able to use that feature, it will make certain things so much easier).

So head over to the EAP page and take a look, and have a play with some C#5 features.

Nigel

If you’ve ever wondered about .NET memory management, or had to get into the guts of your code to track down a memory leak, or wanted to make sure that your code performs as fast as possible, and with a small memory footprint, then I’ve got a book you should read. At the risk of being biased, it’s a book which I edited, and took from concept to print.

More to the point, it’s an eBook which is currently free to download: “Under the hood of .NET memory Management” by Chris Farrell and Nick Harrison. The book normally retails on Amazon for about $22, but you can download it for free (split into two parts) from the Red Gate website.

The book is part of an on-going project by Red Gate to help .NET developers learn more about .NET memory management (and thus write better code or debug issues faster). The front-man for this is Ricky Leeks, who (with a little help) regularly sources and publishes substantial .NET content.

If you want to know what’s on offer, here’s a quick summary:

Chris Farrell opens up with some great chapters laying out the .NET memory management model, and closes the book with some deeper dives into the Windows memory model and advanced .NET memory considerations like parallelism and 64-bit vs 32-bit. In the middle, Nick Harrison (who is a regular author over on Simple-Talk), walks through .NET memory troubleshooting and some handy platform-specific tips covering everything from ASP.NET to WPF.

“Under the hood of .NET memory management” is pretty comprehensive, and I’d strongly recommend it to anyone who wants to take their debugging and development up a notch (and not just because I worked on it). Grab your free copy, and check out Ricky Leeks’ top tips (which are regularly updated, and well worth a read).

EDIT: Part 2 of the eBook is now available, along with a link back to part 1 if you missed it.

We’ve been a bit quiet on the EAP front recently, and there’s a reason for that. The rest of the team and I feel like we’ve spent the last fortnight locked in a meeting room. In hindsight, that’s substantially because we have. All I can see when I close my eyes is post-it notes, but we’re getting a lot closer to scoping out version 8 of Reflector.

V8 is all kinds of exciting, but still very much at the on-paper stage. But somehow, in the midst of all the planning, and sketching, and brainstorming, and well-intentioned bickering, Clive, Nigel, Ruchika, and Nick have shipped a new EAP.

The version 7.6 EAP is the first slice of our support for Visual Studio Dev 11, .NET 4.5, and C# 5

Reflector’s Visual Studio integration is now working in Dev11, so you can decompile code and start to debug it within the new VS beta. You can explore the changes in the .NET 4.5 framework too, and Clive has a blog post coming about this shortly.

Because it’s our first EAP, it’s not all up and running yet. For example, we aren’t currently decompiling the new C# async/await construct, but we’ll be fleshing out the C# 5 support in the coming releases.

To get an idea of what’s planned for Reflector 7.6, take a look at the EAP page

A long, long time ago in a galaxy far, far away, Sean Hederman wrote an add-in for Reflector called Reflector.Diff. It was originally created to help him dive into code differences between Framework versions, but he figured it could also work nicely for people who wanted to diff their own assemblies.

We got in touch with Sean, and he gave us some more details into how he developed the Algorithm and UI in Reflector.Diff 2

To perform the diffs, I used an excellent library by Michael Potter which described how to create a diff engine. I modified it (with his permission), and hooked it into .NET Reflector (with Lutz Roeder’s very patient help); suffice to say, this compact little tool became pretty popular. I have no idea how popular because I wasn’t tracking downloads or anything like that, but I certainly got a lot of link love for it (although to my now-defunct dotnet.org.za blog – lesson learned: don’t put your work under the control of other people).

Anyway, bygones.

After a while, I decided it was time for a revamp of the project. I wanted Diff to work on the newest and coolest version of Reflector, I wanted to get the UI updated, and I wanted to make it fast. Damn fast.

This is a story, not about me, but about some very clever people and their very clever algorithms.

In the beginning was the algorithm

All differencing algorithms, given 2 inputs, attempt to try and find a set of modifications which will turn Input A into Input B.

Counter-intuitively, most difference algorithms focus not so much on finding a set of differences as finding the similarities between the two inputs; this is known as the Longest Common Subsequence problem. Think about it: if you find the commonalities; then all the bits that aren’t common are the changes. If the change is found in the source, but not in the destination, it’s a deletion, and if vice versa, it’s an insert.

As I mentioned, the algorithm I found for Reflector.Diff version 1 was written by Michael Potter, and he kindly allowed me to use it to build my original differencing engine. His algorithm was, in turn, based on one by Aprenot, which was all fine, considering my original intended purpose for the tool, but there’s always room for improvement.

More recently, I wrote a little test harness running diffs against a large project and checking the performance. For most purposes, the original version of Reflector.Diff was good enough for my needs; but I noticed that sluggishness would start to creep in for large diffs (such as looking at the System namespace in mscorlib). With a more detailed analysis, I found that it became slower when given larger texts and more changes within those texts, as would be expected. It also seemed to fall off a cliff at about 4,000 lines (but admittedly, I only tested up to 5,000 lines).

Speed is everything

I did a little digging around and found a well-known algorithm by Eugene Myers, as well as some little-known optimizations to this algorithm (designed by Neil Fraser) that help speed it up significantly in the most common scenarios. The new engine looked good, so I slapped it into Reflector.Diff and reran my tests. The question is, did it help?

In 42% of cases, my new algorithm was actually slower by an average of 622μs per file. Not ideal, but not too bad, either. And in the 58% of cases when it was faster? In those cases, it averaged 64ms faster.

To put that in perspective,  in the58% of cases when it was faster, it was 100 times faster than the old algorithm. Overall (i.e. averaging across all the test scenarios), the new algorithm worked out to be about 9 times faster. So, for a set of 100 files totalling 140,000 lines, it compared them in 0.76 seconds, as opposed to the 7 seconds it would take the original algorithm. I excluded file access times from these calculations, so the figures I’m bandying about were for the straight line comparison of sets of two large strings, held in memory.

Naturally, I’m pretty happy with the improvement, especially considering the scare I originally had while working out the performance benchmarks:

<flashback>

…I did a set of trial runs once I’d initially worked out how to build my performance improvements, and the new algorithm was vastly slower. Hundreds of times slower, in some cases.

I broke out my trusty ANTS Performance Profiler, compared the two algorithms, and found that, for all of its theoretical improvements, my new design was doing hugely more work. A little spelunking through the call stack and I came to the reason why: the old algorithm was differencing the files on a line-by-line basis, and the new one was doing it character-by-character. Once I changed the new one to work line-by-line, I started getting much better figures. I have no idea how long I’d have flailed around if it hadn’t been for that “oh crap” epiphany looking at line hit counts in ANTS.

560,000 iterations is probably not a good sign for finding differences in a single file, even if it is a couple thousand lines.

</flashback>

Speed isn’t everything

On the other hand, we also need to consider the tried-and-tested technique of faking performance, which I’ve written this before. There are two psychological considerations to bear in mind.

Firstly, when people see your app stop responding (hanging), they get a negative impression of its performance. Secondly, people perceive operations accompanied by progress bars as being faster than the exact same operation without a progress bar.

However, I didn’t want to just pop up a progress bar willy nilly whenever Reflector.Diff was doing anything at all – that would be a User Experience mess, and I wanted to use my new-found knowledge wisely. So, I created a BackgroundWorker subclass to handle the Differencing operation for me, and designed it to pop up a screen with a progress bar, but only if the operation has taken longer than one second.

This way, we get the best of all worlds; a responsive UI, coupled with a progress bar if it starts taking too long. The progress bar itself? Eye candy, nothing more – there for the sole purpose of implying that the application is working faster than it actually is. Or rather, of giving the user confidence that the application is working, not hanging.

The takeaway

Diff is designed to do one thing, and one thing well: compare two assemblies and display the differences between them. With that in mind, the work I’ve done to enhance Reflector.Diff is to make it easier and faster to use – take it for a spin, and I hope it works well for you.