Identifying Specific Reference Type Arrays with SOS

Thursday, May 1, 2014

When you're looking for arrays of a specific type using SOS, you might notice a weird phenomenon. Value type arrays (such as System.Int32) will be shown properly regardless of which command you use, but reference type arrays (such as System.String) exhibit some weird behavior. Here's an example: 0:000> !dumpheap -stat Statistics: MT Count TotalSize Class Name ... 00007ffecf435740 2 304 System.Byte 00007ffecf4301c8 2 320 System.Threading.ThreadAbortException 00007ffecf4327d8 11 ...
no comments

.NET Native Performance and Internals

Monday, April 28, 2014

Introduction to .NET Native.NET Native is a compilation and packaging technology that compiles .NET applications to native code. It uses the C++ optimizing compiler backend and removes the need for any JIT compilation at runtime and any dependency on the .NET Framework installed on the target machine. Formerly known as "Project N", .NET Native is currently in public preview and this post explores the internals of the compilation process and the resulting executable's runtime performance.At this time, .NET Native is only available for C# Windows Store Apps compiled to x64 or ARM, so the experiments below are based on...
2 comments

Modern Garbage Collection in Theory and Practice

Tuesday, November 5, 2013

Last week I delivered a very interesting session on modern garbage collection. Usually, I only get the opportunity to talk about GC in very specific contexts, such as .NET internals or performance optimization. This time, I was invited to give a talk on garbage collection theory and its practical applications in modern managed languages – which made for super-interesting preparation! In the course of preparing for the talk I brought myself up to speed with the recent development in JVM garbage collectors as well as approaches taken by other managed languages such as Ruby and Python. Although there...
no comments

On ‘stackalloc’ Performance and The Large Object Heap

Thursday, October 17, 2013

An interesting blog post is making the rounds on Twitter, 10 Things You Maybe Didn’t Know About C#.  There are some nice points in there, such as using the FieldOffset attribute to create unions or specifying custom add/remove accessors for events. However, item #4 on the list claims that using stackalloc is not faster than allocating a standard array. The proof is given in form of a benchmark program that allocates 10,000 element arrays – so far so good – and then proceeds to store values in them. The values are obtained by using Math.Pow. The benchmark results...
2 comments

Talks from DevConnections 2013: Advanced Debugging with WinDbg and SOS, Task and Data Parallelism, and Garbage Collection Performance Tips

Thursday, October 10, 2013

I'm falling behind in documenting all my travels this fall :-) In the beginning of the month I flew out to Vegas for IT/DevConnections, which was my second Las Vegas conference this year. I've been there for just 48 hours, but it was enough time to deliver three talks, meet fellow speakers, and even have a few meaningful chats with attendees about the future of .NET and production debugging techniques. You can find my presentations below -- the last couple of slides of each presentations have some additional references and books that might be useful if you want to expand...

Visual Studio 2013 Heap View

Tuesday, July 2, 2013

It’s always fun to add a new blog tag – VS2013. In today’s post I’d like to tell you about the Heap View feature (a.k.a. “Debug Managed Memory”) that you can use to analyze dump files in Visual Studio 2013, announced at Build last week. Although this feature is far from baked and would likely only be useful for simple investigations, I welcome any improvements to the diagnostic tooling built into Visual Studio and look forward to the day I can solve most bugs without leaving the IDE. Essentially, Heap View is a simple explorer for your application’s...
2 comments

Traversing the GC Heap with ClrMd

Monday, May 20, 2013

ClrMd is a newly released diagnostic library that wraps the CLR’s undocumented data access interfaces (a.k.a. “DAC”) in a friendly managed API. The underlying interfaces are what debugger extensions like SOS and SOSEX use to implement various diagnostic features, including enumerating the managed heap, detecting deadlocks, inspecting object contents, and dumping type/method information. Given my personal and professional interest in debugging tools and techniques, ClrMd is an incredible tool – I can now implement my own diagnostic features without relying on undocumented interfaces or parsing text output from debugging extensions (which also requires going through a debugger in...
one comment

Two More Ways for Diagnosing For Which Synchronization Object Your Thread Is Waiting

Wednesday, April 24, 2013

It is as though there is an infinite variety of heuristics that you can use to determine which synchronization object your thread is waiting for. In fact, these are heuristics for retrieving fastcall parameters passed in registers that have been clobbered by subsequent method calls. Method 1: Inspect the handle passed to WaitForMultipleObjectsEx The CLR uses an auto-reset event to implement sync block synchronization, which means that every attempt to acquire an owned sync block will result in a call to WaitForMultipleObjectsEx. If you inspect this method's parameters, you'll find a handle that you might be able to correlate with the...
3 comments

Revisiting Value Types vs. Reference Types

Wednesday, April 10, 2013

Why do C#, the .NET Framework, and the CLR need value types and reference types? Why two categories of types? Why the added complexity in training developers to understand why and when to use each type of type? There are many answers, but very few get to the crux of the matter. You could try to justify the need for two types of types by looking at the semantic differences C# affords each. For example, you know that by default, instances of value types are copied when passed to a function, but instances of reference types are not -- only...
2 comments

Wishes for the CLR JIT in the 2020s

Sunday, March 3, 2013

There have been some very interesting discussions at the MVP Summit concerning the CLR JIT, what we expect of it, and how to evolve it forward. I obviously can't disclose any NDA materials, but what I can do is share my hopes and dreams for the JIT, going forward. This is not a terribly popular subject, but there are some UserVoice suggestions around the JIT, such as adding SIMD support to C#. The state of the JIT today is that it's a fairly quick compiler that does a fairly bad job at optimization. There are some tricks it employs that...
3 comments