What makes managed code, “managed”? Most people would point to the garbage collector. Automatic memory management makes a tremendous difference in programmer productivity. And when garbage collection improves, all .NET applications benefit. Abhishek Mondal, the program manager for GC on the Common Language Runtime, and Maoni Stephens, the developer for GC on the CLR, authored this article. -- Brandon
In this post, we will look at how the CLR garbage collector (GC) has been changed in the .NET Framework 4.5 to meet the needs of large client and server apps. These improvements are in response to requests from developers who use the .NET Framework to build large-scale commercial apps. Some of these customers have already reported significant wins after deploying the .NET Framework 4.5 (currently available as an RC release) into production.
The needs of large-scale apps
Ever since the .NET Framework was introduced, developers have been using this technology to build client and server apps of increasing size and complexity. The larger an app gets, the more resources it will consume, and memory is one of the major resources. For example, some developers have built massive-scale websites and services that are used by millions of end-users. These sites typically need to deliver some combination of high throughput and low latency, and have to provide access to data in huge databases. Each year, the traffic to these sites grows and so does the amount of data they serve up. At the same time, these developers also strive to deliver increasingly better end-user experiences, which are sometimes defined by formal service level agreements (SLA). We have seen similar examples on the client.
Developers adopt new approaches and architectures in their apps to meet the increasing demands of customers. Newer .NET Framework features such as the async pattern can sometimes help. However, developers of large-scale apps have told us that they need changes in the GC to continue to grow the scale of apps effectively, particularly on the server. We have many partners within Microsoft, such as Exchange Server, SQL Server, Bing, Microsoft Dynamics CRM, and SharePoint, who build sites that serve millions of visitors and who have the engineering experience to help validate the changes that we made to the CLR GC. We used the combination of customer requests that we received and the partner experience within Microsoft to determine a set of important improvements in the GC for the .NET Framework 4.5.
We are happy to report that we’ve improved the GC to handle the latest trend of workloads we are seeing, with heap sizes in the tens of gigabytes, running on machines with ever increasing memory and cores, and using configurations such as non-uniform memory access (NUMA).
Key customer scenarios for the .NET Framework 4.5 GC
After we collected feedback from developers and our Microsoft partners, we determined a set of GC improvements that would satisfy a broad set of the requests and that would benefit both server and client apps. I’ve listed the requests below, described in terms of app requirements.
Server apps
My app requires shorter pauses.
My app requires higher throughput.
My app should scale on modern hardware.
Client and server apps
My app cannot tolerate pauses during a certain time window.
The large object heap takes up too much space.
My app works on large datasets (uses objects> 2 GB).
Read more: .NET Framework Blog
QR: 
Posts
