Determinism in Dispose and Finalize Execution Timing

...Time... by ĐāżŦ {mostly absent}, on FlickrI get a surprising number of questions about when objects are disposed or collected. Usually people will have some limited logic to cleanup their objects (releasing file handles, removing references to large objects, etc.), and they don’t know when this logic will execute. Here is a little bit of insight into when objects are disposed and finalized. (If you are looking for more information about Disposable and Finalizable patterns, check this post)

When Does Dispose Execute?

The Dispose method on an object is only executed when it is called by the application. What I mean by that, is the CLR does not automatically call Dispose on your objects. If you don’t call dispose, it can result in a memory leak that does not get cleaned up until the process exits.

This doesn’t mean you necessarily have to call Dispose() explicitly. In C#, there are a number of times that Dispose() is called implicitly:

Be Kind to Your GC: Examining IDisposable and Finalize Patterns

Through my discussions with various developers, I have noticed a common theme when it comes to disposing objects. Most developers are confused, or at least unclear, on why and when to use dispose and finalize.

Let me start off with this: The purpose of dispose and finalize is the same… to improve the performance of the application and the host system. You don’t need to implement either. When the GC runs, unused managed memory will be reclaimed. When your process exits, the entire process’s virtual memory will be released. When the system re-boots, any open native handles will be closed. Dispose and finalize are two patterns that make it easier for your application to be a “good citizen,” releasing memory as soon as it is no longer needed and closing handles as soon as you are done with them.

Automatic Memory Management Concepts in .NET (Garbage Collection)

Annotated Sagittal T1 Midline MRI Scan of Reigh's BrainAs Raymond Chen so aptly explained, the purpose of garbage collection is to simulate a computer with an infinite amount of memory. This is another piece of the puzzle that gives application developers freedom through abstraction. Freedom to focus on the logic and structure of their code without being unnecessarily concerned about the constraints of the system it is running on, including managing physical and virtual memory. Unfortunately, this seems to result in some gross misuse of system resources.

So that you do not fall into the same fallacies and abuse, let’s learn some more about memory management in .NET. This article will be a higher level overview of Garbage Collection (GC) in version 4.5 of the .NET Framework. There will be more articles to follow that will go into more depth of some of the different parts of the .NET Garbage Collector.

Memory Management?

The Garbage Collector (GC) in .NET can be thought of as the subsystem that handles allocating and de-allocating managed memory. Ever used variables in c?

main() {
  char *name = malloc(50);


Central Ohio Day of .NET 2012

I have been honored with another speaking opportunity. This time at the Day of .NET conference in central Ohio. My presentation will be an in-depth session on garbage collection in general, and specifically as it is implemented in the .NET framework.

If you have the opportunity to attend, you will certainly leave as a smarter developer. The agenda for the conference has been posted, and it looks like all attendees are in for a treat!

The conference will be on December 8, 2012. Register early if can!

Strict Mode in JavaScript

JavaScript strict mode tells the interpreter to be more particular about what is allowed. In general terms, strict mode makes your code a little safer by turning some bad coding practices into exceptions.

For existing code, this is good and bad. It’s good, because it helps you find some potential bugs, like accidental globals. It’s bad because code that used to work, might now be broken.

Here’s the kicker: for new code, it is almost always good.

Geek and Nerd In-Jokes: Star Wars Holiday Special

Star Wars Holiday SpecialEverybody loves inside jokes, and you have inevitably found yourself on the outside a time or two. The more obscure the reference, the more fulfilling it is when someone else “gets it”.

I thought it would be fun to review some of my favorites, so you can feel cool when you catch them in some of my other blog posts. I’ll try to keep them mostly geek/nerd/tech related, but no promises…

Star Wars Holiday Special

The Star Wars Holiday Special is a horribly awesome holiday variety show that takes place (mostly) in the Star Wars universe.

Property Descriptors in JavaScript

Tools IMG_0172 by OZinOH, on FlickrSome of the most common complaints about JavaScript come from its dynamic, mutable nature. You can modify nearly any member of any object and even delete some built-in ones! This enables web developers to improve cross-browser compatibility of their sites while maintaining code readability with a technique called poly-filling. On the other hand, it also allows developers to modify built-in behavior (called “monkey-patching”), sometimes causing side-effects or bugs that are difficult to troubleshoot.

Starting in ECMAScript 5, new mechanisms have been defined to give you (the developer) the ability to restrict what can be done to your object members. You can read the standard here. I did. Twice.

Private Variables in JavaScript

PrivateBecause JavaScript uses prototype-based inheritance, there is no keyword to define a member as “private” or “protected”. Either the object has a member, or it doesn’t, and you can access that member from anywhere you can access the object. Do not despair! There is a way to implement private variables… using another feature of the language: closures!


Closures are fairly simple, but frequently misunderstood. What you need to know for now, is that a closure allows you to reference an outer variable from within a function, even when the function is called from another context.

This will make more sense when you see some code. (more…)

Inheritance in JavaScript

Native JavaScript inheritance is prototypical. For one, this means that you don’t inherit from classes, you inherit from objects. You don’t define classes and instantiate them. Instead, you create objects and use them as a “prototype” or “base” for your own object instances.

In JavaScript, this is facilitated with the mechanisms called “prototype” and “constructor”.

Useful JavaScript Features You Aren’t Using

JavaScript is one of the most widely used and misunderstood programming languages in existence. Nearly every personal computer and mobile device in the world can interpret it, and nearly every developer (and non-developer) that has made a website has written it, some without knowing it!

If you call yourself a JavaScript developer, then here are some things that the language can do that you need to know about, whether you use them or not! If you are using them, then you should understand them!