iter.dk

Morten on GIS and .NET

Main interests are OGC standards, GPS and SOAP Webservices.

All projects are based on Microsoft’s .NET technologies.

PocketGpsLib - .NET Mapping Engine

PocketGpsLib - .NET Mapping Engine

The PocketGPSLib for your Pocket PC, makes it easy to implement a GPS receiver in your .NET Compact Framework applications. Written 100% in C#.

Supports RMC, GGA, GSA, GLL and GSV NMEA sentences. The library runs in it's own thread and is asyncronous / event based for easy implementation. Features full support for sending RTCM messages to the GPS device, making Differential GPS possible. PocketGpsLib is released under the GNU General Public License.

For more info and download visit http://gps.iter.dk

SharpMap engine - .NET Mapping Engine

SharpMap engine - .NET Mapping Engine

SharpMap is a simple-to-use map renderer that renders GIS vector, raster and WMS data for use in web and desktop applications.

The engine is written in C# and based on the .NET 2.0 framework. SharpMap is released under the GNU General Public License.

For more info and download visit http://sharpmap.iter.dk

GC, Dispose and Finalization

Excellent post on the GC, Dispose and Finalization http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=88e62cdf-5919-4ac7-bc33-20c06ae539ae

To Null or Not Null (Chris Lyon's Blog)

Another excellent post by Chris Lyons about the GC http://blogs.msdn.com/clyon/archive/2004/12/01/273144.aspx To Null or Not Null: GC Myth: setting an object's reference to null will force the GC to collect it right away.

GC Truth: setting an object's reference to null will sometimes allow the GC to collect it sooner.

As much as you may want to, you can't guarantee the GC will collect what you want, when you want it to. The best you can do is give it hints. The GC typically does collections when an allocation fails, not necessarily as soon as you're done with an object.

Consider the following method. What is the earliest point the GC could collect the Object that obj references?

void Foo() { Object obj = new Object(); Console.WriteLine(obj.ToString()); for (int i=0; i<10; i++) { Console.WriteLine(i); } obj = null; }

The answer depends on whether you've compiled it in Debug or Release mode. In Debug, the JIT extends all references' lifetimes to the end of their scope. This is so you don't have to worry about the GC cleaning up a variable you're trying to inspect!

In Release mode, the Object is actually first eligible for collection after the call to ToString(). The JIT is usually smart enough to realize that obj = null can be optimized away. That leaves obj.ToString() as the last reference to the object. So after the call to ToString(), the obj is no longer used and is removed as a GC Root. That leaves the Object in memory orphaned (no references pointing to it), making it eligible for collection. When the GC actually goes about collecting it, is another matter.

So when does setting a reference to null allow the object in memory to be reclaimed sooner?

Consider instance variables. Imagine a class that contains a large array of a managed type. There could be times where you no longer need that array, but you want the object to hang around. This is a good case for the Dispose pattern:

class BigObject : IDisposable { int[,] array = new int[1024,1024]; public void Dispose() { array = null; } }

Now the GC will clean up the array when it does its next collection, and you can keep that BigObject around for whatever reason, and not worry about it taking up so much memory.

Dispose Do's and Dont's from Chris Lyon's blog

from http://blogs.msdn.com/clyon/archive/2004/09/23/233464.aspx

• Dispose should contain code to release any unmanaged resources associated with the object's instance. For example, any handles should be released, database connections closed, etc. This simulates deterministic finalization by letting the developer do the resource cleanup when he/she is done with the object. You may want to use an IsDisposed bool and check it inside Dispose.
• Dispose should be safely callable multiple times. In my example above, if some user of your class called Dispose twice, we would crash with an unhandled InvalidOperationException trying to “double free” the GCHandle.
• If you inherit from an IDisposable object, call the base class' Dispose method. Unlike finalizers, which the GC calls, Dispose is only called by user code (sometimes automatically in C#, as I covered previously). This means any unmanaged resources held by your object's parent, must also be disposed of.
• Suppress finalization in Dispose. There has been some debate about whether GC.SuppressFinalization(this) should go before or after the cleanup code. Some argue after, in case something goes wrong before you've finished cleaning up. Others argue before, otherwise you may open up a race condition between your finalizer and your Dispose method. You should consider both strategies depending on your object's implementation.
• Don't throw exceptions in Dispose. Nothing should go wrong with your object calling Dispose. Mainly for reasons stated above.
• Throw ObjectDisposedException if a caller tries to use a released resource. You may be in a situation where you've disposed of your object because you no longer need the unmanaged resource, but you still need to have the object hanging around. If this is the case, any methods that would normally access the resource should throw an ObjectDisposedException, while other (possibly useful) methods should not.
• Don't call Dispose from one thread, while still using the object on another. Try to make the thread that created the object be the one that disposes of it. This is more general good multithreaded programming advice, then Dispose specific.
• Whenever possible, follow the Dispose Pattern. That link, one more time: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfinalizedispose.asp.

Excellent Garbage Collection Blog - Chris Lyon's Blog

This page has lots of indepth info about the GC. Very good reading in deed. http://blogs.msdn.com/clyon/ Here are some excerpts: A few GC links that Chris has collected : http://blogs.msdn.com/clyon/archive/2004/09/14/229477.aspx Patterns and Practices for Dispose and Finalization: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfinalizedispose.asp About Dispose: At what point in an object’s lifetime does the GC call Dispose. The answer: Never.

Dispose is just a method, like any other. Its purpose is allow deterministic resource cleanup, much like C++’s destructors, but without freeing the object’s memory. Like a C++ destructor, the developer puts whatever cleanup code is necessary to be performed when the object’s lifetime is up. Unlike a destructor, the object lives on after being "disposed of". This means an object may be in an invalid state after being disposed, and developers should consider using ObjectDisposedExceptions when methods in a disposed object are called.

What happens when you call Dispose()

Any cleanup your object need done in a timely fashion should be done in Dispose. Things like closing database connections, closing files, releasing bitmaps, etc. Unmanaged resources in particular should be released in Dispose. This is because the GC has no knowledge of anything not allocated on the managed heap. For example, a Bitmap object that encapsulates a 2MB image file reports only its managed size (the size of the managed object) to the GC. The GC knows nothing about the 2MB unmanaged image, thus will not collect it from memory. By calling Dispose, you tell the Bitmap object that you are finished with it, and it will release the image itself.

What about the finalizer?

There are a few reasons why not to rely on the finalizer to clean up resources that I’ll cover in a future blog entry on finalizers. The main reasons you should be concerned with are performance and determinism. Finalizers are expensive to run, and there’s no order (or even guarantee) that they will be run (for example, the finalizer thread may time out, or be killed on AppDomain unload).

That being said, the finalizer should be your last chance to clean up resources, in case someone using your class forgets to dispose of it when done. A call to Dispose inside the finalizer reduces duplication of code. However, you want to make sure the resources don’t get released twice. In your Dispose method, you want to make sure you call GC.SuppressFinalize(this) after your clean up code. If you suppress the finalizer before the clean up, you’re limiting your ability to recover from failures during the cleanup.

Some of you may have noticed a race condition in my description above. Consider a situation where the call to Dispose is the last time your object is being referenced. As soon as Dispose is entered, the object is eligible for collection by the GC. Before that happens, the object’s finalizer gets called, which calls Dispose. You now have two threads inside Dispose, possibly double-freeing resources (this could be bad, as in the case of GCHandles). Make sure you follow the pattern I linked to above and use a disposing flag to avoid problems like this.

.net CLR garbage collection

While looking through our application on how to optimize it, I had several questions about the debugger, like: 1. When does the CLR decide to run the garbage collection (GC). 2. What is the size of the managed heap. How does it resize 3. What are the implications of GC on speed of the application. Found all my answers and more at these websites. The following 2 give an excellent introduction to the GC algorithm that .NET uses. (recommended read) http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetGCbasics.asp Did you know that in tests, the CLR was quicker in allocating memory then normal win32 allocations. Apparently, the reason is that one can always be assured that when the CLR is requested for memory consecuitevely the space will be contigous and hence could all be in the CPU's memory, whereas in Win32, the memory could be fragmented and all over the place. Under the normal course of events, the GC performs periodic collections after every 1MB of allocations, the heap is compacted if it gets too fragmented, and empty segments are returned to the operating system as long as the collector’s 1 MB cache is full (this is for the .NET compact framework) http://blogs.msdn.com/stevenpr/archive/2005/12/14/503818.aspx Another page that is very good (this is a white paper) http://www.gotdotnet.com/team/libraries/whitepapers/resourcemanagement/resourcemanagement.aspx The following pages(blogs) have lots of in depth info about the operations of the garbage collector in .NET Using GC Efficiently – Part 1 by Maoni http://blogs.msdn.com/maoni/archive/2004/06/15/156626.aspx Using GC Efficiently – Part 2 by Maoni http://blogs.msdn.com/maoni/archive/2004/09/25/234273.aspx Using GC Efficiently – Part 3 by Maoni http://blogs.msdn.com/maoni/archive/2004/12/19/327149.aspx Using GC Efficiently – Part 4 by Maoni http://blogs.msdn.com/maoni/archive/2005/05/06/415296.aspx Using performance counters http://blogs.msdn.com/maoni/archive/2004/06/03/148029.aspx Tools for debugging memory related problems http://blogs.msdn.com/maoni/archive/2004/11/08/254288.aspx Finalization and GC http://blogs.msdn.com/maoni/archive/2004/11/04/252697.aspx

Corpscon Version 6.0

Corpscon Version 6.0: "Corpscon, Version 6.0, is a MS-Windows-based program which allows the user to convert coordinates between Geographic, State Plane, Universal Transverse Mercator (UTM) and US National Grid systems on the North American Datum of 1927 (NAD 27), the North American Datum of 1983 (NAD 83) and High Accuracy Reference Networks (HARNs). Corpscon uses the National Geodetic Survey (NGS) program Nadcon to convert between NAD 27, NAD 83 and HARNs. Corpscon, Version 6.0, performs vertical conversions to and from the National Geodetic Vertical Datum of 1929 (NGVD 29) and the North American Vertical Datum of 1988 (NAVD 88). Vertical conversions are based on the NGS program Vertcon and can be performed for the continental U.S. only. Corpscon, Version 6.0, will also calculate geoid-ellipsoid separations based on the NGS program GeoidXX (XX = 90, 93, 96, 99, and 03). Geoid-ellipsoid separations can be calculated for the Continental U.S., Alaska, Hawaii and Puerto Rico/U.S. Virgin Islands."