Rick Byers : CLR

Quickly seeing where an exception may land in the debugger

rmbyers — Tue, 01 Sep 2009 08:08:52 GMT

A co-worker asked me recently how he could predict where an exception that was about to be thrown would land while debugging a managed application. The real answer to this question is “you can’t – step into the throw and see”. The EH system in the CLR has lots of complicated algorithms for determining this, and it needs to interact with other code on the stack (eg. there may be some native code with it’s own SEH filter that can do arbitrary logic). Luckily, unlike for native debugging, managed debugging can generally “step into” exception throws and reliably land in the handler.

But occasionally people still find themselves looking up the callstack, searching the code for ‘try’ blocks that are active. Surely there’s a way to automate that? Of course the debugger has all the information necessary to automate that, but unfortunately the VS debugger is not easily extensible in this way, so there’s not a lot you can do from the debugger process. However, as usual, func-eval offers a nice work-around for the lack of easy extensibility. Using the technique in my “Run-time exception checking” post, we can func-eval code which gets the EH handler info for the current stack and displays it nicely in the watch window. I’ve posted a sample (source and binary) which does that here. To use it, download ExceptionHandlerInfo.dll, and then while stopped in the debugger enter Assembly.LoadFrom(@"c:\mypath\ExceptionHandlerInfo.dll") into the immediate window to get it loaded into the debuggee process. Now, whenever you want to quickly see what handlers are active on the current stack, you can enter “Microsoft.Samples.ExceptionHandlerInfo.EHInfoCollector.GetActiveEHClauses()” into the watch window:

In this example, we can see that there is first a “catch System.ArgumentException” at Program.cs line 35 in method '”Program.Catcher” which is the 2nd (#1) frame on the current stack. Above that on the stack there is a “catch Exception” and a “Finally” block in the “Program.Main” method, and then a “Finally” block inside the VS hosting process code (for which we don’t have PDBs to provide a source location).

You can drill info EHInfo objects further if you want more details on a particular frame:

And if you want to automate scanning all the active EH clauses for the one most likely to catch the currently active exception (eg. when stopping on first-chance exceptions), you can enter “Microsoft.Samples.ExceptionHandlerInfo.EHInfoCollector.GuessCatchHander($exception.GetType())”:

Now someone just needs to integrate this with a VS macro so I can jump to the most likely catcher with a single keypress ;-)

New interviews with my CLR team members up on Channel9

rmbyers — Tue, 09 Jun 2009 07:19:00 GMT

There are a bunch of great new CLR v4-related video interviews up on Channel9. In particular:

Jon, Thomas and Dave from my team (CLR diagnostics) discuss the advancements in debugging and profiling APIs in v4
Simon and I discuss in-process SxS (ability to have multiple CLRs loaded in the same process). You may have noticed the lack of diagnostics blog entries from me lately - that's because I've mostly been spending my time helping out with this important feature.

There are a bunch of other ones that look good (eg. "Type equivalence" and "No-PIAs" are closely related and an interesting discussion), but I haven't gotten a chance to watch them yet.

AnyCPU Exes are usually more trouble than they're worth

rmbyers — Tue, 09 Jun 2009 07:13:00 GMT

Over the past few months I've had some interesting debates with folks here (and some customers) about the cost/benefit trade-off of "AnyCPU" (architecture-neutral) managed EXEs. I think we've converged on a consensus that most of the time they're not what you want and so shouldn't be the default in Visual Studio. I suspect this topic may interest (and even shock) some folks, so I thought I'd share the rationale with you here.

Background - .NET and 64-bit
With the introduction of Win64 (64-bit versions of Windows), PE files (EXEs and DLLs) can be marked either as 32-bit OR 64-bit. When a 32-bit EXE is launched on Win64, it runs in "the WOW" (Windows-32 on Windows-64) to present an illusion of a 32-bit operating system to the process. Generally only 32-bit DLLs can be loaded into a 32-bit process, and only 64-bit DLLs can be loaded into a 64-bit process. When the CLR added 64-bit support in version 2.0, we had an interesting decision to make. Should we mark our binaries as 32-bit or 64-bit by default? Techncally managed binaries had no hard CPU dependency, so they could be either (actually there is a small loader thunk, but that's unused on any newer OS including all the 64-bit ones since the OS loader knows about managed EXEs explicitly). Since we wanted people to be able to write .NET libraries that they could re-use from both 32-bit and 64-bit processes, we worked with Windows to extend the OS loader support to enable architecture-neutral ("AnyCPU") PE files.

Managed architecture-neutral DLLs are fairly straight-forward - they can be loaded into either 32-bit or 64-bit processes, and the (32-bit or 64-bit) CLR in the process will do the right thing with them. AnyCPU EXEs are a little more complicated since the OS loader needs to decide how to initialze the process. On 64-bit OSes they are run as 64-bit processes (unless the 'ldr64' master OS switch says otherwise), and on 32-bit OSes they are run as 32-bit processes. In Visual Studio 2008, AnyCPU is the default platform for C# and VB projects. This means that by default, applications you compile will run in 64-bit processes on 64-bit OSes and 32-bit processes on 32-bit OSes. This is fine and does often work alright, but there are a number of minor downsides.

The costs of architecture-neutral EXEs
There are a number of reasons to think that AnyCPU should not be the default for EXEs. Don't get me wrong, 64-bit hardware and OSes are definitely the way to go (in fact all 4 of my development machines have 64-bit OSes on them - I stopped bothering to install 32-bit OSes years ago). But that doesn't necessarily mean that most processes should be 64-bit. Here's the list I've been using in our discussions to justify making x86 the default for EXE projects in Visual Studio:

Running in two very different modes increases product complexity and the cost of testing
Often people don't realize the implications on native-interop of architecture-neutral assemblies. It means you need to ensure that equivalent 32-bit and 64-bit versions of the native DLLs you depend on are available, and (most significantly) the appropriate one is selected automatically. This is fairly easy when calling OS APIs due to the OS re-mapping of c:\windows\system32 to c:\windows\syswow64 when running in the WOW and extensive testing the OS team does. But many people who ship native DLLs alongside their managed app get this wrong at first and are surprised then their application blows up on 64-bit systems with an exception about their 32-bit DLL being in a bad format. Also, although it's much rarer than for native-code, pointer-size bugs can still manifest in .NET (eg. assuming IntPtr is the same as Int32, or incorrect marshalling declarations when interopping with native code).
Also, in addition to the rules you need to know to follow, there's just the issue that you've now really got twice as much code to test. Eg., there could easily be (and certainly have been many) CLR bugs that reproduce only on one architecture of the CLR, and this applies all the way across the stack (from OS, framework, 3rd-party libraries, to your code). Of course in an ideal world everyone has done a great job testing both 32-bit and 64-bit and you won't see any differences, but in practice for any large application that tends not to be the case, and (at Microsoft at least) we end up duplicating our entire test system for 32 and 64-bit and paying a significant ongoing cost to testing and supporting all platforms.
[Edit: Rico - of CLR and VS performance architect fame - just posted a great blog entry on why Visual Studio will not be a pure 64-bit application anytmie soon]
32-bit tends to be faster anyway
When an application can run fine either in 32-bit or 64-bit mode, the 32-bit mode tends to be a little faster. Larger pointers means more memory and cache consumption, and the number of bytes of CPU cache available is the same for both 32-bit and 64-bit processes. Of course the WOW layer does add some overhead, but the performance numbers I've seen indicate that in most real-world scenarios running in the WOW is faster than running as a native 64-bit process
Some features aren't avaiable in 64-bit
Although we all want to have perfect parity between 32-bit and 64-bit, the reality is that we're not quite there yet. CLR v2 only supported mixed-mode debugging on x86, and although we've finally added x64 support in CLR V4, edit-and-continue still doesn't support x64. On the CLR team, we consider x64 to be a first-class citizen whenever we add new functionality, but the reality is that we've got a complicated code-base (eg. completely separate 32-bit and 64-bit JIT compilers) and we sometimes have to make trade-offs (for example, adding 64-bit EnC would have been a very significant cost to the JIT team, and we decided that their time was better spent on higher priority features). There are other cool features outside of the CLR that are also specific to x86 - like historical debugging in VS 2010. Complicating matters here is that we haven't always done a great job with the error messages, and so sometimes people "upgrade" to a 64-bit OS and are then disgusted to see that some of their features no longer appear to work (without realizing that if they just re-targetted the WOW they'd work fine). For example, the EnC error in VS isn't very clear ("Changes to 64-bit applications are not allowed"), and has lead to some confusion in practice. I believe we're doing the right thing in VS2010 and fixing that dialog to make it clear that switching your project to x86 can resolve the issue, but still there's no getting back the time people have wasted on errors like this.

