The release of Visual Studio 2012 brought with it .NET Framework 4.5, and many interesting nes features. In this article the first in a short series on the new Framework I'll examine the most useful global improvements that affect the Common Language Run-time (CLR).
.NET Framework 4.5 does not support Windows XP or Windows Server 2003, and therefore, if you have to create applications that target these operating systems, you will need to stay with .NET Framework 4.0. In contrast, Windows 8 and Windows Server 2012 in all of their editions include .NET Framework 4.5.
You can install .NET Framework 4.5 in any of the following operating systems (which do not include it):
- Windows 7 (64-bit and 32-bit)
- Windows Vista with Service Pack 2, also known as SP2 (64-bit and 32-bit)
- Windows Server 2008 R2 (it is only available in 64-bit). .NET Framework 4.5 supports Server Core Role with Service Pack 1, also known as SP1 or later
- Windows Server 2008 (64-bit and 32-bit). However, .NET Framework 4.5 doesn't support Server Core Role on this operating system
.NET Framework 4.5 does not support Itanium processors. If you install it on any of the listed operating systems, the installation detects and closes .NET Framework 4 applications to reduce the necessary system restarts. It also replaces .NET Framework 4 files, and therefore, it requires applications that use those files to be closed or you will have to restart to complete installation.
Support for Arrays Larger than 2 GB on 64-bit Platforms
One of the most frustrating experiences I have had with 64-bit support on the .NET Framework is the limitation on arrays, which cannot exceed 2 GB. One of the main reasons you move to 64-bit platforms is to access more than 2 GB, and this limitation was a big problem for those of us trying to work with large matrices and vectors. No matter the amount of available RAM available, it was very common to have a System.
OutOfMemoryException whenever you worked with large matrices and vectors, as follows:
System.OutOfMemoryException was unhandled HResult=-2147024882 Message=Exception of type 'System.OutOfMemoryException' was thrown. Source=Console64BitArrays
Thankfully, .NET Framework 4.5 introduces a configuration attribute in the run-time schema that enables arrays larger than 2 GB in total size on 64-bit applications. You need only enable the
gcAllowVeryLargeObjects element that controls the behavior of the .NET garbage-collection system. For example, line 7 in the following
App.config example of a 64-bit .NET Framework 4.5 console application enables
<?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> <runtime> <gcAllowVeryLargeObjects enabled="true" /> </runtime> </configuration>
This way, it is possible to take better advantage of available memory when working with huge arrays on 64-bit platforms (see Figure 1).
Figure 1: Inspecting an array of 150,000,000 decimal elements in Visual Studio 2012, with an application that has gcAllowVeryLargeObjects enabled.
You can combine this setting with the garbag- collection improvements explained in the next section. The bad news is that the maximum number of elements in arrays is still the same as in .NET Framework 4.0.
Enhanced Background Server Garbage Collection
.NET Framework 4.5 changes the default mode for server garbage collection to the new background server garbage collection. Thus, whenever you enable the
gcServer element in the run-time schema to change from the default workstation garbage collection to server garbage collection, you will be activating the new mode.
For example, line 7 in the following
App.config example of a 64-bit .NET Framework 4.5 console application activates background server garbage collection:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> <runtime> <gcServer enabled ="true" /> </runtime> </configuration>
A common problem with previous versions of the .NET Framework with multithreaded applications was frequent garbage collections that blocked all the threads until the collection completed. That was typical with workstation garbage collection and the pattern is known as "workstation garbage collection overhead."
Whenever you couldn't reduce the memory pressure in your algorithms, you usually achieved a speedup by enabling the server garbage collection, also known as "Server GC," by simply enabling the
gcServer element in the run-time schema. The Server GC would maximize throughput and improve scalability as the number of available cores increased because it dedicated more threads to garbage collection and reduced the overall time to complete garbage collection. The drawback was that it required scheduling more threads than the workstation garbage collection mechanism.
The new background server garbage collection usually creates a managed heap and one dedicated background garbage-collection thread per logical core. Each background garbage-collection thread has its appropriate thread-affinity setting assigned to each available logical core. These background garbage-collection threads don't time out and can remove dead objects and expand heap. The improved algorithms reduce the amount of foreground garbage collections, and hence, improve overall throughput.
The good news is that you don't have to make changes in your code. If you were already using server garbage collection, you will usually notice increased throughput and fewer threads blocked until foreground collection finishes in .NET Framework 4.5.