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...

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...

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...

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...

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...

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...

DevReach 2012: Garbage Collection Performance Tips

Thursday, October 4, 2012

Thanks for attending my DevReach session on garbage collection performance tips! This is one of my favorite subjects, and I found it very hard to cover it well in just under one hour. Still, we discussed the general inner workings of the garbage collector and highlighted several best practices for improving your application performance. Among the topics we covered: Switching GC flavors and understanding server, concurrent, and background GC Finding long-lived objects and allocation sources with CLR Profiler Detecting virtual address space...
no comments

Runtime Representation of Generics—Part 2

Tuesday, September 18, 2012

This is an excerpt from Chapter 5 (Collections and Generics) of Pro .NET Performance, scheduled to appear in less than a month. I might be publishing a few more of these before and after the book is out. After giving ample consideration to the design of Java generics and C++ templates, we can understand better the implementation choice for CLR generics. CLR generics are implemented as follows. Generic types — even open ones, like List<> — are first-class runtime citizens. There is a method table and an EEClass for each generic type and a System.Type instance can be...
no comments

Finalization Queue or F-Reachable Queue? SOSEX (Not So) New Commands

Saturday, July 28, 2012

As Steve Johnson, the author of the awesome SOSEX debugging extension, pointed out in a comment on my last finalization post, as of SOSEX 4.0 you can use the !finq and !frq commands to inspect separately the finalization queue and the f-reachable queue. As a reminder, objects on the finalization queue are objects that are eligible for finalization but are still referenced by the application. These are objects for which finalizers will run at some point, but the GC has not passed them over to the finalizer thread’s control. Objects on the f-reachable queue, on the other hand,...
no comments