When do 64-bit processes make sense?
The biggest benefit of 64-bit processes is obivously the increased address-space. Many programs are bumping up against the 2GB limit of traditional 32-bit processes (even though they may not be using anywhere near 2GB of RAM). The first thing that should usually be done to such programs is to have them opt-into 4GB mode so that they can get a full 4GB of address space when running in the WOW on a 64-bit OS. If more address space would be useful, than sometimes the right thing to do is to decide to target JUST x64 and avoid the cost of supporting two platforms (Exchange Server has done this for example). But often the right trade-off is to support both 32-bit and 64-bit processes, so that you can still run on 32-bit OSes, but take advantage of the large address space when running on 64-bit OSes.

This is where architecture-neutral assemblies make a lot of sense. If you're a library vendor, then building as AnyCPU and testing on all supported architectures absolutely makes sense. If you are producing an application EXE and have reason to believe your application may need more than 4GB of address space, then switching to AnyCPU may be a good idea. But, as for native, really needing this much address space is still pretty rare and usually only necessary for large complex applications, and so opting-in to AnyCPU should really not be a burden. You've got to think about what you want your testing strategy to be anyway, so making this step explicit seems to make sense.

Another argument for AnyCPU being the default which I think deserves serious thought is the impact on the Windows ecosystem and desire to move to a pure 64-bit world someday. No doubt the WOW adds extra complexity and confusion and it would be great to just kill it as quickly as we can. I definitely agree with that sentiment, and we should work to get to that place. But realistically, we're a long way from being able to seriously consider killing the WOW from Client OSes (it is already optional on Server Core - but how many EXE projects are really server apps?). Here are some things that need to happen before we can seriously consider killing the WOW: Windows needs to stop shipping new 32-bit-only client OSes, most new native applications need to fully support 64-bit, all popular existing apps need to move to 64-bit (including VS), etc. I'm sure we'll get there some day (as we did with the 16-bit to 32-bit transition), but I don't think defaulting to x86 in Visual Studio is going to be a major barrier here. When it starts looking like killing the WOW may be a feasible option in the near-future, then perhaps we should probably just switch the default to be x64-only, and let people opt-in to supporting 'legacy' 32-bit platforms.

