Certainly that\u2019s one of the most frequently asked questions I get (at the PDC too!). So since PDC already happened I can tell the rest of you about the new stuff happened in GC in CLR 2.0. The slides can be downloaded <\/FONT>here<\/FONT><\/A>. And I will be referring to some of the slides. I must apologize for your having to click on the link to see the slide each time I refer to one since I don\u2019t have a separated site where I can store pictures.<\/FONT><\/P>\n <\/FONT> <\/P>\n Most of what I am going to talk about was covered in my PDC GC talk. BTW, just a few words about the 2005 PDC (skip this paragraph if you are interested in only technical stuff \ud83d\ude42<\/FONT>). I was very pleased with the way it went. I got to talk to lots of customers who told me how awesome our GC was which certainly made me feel very good! There were a couple of customers who did tell us about the problems they had with our GC. One problem we already addressed in Whidbey and the other one was something we were perfectly aware of and had put on our todo list. So no surprises there. I was happy to see the number of people at my talk considering it was the latest possible and lots of people had already left the conference before that. So all in all it was great.<\/FONT><\/FONT><\/P>\n <\/FONT> <\/P>\n Some terminology before we start:<\/FONT><\/P>\n <\/FONT> <\/P>\n Ephemeral generations<\/I> \u2013 gen0 and gen1.<\/FONT><\/FONT><\/P>\n <\/FONT> <\/P>\n Ephemeral segment<\/I> \u2013 the segment that gen0 and gen1 live in (they always live in one segment) and there can only be one ephemeral segment for each heap. So for server GC, if we have 4 heaps we have 4 ephemeral segments (refer to my <\/FONT><\/FONT>Using GC Efficiently \u2013 Part 2<\/FONT><\/A> for explaination for different flavors of GCs).<\/FONT><\/P>\n <\/FONT> <\/P>\n Small object heap<\/I> \u2013 you know LOH (if you don\u2019t, it\u2019s covered in <\/FONT><\/FONT>Using GC Efficiently \u2013 Part 1<\/FONT><\/A>), so the rest of the managed heap is called small object heap \ud83d\ude42<\/FONT><\/FONT><\/P>\n <\/SPAN><\/SPAN><\/FONT> <\/P>\n <\/SPAN><\/SPAN><\/FONT>Fragmentation control<\/FONT><\/FONT><\/B><\/P>\n <\/FONT><\/STRONG> <\/P>\n If you ask me what was the most significant improvement in the CLR 2.0 GC from the 1.1 GC, I\u2019d have to say it\u2019s the work we did in reducing fragmentation caused by pinning.<\/FONT><\/P>\n <\/FONT> <\/P>\n One of the biggest problems we faced for managed applications was wasted free space on the managed heap. And sometimes you get OOM while there\u2019s plenty of free space on the managed heap. So reducing fragmentation, in other words, having less space wasted on the managed heap, was crucial. It was observed often in applications that perform IO which needs to pin the buffers for the native APIs to read or write to them. As such, we\u2019ve done a lot of work in CLR 2.0 to help solve this <\/FONT><\/P>\n problem.<\/FONT><\/P>\n <\/FONT> <\/P>\n Slide 25<\/FONT><\/A> demonstrates the fragmentation problem caused by pinning. Let\u2019s say we have an application where each request performs some type of socket or file IO. Before GC number X we have a heap that has one segment, which is our ephemeral segment, has bunch of stuff allocated in gen0, including some pinned objects. Now a GC is triggered. After the collection what survived from gen1 was promoted to gen2. For a simplistic view let\u2019s just say nothing from gen0 except the pins survived. In reality what survived is the pinned objects and the other data associated with the requests that pinned those objects for this scenario. So after the collection, gen1 just has the pins \u2018cause that\u2019s all that survived from gen0. Gen0 then starts right after the 2nd<\/SUP> pin.<\/FONT><\/P>\n <\/FONT> <\/P>\n You can imagine that if this process keeps repeating itself, and let\u2019s say that the pins survived N more GCs, after these GCs we may have a situation where we have expanded the heap and the old ephemeral segment now is a gen2 segment and we acquired a new ephemeral segment. Again we start the new gen0 after the pins in the ephemeral segment.<\/FONT><\/P>\n <\/FONT> <\/P>\n This is a really bad situation because we now have lots of wasted space on our heap. Both our gen2 and gen1 look quite empty. Obviously the less wasted space we can make it, the better.<\/FONT><\/P>\n <\/FONT> <\/P>\n The fragmentation reduction work can be categorized into 2 things: one is called demotion<\/I> which is to prevent fragmentation from getting into higher generation as much as we can; the other one is reusing existing gen2 segments<\/I> so we can reuse the free space that has already made into gen2. Let\u2019s talk about them in more details.<\/FONT><\/P>\n <\/FONT> <\/P>\n Demotion, as the opposite of promotion, means the object doesn\u2019t end up in a generation that it\u2019s supposed to be in. Imagine if after the compaction, there\u2019s plenty of space between some pinned objects at the end of the ephemeral segment, it\u2019s more productive to leave them in gen0 instead of promoting them to gen1 because when allocation requests come in the free space before the pins can be used to satisfy allocations. This is demonstrated with <\/FONT>slide 26<\/FONT><\/A>.<\/FONT><\/P>\n <\/FONT> <\/P>\n Segment reuse is relatively straightforward. It\u2019s to take advantage of the existing gen2 segments that have a lot free space but not yet empty (because if they were empty they would have been deleted). <\/FONT>Slide 27<\/FONT><\/A> demonstrates the problem without segment reuse. So before GC we are running out of space in the ephemeral segment and we need to expand the heap. We have 2 pinned objects. And I didn\u2019t mark their generations because it\u2019s not significant to indicate their generations – they can not be moved so they will stay in this segment and become gen2 objects by definition. There might be pinning on the gen2 segments as well but since that doesn\u2019t affect illustrating the point I preferred to keep the picture simple and left them out.<\/FONT><\/P>\n