Browse by Tags
All Tags »
.NETInternals (
RSS)
Patrick Dussud described the variants of garbage collection that exist in the world today – specifically, reference counting and tracing GC. GCs are measured by the speed of the allocator, the GC time overhead, the pause time (latency), the working set, and multi-core scaling. Patrick described the general architecture of the GC, and said that he wants to focus on GC policies and mechanisms and not on the actual implementation of root scanning, thread suspension, virtual memory management and similar...
Over a year ago, I blogged about the SOSEX debugging extension (which has been updated since!) and how its !dlk command can be used to diagnose a managed deadlock that involves Monitor locks . There’s also the obvious question of what to do when SOSEX can’t be used for this purpose, i.e. how to diagnose this kind of deadlock with SOS alone. First of all, you need to see the sync blocks involved. The SOS !syncblk command (and the !dumpheap -thinlock command) will show you information about the sync...
We all know that the first time a .NET method is called, the just-in-time (JIT) compiler is invoked to compile the method’s IL representation to the native code for the particular platform it’s running on (x86, x64 or ia64). Did you ever ask yourself how this happens? The naive way to think about it is the following: Every time a method is called, the generated native code checks a flag that indicates whether the method has already been compiled (jitted). If it has been, the code jumps directly to...
Patrick humbly asks for a method tentatively called GC.GetAliveInstancesOf<T>() that returns a collection of referenced instances of a specific type. While useful, this is something that doesn’t belong in the .NET framework, much more so in the API of the garbage collector, but it’s still very useful for diagnostic scenarios (e.g. SOS yields this information easily through the !dumpheap –type command ). The following is a quick and dirty suggestion at an implementation that “automagically”...
About a week ago, Dima and I were consulting for two different teams at the same customer site, without even knowing about each other’s presence. Around the middle of the day he gave me a call, and we discovered that we’re only a couple of stories apart. What Dima’s customer was experiencing is a non-deterministic delay in a managed application performing processing of buffers received from a physical device before they were being sent to another physical device. While it would typically take less...
In the first part , we looked at a scenario where fiddling with the in-memory field controlling a custom cache size and then externally triggering a garbage collection gave us a likely culprit for a high memory scenario. After having disentangled the first problem, we faced a completely different issue. One of the apparently-leaking processes didn’t have that many objects in its managed heap. Inspecting the GC performance counters indicated that there while memory utilization was around...
I’ve just noticed a post by Guy Kolbis discussing a possible solution for deadlocks – ensuring that all locks are taken with a timeout. To do so, Guy cites the TimedLock struct , originally introduced by Ian Griffiths . The general idea is that instead of using a standard lock{…} block, you wrap your critical section in the following statement: using ( TimedLock .Lock(...)) { } Ian even introduces a refinement of this idea by including a sentinel reference type in the struct, in Debug builds...
A few days ago, I was visiting a customer with high-memory scenarios in a 64-bit ASP.NET application. I’m saying “scenarios” because we still don’t know for sure what the problem was, and because we’re pretty confident that there’s more than one underlying cause. Even though there are no conclusive results yet, I wanted to share with you some of the things we did because they are interesting on their own behalf. What we were facing was a set of 4 w3wp.exe processes that were consistently increasing...
In part 1 we looked at CLR side-by-side support for multiple versions, at interoperability-related features and at DLR-related changes in the CLR. There have been various complaints about performance aspects of the CLR that are sometimes neglected - the installation experience, the startup experience and the GC latency experience for high-performance applications. This feedback will be addressed in CLR 4.0: The .NET installer can be branded and customized, and begins with a 200K bootstrapper. Downloading...
Joshua Goodman's session on CLR futures was packed - the crowd of developers wanted to learn what's been cooking under the hood for the past couple of years. Without a major CLR upgrade since 2005 (CLR 2.0), we all had our appetites whetted. So to begin with, Joshua announced that as of 4.0, multiple versions of the CLR can be hosted in the same process. For example, an application leveraging CLR 4.0 will run on top of CLR 4.0, but will be able to load and interact with a module that requires...
The first session I attended on the first day of PDC was Misha Shneerson's presentation on a feature affectionately called No-PIA, or formally enabled by type equivalence and type embedding. The primary motivation for this feature is to simplify COM interoperability scenarios and improve their performance, but it is useful for managed-to-managed applications as well, particularly those with extensibility requirements. What No-PIA means in brief is that instead of generating an interop assembly...
I’ve written about the perils of non-deterministic finalization before: It is a guaranteed way to get yourself in trouble. One of the more-or-less known facts is that in the process shutdown scenario, finalizers are called for reachable objects as well. The total allotted time for this operation is approximately 40 seconds, and each individual finalizer gets approximately 2 seconds to execute. It is extremely difficult to detect this scenario and debug it because we are talking about the CLR...
In this entry, we will examine the last two interesting new commands bundled in the Silverlight SOS.DLL – namely !FindRoots and !ListNearObj . (Previously in this series: Basic introduction to Silverlight SOS ; The !AnalyzeOOM command ; The !HeapStat and !GCWhere commands .) The !FindRoots command is specifically oriented at understanding memory leaks and object promotion scenarios. It is a wrapper on top of existing functionality, making analysis more convenient. The key scenario to...
Another SOS.DLL command new in Silverlight is !HeapStat , featuring statistics on the sizes and available space in the various GC heaps and generations. (Previously in this series: Basic steps with Silverlight SOS ; The !AnalyzeOOM command .) Because Silverlight applications run within a browser, there’s typically going to be a single GC heap because the browser’s CLR host uses workstation GC. However, generations and the large object heap (LOH) are still of interest. The following is...
The managed synchronization mechanisms, including Monitor , WaitHandle.WaitAny , ManualResetEvent , ReaderWriterLock , Thread.Join , GC.WaitForPendingFinalizers and the rest of the family are not just a thin platform adaptation layer on top of the Win32 API. The CLR needs to know exactly which threads are currently waiting for a synchronization mechanisms for a variety of reasons. To mention two of them: In hosting scenarios, the CLR host might want to limit the ability of application threads...
More Posts
Next page »