So how is Visual Studio 2010 and .NET 4.0 changing?
We are not changing anything here in the CLR or compilers - they continue to support both modes. However, after discussing these issues, VS project system team has agreed to make EXE projects default to the x86 platform in VS 2010. Unfortunately there is a bug in Beta1 where ALL managed project types default to x86 (I take the blame for this - I didn't think to check DLL projects when validating the changes were in). AnyCPU is still incredibly valuable for DLLs (you may not always know what processes it will be loaded into), and since it just enables a DLL to be used in more places without actually affecting the bitness of the process, there isn't sufficient justification to disable AnyCPU by default. This bug has been fixed, and so the plan is to ship Beta2 with just the EXE projects defaulting to x86, and all DLL projects remaining as AnyCPU.

That said, there's still time to get customer feedback and so this could change for VS2010 RTM. We've already heard a lot of surprised reactions where people seem to think we're treating x64 as second-class, or otherwise resisting the natural evolution to 64-bit systems. Many people have mentioned that 32-bit hardware and 32-bit OSes are quickly becoming a thing of the past. I agree completely and this is a good trend, but it's completely orthogonal. 64-bit hardware and OSes give us the ability to run processes with 64-bit address spaces, but they by no means make using them a requirement or necessarily even preferable to using the WOW. The Windows folks did such a good job building the WOW, and the CPU designers did a good job supporting 32-bit modes (for x64 at least, ia64 is a different story), so there aren't a lot of downsides to relying on them. Someday I'm sure we'll decide the WOW has outlived it's useful lifetime and Windows should kill it rather than maintain it, but I'm sure that day is a LONG way off (eg. when did Windows finally remove support for 16-bit processes, and did anyone really notice?).

When I actually get into debating this issue on it's merrits, almost everyone I've talked to has agreed that making x86 the default seems to be the best choice - at least for the next several years. This, by no means signifies decreased support for 64-bit OSes and frameworks. I can tell you that most CLR developers work almost exclusiviely on x64 OSes, and do much of their testing and development with 64-bit processes. Our testing (like most teams at Microsoft) treats x86 and x64 as first-class and generally equal-priority (except for products like Silverlight of course that are still x86-only). But when we put ourselves in the shoes of our users and study this issue on it's merrits, it just makes practical sense for x86 to be the default for EXE projects.

Let me know if you agree or disagree. Regardless, I hope you enjoy using VS2010 - it's really shaping up to be a great release!

[Edit - added section about helping the ecosystem move to all 64-bit]

Getting good dumps when an exception is thrown

rmbyers — Tue, 23 Dec 2008 09:03:00 GMT

Often, when an unexpected exception occurs in production code, applications want to generate (and potentially report) some sort of diagnostics information. Sometimes people just want to write to a log file (and perhaps pop some error dialog) for support purposes, but more sophisticated applications will want to have a mechanism to save a minidump of the crash (and perhaps report it back to the author of the software) so their developers can debug the problem. Windows Error Reporting is usually the best way to do this (the CLR v2 and above integrates with WER for all managed apps), but people also like to build their own custom solutions. By the way, if you want to build your own error-reporting mechanism that captures dump files, I suggest you use a helper process to suspend all your threads and call MiniDumpWriteDump, rather than calling it directly in-process (see this discussion for example).

As a very simple example, you may want to use the FailFast API to say "exceptions should never escape here, if it does present an error to the user and let them report the problem back through WER":

try
{
    MyCode();
}
catch (Exception ex)
{
    // We don't expect any exceptions - generate an error-report if we see one
    System.Environment.FailFast("Unexpected exception: " + ex.Message);
}

Unfortunately, this won’t give you a very useful dump in your error-report. The problem is that by the time the catch block has been started, the stack frames showing how the exception occurred are no longer available (see below for details). Managed exceptions are built on Windows Structured Exception Handling, and so have the same two-pass model. ‘catch’ blocks are executed on the second pass, but really what we want here is to generate our error-report on the first-pass (before EBP gets reset). You are probably used to seeing this when debugging your code. If you really want to see what caused an exception, you have to tell Visual Studio to stop on first-chance exceptions – by the time you stop in the catch block, the code that threw the exception is no longer visible on the callstack:

Luckily the CLR provides a way to do this called managed exception filters. Unfortunately C# doesn’t expose a way to use them. The simplest way to use a filter from C# code is to write a simple helper function in VB.Net. The ‘When’ portion of a ‘Catch’ clause in VB.Net is an exception filter. Here’s a simple helper I wrote for this that I can easily call from C#:

Public Class ExceptionUtils
    Public Shared Sub Filter(ByVal body As Action, ByVal filter As Func(Of Exception, Boolean), ByVal handler As Action(Of Exception))
        Try
            body()
        Catch ex As Exception When filter(ex)
            handler(ex)
        End Try
    End Sub
End Class

Now I can re-write my code that triggers error-reporting on exceptions as follows (referencing the VB assembly with the above code):

ExceptionUtils.Filter(() =>
{
    // This is the body of the 'try'
    MyCode();
}, (ex) =>
{
    // This is the body of the filter
    System.Environment.FailFast("Unexpected exception: " + ex.Message);
    return false; // don't catch - this code isn't reached
}, null); // no catch block needed

Now, running under the debugger I can see the original call-stack, and even inspect locals/args on it (note the ‘Throw’ frame in the callstack, and the visible arg value for a – I can also click on this frame and poke around as normal):

So that’s basically it. Now debugging at the point of the FailFast (whether live, or with a dump file) will let you see all the data on the stack leading up to the cause of the exception. Note that if exceptions are thrown and caught within the body they don’t trigger the filter, the filter is just like a catch block in that it cares about exceptions that “reach” it – which is usually what you want (eg. it’s not normally any of your concern if the implementation of some external API you call happens to throw and catch an exception – as long as it doesn’t propagate back to your code).

Additional Details

It might be a bit of a pain to have to deploy this extra assembly with your application, but there are other options for using an exception filter in your C# app:

Statically link the C# and VB code together into a single (single-file) assembly (eg. using ILMerge, Link.EXE, or a ILDasm/ILAsm round-trip)
Use a tool to re-write your assembly after it’s built to inject the filter. Gregg on the VS debugger team posted such a tool awhile back.
Use Reflection.Emit to dynamically generate the IL code for the filter at run-time.

Also, one note about using FailFast with managed error-reporting. Error-reports are grouped by their ‘bucket parameters’. The buckets generated for System.Environment.FailFast(string) are always the same for any given call-site (basically just the address of the call, and a the string ‘FatalError’ for the exception type. Ideally what you’d like to do here is use the buckets for the original exception (so that two different exceptions that trigger the same call to FailFast will show up as two different problems). We’ve added a FailFast overload that takes an Exception object in .NET 4.0 that does this.

All I’ve talked about so far are simple single exceptions. Exceptions can also be caught and re-thrown ('”throw;” in C#) or wrapped in an outer exception which is thrown (“nested exceptions”). Unfortunately if that happens within the body you pass to ExceptionUtils.Filter, by the time the filter is invoked, the first exception has already been thrown and caught and so the stack you see is at the point of rethrow. There’s no good way that I’m aware of to get the stack from the original throw point in this case (although it’s something I’d like to get added to the CLR in a future version). This is particularly troublesome when using .NET APIs that catch-and-rethrow like Reflection (which wraps all exceptions in a TargetInvocationException). The best thing I can suggest is to put filters inside any such point, so you filter sees the exception before it’s caught.

If you want to be really hard-core about exceptions, you could use some sort of exception monitoring solution that notices as soon as an exception is thrown. For example, you could generate a dump from a vectored exception handler, but you won’t have access to the managed System.Exception object here. Better yet, you could write a tool that uses the debugging APIs to watch for first-chance exceptions and log details about them (perhaps including dump files) such as Mike Stall’s MDbg exception harness.

Above I said that in a catch block the frames leading up to the throw are no longer available on the stack. Technically, they’re still on the stack (the stack isn’t really “unwound” until you leave the catch block), but the frame pointer has been reset to point to the frame of the catch block (so that locals are available, etc.). This is true for native code as well, but powerful low-level debuggers like WinDbg allow you to switch the current context to that where an exception was thrown (.cxr command in windbg) if you have the CONTEXT pointer (which might even be saved into the dump for you – which you can access with .ecxr). An additional complication with managed code is that once the frame pointer has been reset, we no longer report any “roots”on the stack to the GC, so if a collection occurs there may actually be garbage pointers on (or available from) that masked portion of the stack. So it’s not a simple feature to expose some way to see the callstack starting from the throw site (unless we disabled inspection all locals and arguments, or allowed it to fail unpredictably). We’ve toyed with ideas for relaxing this in the CLR, but there won’t be any improvements here in CLR v4.

At the PDC this year I learned that this general class of problems (error reporting / logging in the face of exceptions) is something that many customers are very interested in. I don’t think we’ve got a ton of great documentation on this today. Going forward, you should expect to see more documentation, blog entries and new features from the CLR team in this area. Feel free to let me know if there’s anything in particular you’d like to know more about.

CLR 4.0 advancements in diagnostics

rmbyers — Fri, 31 Oct 2008 00:30:00 GMT

We announced at PDC today that we're making some significant advances in diagnostics tool support for CLR v4! In particular, we've been investing heavily in improving our support for production diagnostics scenarios over the past couple years. I'm excited that we're finally able to start talking about it!

Here's a quick list of some of the things we're doing - stay tuned here, Dave's blog and Mike's blog for more details. Also feel free to ask questions about our strategy and specific plans for new features on our forum (of course we still have a few things we're not ready to talk about yet). Of course, all of the features below are only available when targetting a process that is running inside version 4 of the CLR.

Managed dump debugging
Finally you'll be able to open crash dump files in Visual Studio and see managed state (stacks, locals, etc.) without using SOS. The key scenario we want to enable here is taking a dump of an app/server in production (perhaps in an automated way like Windows Error Reporting) and opening that dump in Visual Studio on another machine at some point in the future. We have a big piece of this working in the VS 2010 CTP, but we still have some work to do before beta (eg. the CTP supports dumps with full heap memory). The experience in VS is very much like being stopped at a breakpoint in a live process, except you can't say "go". Of course production code tends to have JIT-optimizations enabled, so the normal caveats about debugging optimized code apply here too (eg. may not see all locals). Also, you can't evaluate arbitrary expressions since there is no target process to call functions in (but we have some ideas for how we might compensate for this). But despite the caveats, this is still a huge feature that should really help improve production diagnostics scenarios. This work is actually the main visible piece of a much larger "out-of-process debugging" re-architecture we've been working on for years. This re-arch deserves a post of it's own so stay tuned.
Profiler attach (and detach) for memory diagnostics and sampling
One of the most common feature requests we hear from profiling tools is to be able to attach to a target process (today you have to set some environment variables at process start which cause your profiler to be loaded). Before you get too excited - this doesn't have everything you want. In particular, the CLR still doesn't have the ability to change the code of a method once it's been JIT-compiled (EnC is a very special case - not really applicable here). This means that IL instrumentation isn't available on attach, as well as a few other features (like object allocated callbacks). But basic memory diagnostics scenarios where the profiler inspects the heap, and simple sampling-based CPU profiling will now work on attach. We anticipate this will be useful in production scenarios - you can walk up to a server behaving badly and attach a profiler, collect some data, and detach - leaving the process in basically the same state it was before you attached.
[Update: See Dave's blog entry here for additional details on profiling API improvements]
Registry-free profiler activation
One major impediment to the sort of production scenario I described above is that today you have to register your profiler in the registry. In many production scenarios, making some change to the machine-wide system registry is very unappealing (will the dev remember to undo the change when he's done with the server, etc?). So to really enable production scenarios, we've also supplied a mechanism for running a process under a managed profiler (or attaching) without having to make any changes to the registry.
x64 mixed-mode debugging
This isn't really a production diagnostics scenario (although you can do x64 mixed-mode dump debugging), but is one of the main debugging feature requests we've gotten. With this feature, "mixed-mode" (native+managed) debugging will work for x64 processes in basically the same way it works for x86 today.
lock inspection
We're adding some simple APIs to ICorDebug which allow you to explore managed locks (Monitors). For example, if a thread is blocked waiting for a lock, you can find what other thread is currently holding the lock (and if there is a time-out).
Corrupted-state exceptions
This feature doesn't come from our team (it's part of the core exception-handling sub-system in the CLR), but in my opinion it's a huge improvement for diagnostics scenarios. Basically it means that "bad" exceptions (like access violations) that propagate up the stack into manage code no longer (by default) get converted into normal .NET exceptions (System.AccessViolation) which you can accidentally catch in a "catch(Exception)" clause. Basically, haivng a catch(Exception) which swallows AVs coming from native code is a bad thing because you're unlikely to be able to reason about the consistency of your process after the AV. The default behavior for such "corrupted-state exceptions" is now to fail-fast and send an error-report (just like in normal C++ programming). Of course, you can override this if you REALLY need to catch such an exception.

That's the overview of the main CLR v4 features that affect diagnostics. Of course there are also lots of other great things coming in CLR v4 and the rest of .NET Fx 4.0.

Func-eval can fail while stopped in a non-optimized managed method that pushes more than 256 argument bytes

rmbyers — Sun, 17 Aug 2008 02:55:00 GMT

In this blog entry, Mike describes that func-eval will fail when not a GC-safe point. In VS this results in the error "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized". Typically non-optimized (debuggable) managed code is compiled as "fully-interruptible" which means every point is a GC-safe point. However, occasionally I hear complaints that VS is giving the error even when in non-optimized code.

In CLR 2.0, the x86 JIT has a limitiation where it will fall back to partially-interruptible code if more than 256 bytes of arguments are pushed onto the stack (which is normally very rare). [Update: corrected claim that the limitation was introduced in 2.0, .NET 1.1 actually had an even smaller limit of 128 bytes]. For example, the code below passes two 128 byte structures by-value to the function 'BigFunc', and so is compiled as partially-interruptible which means FuncEval isn't necessarily possible at all points in the method.

In the above case, we can verify that the method Main is not fully-interruptible by using the GCInfo command in SOS:

.load sos
extension C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded

!GCInfo 003A00A4
entry point 003a0070
Normal JIT generated code
GC info 11e8a09800121a98
Method info block:
    method      size   = 0167
    prolog      size   = 32
    epilog      size   = 8
    epilog     count   = 1
    epilog      end    = yes
    callee-saved regs = EDI ESI EBX EBP
    ebp frame          = yes
    fully interruptible= no
    double align       = no
    arguments size     = 0 DWORDs
    stack frame size   = 44 DWORDs
    untracked count    = 1
    var ptr tab count = 1
    security check obj = yes
    exception handlers = yes
    edit & continue    = yes
    epilog        at   015F
    argTabOffset = 5

First we load sos in the immediate window, then get an address in the method of interest (eg. by looking at the value of the EIP register while we're stopped there) and pass it to the !GCInfo command. The "fully intteruptible=no" line is unusual for debuggable code (one way you can tell it's indeed debuggable is the "edit & continue = yes" which isn't normally the case in optimized code).

The other, more common, case where this happens is when calling a method with at least 64 arguments (each of 4 bytes). Having a method that takes 64 arguments seems poor style to me (hard to read), but I've seen such code from code-generation tools. Either way, passing 256 bytes by-value on the stack is generally a bad idea from a performance perspective anyway (it's a fair amount of copying of data). It's usually better to group the data into a class and pass that, and/or pass large value-types by reference (eg. with the 'ref' keyword in C#).

We're looking into relaxing this restriction in a future version of the CLR, but in the meantime if you run into problems with this, I suggest you refactor your code to avoid having methods that take 256 bytes or more in arguments. Perhaps somebody should write an FxCop rule for this.

Invoking a virtual method non-virtually

rmbyers — Sun, 17 Aug 2008 02:11:00 GMT

Method calls using the C# ‘base’ keyword get compiled to an IL ‘call’ instruction, rather than the ‘callvirt’ that is normally used. This is the one case in C# where a virtual method can be invoked without virtual dispatch. The CLR allows it to be used generally for non-virtual calls, but it’s unverifiable in other cases (see section 3.19 of the CLI specification partition III for the full definition).

One place this causes some pain is with func-eval. Func-Eval always does a virtual dispatch on virtual methods, which is why the ‘base’ keyword doesn’t work properly in the watch/immediate window in VS 2008. Mike Stall has a blog entry on this topic here: http://blogs.msdn.com/jmstall/archive/2006/06/29/funceval-does-virtual-dispatch.aspx

What Mike doesn’t mention is there is actually a work-around for this. First we need some mechanism to invoke a virtual method non-virtually, and the only one I could find was using Reflection.Emit / lightweight-codegen to emit a ‘call’ instruction. For example, the following method can be used to invoke any virtual method non-virtually:

/// <summary>
/// Call a virtual method non-virtually - like Reflection's MethodInfo.Invoke, 
/// but doesn't do virtual dispatch.
/// </summary>
/// <param name="method">The method to invoke</param>
/// <param name="args">The arguments to pass (including 'this')</param>
/// <returns>The return value from the call</returns>
static object InvokeNonVirtual(MethodInfo method, object[] args)
{
    // Reflection doesn't seem to have a way directly (eg. custom binders are 
    // only used for ambiguities).  Using a delegate also always seems to do 
    // virtual dispatch.

    // Use LCG to generate a temporary method that uses a 'call' instruction to
    // invoke the supplied method non-virtually.
    // Doing a non-virtual call on a virtual method outside the class that 
    // defines it will normally generate a VerificationException (PEVerify 
    // says "The 'this' parameter to the call must be the callng method's 
    // 'this' parameter.").  By associating the method with a type ("Program") 
    // in a full-trust assembly, we tell the JIT to skip this verification step.
    // Alternately we might want to associate it with method.DeclaringType - the
    // verification might then pass even if it's not skipped (eg. partial trust).
    var paramTypes = new List<Type>();
    if (!method.IsStatic)
        paramTypes.Add(method.DeclaringType);
    paramTypes.AddRange(method.GetParameters().Select(p => p.ParameterType));
    DynamicMethod dm = new DynamicMethod(
        "NonVirtualInvoker",    // name
        method.ReturnType,      // same return type as method we're calling 
        paramTypes.ToArray(),   // same parameter types as method we're calling
        typeof(Program));       // associates with this full-trust code
    ILGenerator il = dm.GetILGenerator();
    for (int i = 0; i < paramTypes.Count; i++)
        il.Emit(OpCodes.Ldarg, i);             // load all args
    il.EmitCall(OpCodes.Call, method, null);   // call the method non-virtually
    il.Emit(OpCodes.Ret);                      // return what the call returned

    // Call the emitted method, which in turn will call the method requested
    return dm.Invoke(null, args);
}

With a method like the above available, we can use statements like the following (in the program or in the immediate window) to invoke a method non-virtually (i.e. to simulate the ‘base’ keyword):

// Foo is some class that overrides ToString
Foo f = new Foo();
MethodInfo m = typeof(object).GetMethod("ToString", 
    BindingFlags.Instance | BindingFlags.Public);

// s1 will be the same as f.ToString - whatever Foo.ToString returns
string s1 = (string)m.Invoke(f, 
    BindingFlags.Instance | BindingFlags.InvokeMethod, null, null, null);

// s2 will be the return value from Object.ToString
string s2 = (string)InvokeNonVirtual(m, new object[] {f});

We can also avoid having to get the ‘InvokeNonVirtual’ method into the target program at all by entering code like the following into the immediate window (depending on what method you want to invoke, eg. this invokes 'ToString' non-virtually on object 'o').:

MethodInfo m1 = typeof(object).GetMethod("ToString", 
    BindingFlags.Instance | BindingFlags.Public);
DynamicMethod dm = new DynamicMethod("ToStringInvoker", 
    typeof(string), new Type[] { typeof(object) }, typeof(Program));
ILGenerator il = dm.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.EmitCall(OpCodes.Call, m1, null);
il.Emit(OpCodes.Ret);
string s3 = (string)dm.Invoke(null, new object[] { o });

Yes, I realize typing this into the immediate window whenever you want to say ‘base’ is kind of a pain (perhaps completely impractical). But the interesting thing here is that it means a debugger could build support for the ‘base’ keyword without any additional work from ICorDebug or the CLR! Of course, I still agree with Mike that it’s a reasonable feature-request to have func-eval support an option for non-virtual dispatch. I just don’t see it making its way to the top of our wish-list anytime soon (unless we get strong customer feedback of course).

This also raises an interesting question about the design of func-eval. Should we have just supported calling a few key reflection APIs and made all evals go through reflection? This certainly would have been simpler and more reliable for the CLR – otherwise we have to duplicate a lot of the logic about how to marshal values and call methods that Reflection already needs to have. Then again, there’s always going to be the challenge of marshalling between ICorDebugValue instances and objects in the target, and that’s a pretty big chunk of what’s required to make func-eval work.

Customizing PDB lookup for source information in StackTrace

rmbyers — Fri, 22 Jun 2007 08:49:00 GMT

The System.Diagnostics.StackTrace class in .NET can be used to generate a textual representation of the current callstack. This is used, for example, by Exception.ToString(). If requested by the caller, StackTrace can include source file locations (file names and line numbers, etc.) for each frame whose module has a PDB file available to the CLR. PDB files are designed to be used primarily in development-time scenarios, and so the idea here is that when you're developing or testing your application and it spits out an exception (eg. to a log file, or an unhandled exception to the console), it will help you to debug the issue if you can see exactly where in the leaf method the exception was thrown, and where exactly each child function was called (actually it's not technically "exactly" - if JIT optimizations are enabled the results may be approximate, and frames may be missing completely due to inlining). If you've done much .NET programming, you probably knew all this already.

The more interesting (and less well documented) question I want to address is where exactly you must place your PDB files for this to work. The CLR will look next to the corresponding module (DLL or EXE), and also check a few other standard locations (those local paths specified by the _NT_SYMBOL_PATH environment variable for example, and I believe the Windows system directory). In fact, it's not really the CLR controlling any of this, but the ISymUnmanagedBinder::GetReaderForFile API from diasymreader.dll, which itself is implemented on top of the IDiaDataSource::loadDataForExe API. Since this support for source locations is designed for development time, when you're generally running binaries you've just built - the PDBs are almost always next to the binaries and this works great.

Occasionally we get requests from people who like this feature but complain that the CLR isn't flexible enough to find their PDB files where they want to put them. Sometimes this stems from wanting to use this feature for something it wasn't designed, such as shipping PDBs with your product and logging/reporting errors from the field. For that scenario you're usually MUCH better off using Windows Error Reporting and minidumps. You generally do not want to ship your PDBs to your customers (they're big, and can make it easier to reverse engineer your code - although this is a much bigger concern for unmanaged C++ code than .NET code). In other cases, you may want to generate machine-readable stack traces (with module names, method tokens and IL offsets), and then post-process them using PDB files at your location to get source location information.

But, there are a few scenarios where it does really make sense to want more flexibility in how PDBs are located for the StackTraces generated at runtime. For example, I recently got a request through product support from a customer with a large test environment where they were deploying their actual product. They keep all their PDBs (1TB+ of them!) on a symbol server, and they would like to be able to use them to generate stack traces with source info without having to deploy PDBs to all their test machines (in the proper directories). Although the CLR doesn't support this directly, there isn't any reason you can't implement this yourself. The CLR StackTrace class exposes StackFrame objects which have all the information you need to map back to source addresses given an ISymbolReader instance. ISymbolReader instances can be created directly (controlling PDB location policy manaually with ISymbolUnmanagedBinder2::GetReaderForFile2) by calling into diasymreader.dll through COM interop. I've posted sample code for a StackTraceSymbolProvider class that does this here (using MDbg's COM interop wrappers for diasymreader.dll).

Here's an example of how this code can be used to print out a StackTrace from an Exception while explicitly controlling the directories searched (searchPath is a semi-colon separated list of directories including SRV* entries for symbol servers), and whether things like a symbol server will be checked:

            catch (System.Exception e)
            {
                st = new StackTrace(e, true);
                StackTraceSymbolProvider stsp = new StackTraceSymbolProvider(searchPath,
                    SymSearchPolicies.AllowSymbolServerAccess |
                    SymSearchPolicies.AllowOriginalPathAccess |
                    SymSearchPolicies.AllowReferencePathAccess |
                    SymSearchPolicies.AllowRegistryAccess);

                Console.WriteLine("Custom stack trace:");
                Console.WriteLine(stsp.StackTraceToStringWithSourceInfo(st));
            }

To get this flexibility you have to re-implement some of the formatting done by StackTrace.ToString(), but you might want the flexibility to control this anyway (for example, it's easy to include column numbers in addition to line numbers). It's non-trivial to wire this all up (especially if you're not familiar with COM-interop), but it's all plumbing really. Hopefully this sample code will save some of you the hassle of figuring out this plumbing yourself.

More on generic variance

rmbyers — Fri, 02 Jun 2006 04:44:00 GMT

In my entry on generic variance in the CLR, I said that you can’t convert a List<String> to a List<Object>, or even an IEnumerable<String> to IEnumerable<Object>. I should point out however that the real-world scenarios where you’d want to do this usually involve passing an object of a more specific type to an API that (for abstraction reasons) takes a less specific type. For example, say you have a class hierarchy like this:

abstract class Shape

{

public abstract double ComputeArea();

}

class Square : Shape

{

public Square(double height)

{

m_height = height;

}

public override double ComputeArea()

{

return m_height * m_height;

}

private double m_height;

}

class Circle : Shape

{

public Circle(double radius)

{

m_radius = radius;

}

public override double ComputeArea()

{

return Math.PI * m_radius * m_radius;

}

private double m_radius;

}

You’d like to be able to use it uniformly like this:

class Program

{

static void Main(string[] args)

{

List<Square> ls = new List<Square>();

ls.Add(new Square(2));

ls.Add(new Square(3));

double totS = GetTotalArea(ls); // won’t compile

List<Circle> lc = new List<Circle>();

lc.Add(new Circle(2));

lc.Add(new Circle(3));

double totC = GetTotalArea(lc); // won’t compile

}

public static double GetTotalArea( IEnumerable<Shape> l)

{

double total = 0;

foreach (Shape s in l)

{

total += s.ComputeArea();

}

return total;

}

This would only work if C# supported generic variance and IEnumerable was defined as IEnumerable<+T>. However, there is another option in this case. You could make GetTotalArea a generic method and rely on a base-type constraint:

public static double GetTotalArea<T>(IEnumerable<T> l)

where T : Shape

{

double total = 0;

foreach (Shape s in l)

{

total += s.ComputeArea();

}

return total;

}

Now the above Main method will work perfectly, you don’t even have to modify it to specify the type parameters (C#’s type inference can figure them out automatically). So although you're not really converting an IEnumerable<Square> to an IEnumerable<Shape>, you are able to use it that way.

This is certainly great. And in practice, most .NET developers will find the support in .NET 2.0 for generics to be more than powerful enough. However, if you’re trying to do some serious “generic programming” [3], or if you’re excited by programming language theory like I am, then this does still leave something to be desired. Most notably, we can specify an upper-bound using a constraint like this (rather than require our language to support covariant type parameters), but the CLR and C# don’t have support for lower bounds (“supertype constraints”) so you can’t use this technique in place of contravariant type parameters (eg. my IComparer<-T> example). See section 4.4 (“Comparison with Parametric Methods”) of [1] for more details.

Java 5 addresses these scenarios with “Wildcard types” [2]. Eg. you would use a “List<? extends Shape>” in Java to implement my example above, and there is also a syntax “? super T” for lower-bounds. It’s interesting to note that the authors of the paper on wildcards indicate that the main advantage of wildcard types over using normal generic methods (as I’ve done above) is that wildcard types don’t require exact type information (see section 4.4 of [2]). The big difference between generics in .NET and Java is that in .NET, the CLR supports generics to the core and so we have exact type information everywhere (which is why you can get information about generic types using Reflection at run-time). In Java, generics are “erased” by the compiler, and so at run-time, the information about generic instantiations are lost. Using erasure has the benefit of better compatibility with old code and a much simpler implementation, but extending the VM (like we did for the CLR) has several important benefits including avoiding boxing for instantiations at value types and therefore better performance (eg. a List<int> can be very efficient), and the ability to use exact type information at run-time.

The big difference between wildcards and generic variance in the CLR is that wildcard types are an example of “usage-site variance” where MSIL uses “definition-site variance” (meaning it’s the type definition that specifies the variance annotation, not the user of the type). I was reading about a cool academic programming language called Scala recently, and was pleased to see that after some experience with usage-site variance, they decided to switch to definition-site variance because they found it easier to use correctly (see “Comparison with wildcards” in [4]). Scala is a very cool language (my programming languages professor recently mentioned it as a great example of a language on the forefront of modern academic language design), and can target .NET. Unfortunately they haven’t built support for the V2.0 CLR yet so they aren’t actually making use of the definition-site variance support in the CLR (for the moment <grin>).

Anyway, I think that’s about all I have to say about generic variance. I’ve got a programming languages exam on Tuesday (I’m working on my masters in computer science) so I think I better stop procrastinating and study for it <grin>.

References

[1] On variance-based subtyping for parametric types

[2] Adding Wildcards to the Java Programming Language

[3] A Comparative Study of Language Support for Generic Programming

[4] An Overview of the Scala Programming Language (2. Edition)

DebuggingModes.IgnoreSymbolStoreSequencePoints

rmbyers — Fri, 09 Sep 2005 03:01:00 GMT

In my last post I gave an overview of the DebuggableAttribute, what values the C# compiler gives it, and how the CLR uses those values. I mentioned that with /debug+, the C# compiler sets the IgnoreSymbolStoreSequencePoints DebuggingModes bit, but I didn't describe what this bit does. Understanding sequence points and ths IgnoreSymbolStoreSequencePoints bit is important for anyone writing a compiler for .NET (including one that uses Reflection.Emit).

A sequence point is used to mark a spot in the IL code that corresponds to a specific location in the original source. For Reflection.Emit, they are emitted by the ILGenerator.MarkSequencePoint method. This serves two purposes. First to allow debuggers (and the StackTrace class) to map IL offsets back to source and line information. Secondly to tell the JIT compiler that it must preserve this location uniquely in the generated native code so that a user could, for example, set a breakpoint on it (see Mike's blog entry for more details).

Since they're only needed for debugging scenarios, the location of sequence points, and their mapping back to source locations, are stored in the PDB file. Unfortunately this means that the JIT compiler has to open the PDB file and read this data any time it compiles a method with optimizations disabled (if JIT optimizations are enabled, then it doesn't care about sequence points in order to get the best codegen possible). The PDB file format is quite complicated, and has a long legacy. So as you might imagine, there is an unfortunate performance penalty here.

Now in addition to the sequence points specified in the PDB file ("explicit sequence points"), the JIT also infers additional sequence points based on the IL code ("implicit sequence points"). For example, it adds an implicit sequence at every point where the IL evaluation stack is empty, or on any "nop" instruction. So in Whidbey we added the IgnoreSymbolStoreSequencePoints bit to allow compilers to indicate to the JIT that they are content with the JITs rules for implicit sequence points, and there is no need for the JIT to look in the PDB file for more.

So our official recommendation is that all compilers (including those using Reflection.Emit) set the IgnoreSymbolStoreSequencePoints bit and rely on "nop" instructions to ensure the JIT places sequence points at the right place. This can make a nice JIT performance improvement, and also has some other benefits related to not needing to read the PDB file at JIT time (eg. it may not be available). The Whidbey C# and VB compilers do this, but unfortunately the managed C++ compiler does not.

DebuggableAttribute and dynamic assemblies

rmbyers — Mon, 27 Jun 2005 07:52:00 GMT

Mike Stall has a great little sample showing how to make your dynamically generated code debuggable. However, there is one more detail you should be aware of. By default the JIT compiler will enable optimizations for the module, making debugging difficult or (in the case of JMC-mode in VS) impossible. If you run your program from within Visual Studio and have the “Suppress JIT optimizations on module load” option enabled, then it’ll work fine. However, I believe this setting in VS is now (as of the June CTP) disabled by default in order to minimize any changes to your program’s behaviour when run under the debugger. Additionally, optimizations would also be enabled it you attached to an already running process.

Compilers like csc.exe have command line options such as /debug and /optimize that affect how the JIT generates code for the assembly. The compiler communicates this information to the CLR by attaching a System.Diagnostics.DebuggableAttribute to the assembly. This attribute contains a DebuggingModes value which is a bit-mask of various flags. Here are the flags that the Whidbey C# compiler emits for the various combinations of compiler options:

/debug-	Retail build: No attribute emitted (same as specifying DebuggingModes.None). Setting /o+ or /o- doesn’t change anything when debug mode is disabled. /debug- is the default and so can be omitted.
/debug+	Debug build: Default, IgnoreSybmolStoreSequencePoints, EnableEditAndContinue DisableOptimizations. /o- is the default here.
/debug+ /o+	Debug optimized: Default, IgnoreSybmolStoreSequencePoints. In Whidbey this is essentially the same thing as /debug-.

Note that before Whidbey, the “Default” flag was used to “enable JIT tracking”. JIT tracking meant we would track information necessary for debugging such as IL/native maps (for converting native address offsets to IL offsets and vice versa). In Whidbey we have an efficient form of JIT tracking enabled all of the time, so this flag is now basically meaningless. However, we need to ensure the Whidbey CLR runs Everett binaries in the same way, so for backwards compatibility we still require the Default flag to be present if we’re going to do things like disable JIT optimizations.

So, if you want to emit a dynamic assembly which is always debuggable (similar to using the C# compiler’s /debug+ option), then you need to use the following code after calling DefineDynamicAssembly:

// Add a debuggable attribute to the assembly saying to disable optimizations
Type daType = typeof(DebuggableAttribute);
ConstructorInfo daCtor = daType.GetConstructor(new Type[] { typeof(DebuggableAttribute.DebuggingModes) });
CustomAttributeBuilder daBuilder = new CustomAttributeBuilder(daCtor, new object[] {
DebuggableAttribute.DebuggingModes.DisableOptimizations |
DebuggableAttribute.DebuggingModes.Default });
assemblyBuilder.SetCustomAttribute(daBuilder);

Note that it’s best to do this before calling DefineDynamicModule. Visual Studio, for example, looks at the optimization setting by calling ICorDebugModule2.GetJITCompilerFlags as soon as it gets a LoadModule event (which is triggered by DefineDynamicModule). If you haven’t emitted the DebuggableAttribute yet, VS will think optimizations are enabled and will prevent debugging of the module if JMC is enabled.

It’s amazing how complicated the concept of “debug build” can be here, especially when you add in backwards compatibility, debugger overrides, various config file overrides, etc. Thankfully, the story is simpler in Whidbey since we no longer have to worry about JIT tracking.

Run-time exception checking

rmbyers — Sat, 30 Apr 2005 23:32:00 GMT

One of our partners asked us how a .NET program can tell what the currently active “try” blocks are on the stack. This seemed like a dubious thing to want to do, but regardless a colleague of mine whipped up some sample code that uses the StackTrace class and reflection to do this. We were talking about the possible uses of this, and most of them seemed pretty evil. Changing program behaviour based on dynamic program inspection can lead to programs that are hard to reason about and brittle due to violating abstraction boundaries and implicit coupling. Not to mention the fact that in optimized builds, some data may be missing from the StackTrace due to in-lining or other optimizations.

However, in-process inspection mechanisms like the StackTrace class can be incredibly useful for diagnostics purposes. Perhaps in certain situations, it would be valuable to be able to write assertions like “If I throw a FooException, it should be handled by somebody”. As you probably know, there is a lot of debate about the value of checked exceptions, but I’m not going to discuss that here, see the Artima interviews with Anders Hejlsberg and James Gosling for a start. We all know that validating your assumptions with assertions is a critical part of writing quality software, especially for large systems. So if you’re making some assumptions about exception behaviour, it seems logical to want to check those assumptions at run-time with assertions. Assertions can also be useful for making you aware of changes in behaviour that might have an impact on an area you didn’t anticipate. You could imagine more complex checks like “The only catch handler for System.Exception is the one I know about in the top loop of my application” (nothing is more annoying then having some library code swallow your exceptions). Of course checking these sorts of things statically (with tools like FxCop) is generally preferable to run-time checks, but our managed static analysis tools are still quite primitive, and it is very difficult to do complete static analysis in the presence of dynamic control flow mechanisms like reflection and delegates.

Anyway, here is some sample code that shows how you could write such assertions (I apologize for the lack of syntax highlighting – this new community server software doesn’t properly paste formatted text). I’m still not convinced this is necessarily a good idea, but it seems to have some intriguing possibilities nonetheless.

// Get a list of all the try clauses that are active on the stack that would
// catch exceptions of the specified type.
static public List<ExceptionHandlingClause> GetActiveTryClauses(Type exType)
{
List<ExceptionHandlingClause> activeTryClauses =
new List<ExceptionHandlingClause>();

StackTrace stackTrace = new StackTrace();
StackFrame[] frames = stackTrace.GetFrames();

// Start at 1 to skip the GetActiveTryClauses frame.
for (int i = 1; i < frames.Length; i++)
{
    StackFrame frame = frames[i];
    MethodBase method = frame.GetMethod();
    MethodBody body = method.GetMethodBody();

    // Only consider methods that have an IL body.
    if (body != null)
    {
      IList<ExceptionHandlingClause> ehClauses = body.ExceptionHandlingClauses;
      foreach (ExceptionHandlingClause ehClause in ehClauses)
      {
        if (ehClause.Flags == ExceptionHandlingClauseOptions.Clause)
        {
          // Only consider clauses which are active on the current stack
          int offsetInFrame = frame.GetILOffset();
          int tryStartOffset = ehClause.TryOffset;
          int tryEndOffset = tryStartOffset + ehClause.TryLength;

          if ((offsetInFrame >= tryStartOffset) && (offsetInFrame < tryEndOffset))
          {
            // If desired, only collect clauses that would catch the specified type
            if (exType == null || ehClause.CatchType.IsAssignableFrom(exType))
            {
              activeTryClauses.Add(ehClause);
            }
          }
        }
      }
    }
}

return activeTryClauses;
}

public static bool IsCaught(System.Type type)
{
List<ExceptionHandlingClause> handlers = GetActiveTryClauses(type);
return (handlers.Count > 0);
}

This allows you to write simple checks like the following:

// Ensure someone will handle any IO failure here
Debug.Assert(TryClauseInfo.IsCaught(typeof(System.IO.IOException)));

// Ensure no-one is catching all exceptions
Debug.Assert(!TryClauseInfo.IsCaught(typeof(System.Exception)));

Or you could even write more complex checks based on the ExceptionHandlingClause information.

What do you think? Are there situations in your applications where you could get value out of using assertions like this? Can you think of any other uses for this code that wouldn't be totally evil?

Generic type parameter variance in the CLR

rmbyers — Thu, 17 Feb 2005 10:00:00 GMT

When people start using C# generics for the first time, they are sometimes surprised that they can’t convert between related generic instances. For example, since you can convert a string to an object, shouldn’t you also be able to convert a List<string> to a List<object>? After all, you can convert a string[] to an object[], why should List<T> be any different?

More formally, in C# v2.0 if T is a subtype of U, then T[] is a subtype of U[], but G<T> is not a subtype of G<U> (where G is any generic type). In type-theory terminology, we describe this behavior by saying that C# array types are “covariant” and generic types are “invariant”.

There is actually a reason why you might consider generic type invariance to be a good thing. Consider the following code:

List<string> ls = new List<string>();

ls.Add("test");

List<object> lo = ls; // Can't do this in C#

object o1 = lo[0]; // ok – converting string to object

lo[0] = new object(); // ERROR – can’t convert object to string

If this were allowed, the last line would have to result in a run-time type-check (to preserve type safety), which could throw an exception (eg. InvalidCastException). This wouldn’t be the end of the world, but it would be unfortunate. Part of the benefit of generic types is that it helps to avoid the run-time checking and error handling overhead involved in converting back and forth from a base type (object in C#). It simplifies things greatly (both from a developer and run-time perspective) to be able to say that a variable of type List<object> can for sure hold any object.

So what about arrays, don’t we have the exact problem there? Yep. This was a hotly debated aspect to C#/CLR design. Java also has covariant array types, and whether or not this is a language flaw has been debated for ages. Jim Miller has an interesting annotation in his CLI book (pg 59) where he says "The decision to support covariant arrays was primarily to allow Java to run on the VES. The covariant design is not thought to be the best design in general, but it was chosen in the interest of broad reach". [Update: I've heard that Bill Joy, one of the original Java designers, has since said that he tried to remove array covariance in 1995 but wasn't able to do it in time, and has regretted having it in Java ever since]

Let’s get back to our original question. What if you really did want covariant generic types in a .NET language? Does the CLR really prevent that? Well, you may recall that I alluded to the fact that Eiffel makes use of additional features in the CLR generic support, that C# and VB do not. In Eiffel, generic types are always covariant (and so have the same sort of run-time checks as arrays). If you were to look at the draft v2 ECMA specification, you would see the following:

In addition, CLI supports covariant and contravariant generic parameters, with the following characteristics:

· It is type-safe (based on purely static checking)

· Simplicity: in particular, variance is only permitted on generic interfaces and generic delegates (not classes or value-types)

· Languages not wishing to support variance can ignore the feature, and treat all generic types as non-variant.

· Enable implementation of more complex covariance scheme as used in some languages, e.g. Eiffel.

Contravariance is the opposite of covariance – it means that the subtype relationship of the generic type varies inversely with the relationship of the type parameter. Or formally, G<T> is a subtype of G<U> if and only if U is a subtype of T. This is a pretty cool approach in my opinion. It allows a compiler to mark generic type parameters on an interface as being nonvariant, covariant or contravariant, and then enforces that those types are used only in places where they are safe (i.e. don’t require a run-time type check). Specifically, it’s always safe to use a covariant type as an output (return type or out parameter), and a contravariant type as an input. In IL, covariant type parameters are indicated by a ‘+’, and contravariant type parameters are indicated by a ‘-‘ (non-variant type parameters are the default, and can be used anywhere). Consider this simple example (using a theoretical extension of C#) from the draft ECMA spec [Update: switched to the newly announced C# 4.0 syntax]:

// Covariant parameters can be used as result types

interface IEnumerator<out T> {

T Current { get; }

bool MoveNext();

}

// Covariant parameters can be used in covariant result types

interface IEnumerable<out T> {

IEnumerator<T> GetEnumerator();

}

// Contravariant parameters can be used as argument types

interface IComparer<in T> {

bool Compare(T x, T y);

}

This would mean we could write code like the following:

IEnumerable<string> stringCollection = ...;

IEnumerable<object> objectCollection = stringCollection;

foreach( object o in objectCollection ) { ... }

IComparer<object> objectComparer = ...;

IComparer<string> stringComparer = objectComparer;

bool b = stringComparer.Compare( "x", "y" );

But we couldn’t do the opposite – try and convert an IEnumerable<object> to an IEnumerable<string>, or try and convert an IComparer<string> to an IComparer<object>. In those cases, we’d get a compile time error telling us such a conversion wouldn’t be type-safe. Of course, languages (like Eiffel) are free to build their own run-time type checking on top of the strict CLR support to relax the rules where they see fit.

In my opinion this sort of language feature would occasionally be very useful (although the real scenarios would, of course, be much more involved than the above simplistic examples). There have been a couple of times when writing real-world C# code when I knew I could write simpler code if the CLR generic variance support was exposed in C#. Generic variance support in C# has been discussed on the MSDN product feedback center, and I don’t think the C# team has ruled it out for a future addition to the language (but of course I don’t know their plans any better than you do). Although I think this is a cool feature, I don’t think I’m going to start writing any applications in IL just so I can take advantage of it. However, it would probably be a fun project to write or extend and existing free C# compiler (like Mike Stall’s Blue) with support for generic variance. If you're interested in more details (including a thorough description of assignment compatibility in the face of generic variance) see the draft v2 ECMA specification.

[Update: Added details about covariant arrays from Jim Miller's CLI book, and pointer to the draft v2 ECMA spec above.]

[Update: See my post "More on generic variance" for more details and discussion]

[Update: Here's an MSDN article that discusses this as well: http://msdn2.microsoft.com/en-us/library/ms228359(vs.80).aspx]

[Update: Anders has finally announced that C# 4.0 and the BCL will support generic variance with "in" and "out" keywords. This has been in the works for awhile, and of course I'm super excited about it.]