how to create barcode in vb.net 2012 Controlling GC Behavior in Visual C#

Print PDF417 in Visual C# Controlling GC Behavior

At times, it may be useful to control the GC behavior. You should do this in moderation; the whole point of a managed environment is that it controls what s going on, and controlling it tightly can lead to problems elsewhere.

The function System.GC.Collect() can be called to force a collection. Avoid this call in production code. Forcing a garbage collection is usually done as a futile attempt to reclaim resources that should have been disposed, and this problem has other remedies, such as using code-quality tools from companies such as Compuware that can pinpoint missed Dispose() calls.

As mentioned earlier, an instance of an object is placed on the finalization list when it s created. If it turns out that an object doesn t need to be finalized (because the cleanup function has been called, for example), you can use the System.GC.SupressFinalize() function to remove the object from the finalization list.

The .NET Framework ships with two flavors of the garbage collection: server and workstation. The term flavor prevents confusion between the two different garbage collectors and different versions of the .NET Framework, such as 1.0, 1.1, and 2.0; we ll use this term for the rest of this discussion. The workstation garbage collection is further broken down into two separate modes: concurrent and nonconcurrent. Concurrent garbage collection refers to the execution of managed code while various aspects of a garbage collection cycle are being completed. In the early description of the Mark and Compact algorithm, we stated that all useful work needs to be stopped while a garbage collection takes place. With concurrent garbage collection, this isn t quite true, because execution of managed code (in other words, useful work) can still occur during a couple of places during the collection cycle, notably during the Mark stage. Concurrent garbage collection makes for a slower overall garbage collection cycle, but during the collection the application stays more responsive. These characteristics make it the best choice for interactive applications such as Windows Forms applications, and this is the default mode for the garbage collector. For some applications, such as those that operate in batch mode without a user interface, maximum performance in a garbage collection cycle is preferable to the minimization of pauses, and concurrent garbage collection should be turned off. If an unmanaged application written in a language such as C++ is explicitly hosting C# or other managed code, you can control the

CHAPTER 38 DEEPER INTO C#

use of concurrent garbage collection by the value of parameters passed to the hosting APIs (see the documentation for CorBindToRuntimeEx for details). For applications written entirely in managed code, you can use a configuration file setting to turn off concurrent garbage collection: <configuration> <runtime> <gcConcurrent enabled="false"/> </runtime> </configuration> For a multiprocessor machine, many different optimizations are possible. To implement these optimizations, a different flavor of the garbage collector is available. The server flavor of the garbage collection will load only on multiprocessor machines, but it s possible to also load the workstation flavor on these machines, and this is actually the default behavior. Prior to Service Pack 1 (SP1) of the .NET Framework 1.1, the only supported1 way to load the server flavor of the garbage collector was via the hosting APIs and the use of unmanaged code (again, see the documentation for CorBindToRuntimeEx for details). From .NET 1.1 SP1 onward, you can load the server flavor by using a configuration file setting: <configuration> <runtime> <gcServer enabled= true"/> </runtime> </configuration> The server flavor of the garbage collector doesn t have a concurrent collection mode, and managed code is suspended for the duration of a collection cycle. This means that for UI-centric applications, the server version of the runtime may not give the best appearance of performing as well as the workstation flavor using concurrent collection. This is the reason for the default choice of concurrent workstation garbage collection regardless of the number of processors present. For server applications, the optimizations present in the server flavor of the garbage collector can be quite significant. The main optimization is a separate garbage-collected heap and garbage collection thread for each processor. This dramatically reduces the amount of contention on global locks and resources needed to allocate and clean up memory. In the workstation flavor of the runtime, garbage collection takes places on the thread that requested the allocation that couldn t be satisfied from the currently available memory, which in turn triggered the garbage collection. In contrast, the optimizations in the server GC mean that every garbage-collected heap can be collected simultaneously, maximizing the use of the available processor power. The 2.0 release of the .NET Framework libraries includes a new class called GCSettings that can determine which flavor of the garbage collection is in use: bool isServerGC = GCSettings.IsServerGC;

1. You can use a Windows environment variable to instruct the CLR to load the server flavor of the garbage collector, but this was unsupported. To use this hack, create an environment variable called COMPLUS_BUILDFLAVOR and set it to svr.

CHAPTER 38 DEEPER INTO C#