Under the Hood of .NET Memory Management - Simple Talk

More documents

Recommendations

Info

Chapter 2: The Simple Heap Model To overcome the fragmentation problem, the GC compacts the heap (as mentioned in the previous chapter), and thereby removes any gaps between objects. If the GC cleaned up the heap in Figure 2.2, it would look like the example in Figure 2.3 after the GC had completed its work. Figure 2.3: SOH after compaction. Notice that Object A has been removed, and that its space has been taken up by the other objects. As a result of this process, fragmentation of the SOH is drastically reduced, although it can still happen if objects are deliberately pinned in memory (more on this in Chapter 3). What's still in use? In Chapter 1 we looked conceptually at the kind of algorithms used by the GC to determine which objects are still being used and those that aren't. The rule is really very simple: "If you don't ultimately have a root reference, then you can't be accessed, so you must die." Harsh, maybe, but very effective. When it runs, the GC gets a list of all root references and, for each one, looks at every referenced object that stems from that root, and all the objects they contain recursively. Every object found is added to a list of "in use objects." Conversely, any object not on the list is assumed to be dead and available for collection, which simply involves compacting 42
Chapter 2: The Simple Heap Model the heap by copying live objects over the top of dead ones. The result is a compacted heap with no gaps. Conceptually, everything I just said is correct but, as I mentioned in Chapter 1, whether the actual GC code performs "object in use" processing with a separate marking phase, sweeping phase, and compacting phase, is sometimes difficult to determine. What is clear is that the GC algorithm will be optimized to the maximum for releasing objects as soon as possible, while touching as few objects as possible. While it doesn't always get it right, that's the context you should always see it in. Optimizing garbage collection If you think about it, there's potentially a bit of a problem with creating "still in use" lists and compacting the heap, especially if it's very large. Navigating through huge object graphs and copying lots of live objects over the top of dead ones is going to take a significant amount of processing time. To get maximum performance, that whole process needs to be optimized, and that's just what the .NET GC guys did. They decided to classify all objects into one of three groups. At one end, you've got short-lived objects that are allocated, used and discarded quickly. At the other end of the spectrum, you have long-lived objects which are allocated early on and then remain in use indefinitely. Thirdly and finally, you have, you guessed it, medium-lived objects, which are somewhere in the middle. When they analyzed typical allocation patterns they discovered that short-lived objects are far more common than long-lived ones. They also realized that the most likely contenders for GC were the most recently allocated objects. Because most objects are created within a method call and go out of scope when the method finishes, they are, by definition, short lived. So a really cool optimization was developed, which involved inspecting and collecting the most recently allocated objects more frequently than the older objects. 43
Page 1 and 2: .NET Handbooks Under the Hood of .N
Page 3 and 4: Copyright November 2011 ISBN 978-1-
Page 5 and 6: Workstation GC mode ...............
Page 7 and 8: Section 3: Deeper .NET ............
Page 9 and 10: I also want to thank the countless
Page 11 and 12: Introduction Tackling .NET memory m
Page 13 and 14: Section 1: Introduction to .NET Mem
Page 15 and 16: Chapter 1: Prelude The truth is, by
Page 17 and 18: Chapter 1: Prelude 7 { 8 int multip
Page 19 and 20: Chapter 1: Prelude These are primit
Page 21 and 22: Chapter 1: Prelude 1 void ValueTest
Page 23 and 24: Chapter 1: Prelude On the other han
Page 25 and 26: Chapter 1: Prelude Because paramete
Page 27 and 28: Chapter 1: Prelude 1 int i=12; 2 Ar
Page 29 and 30: Chapter 1: Prelude When an Order is
Page 31 and 32: Chapter 1: Prelude Void Mark(object
Page 33 and 34: Chapter 1: Prelude To access each m
Page 35 and 36: Chapter 1: Prelude [ThreadStatic] p
Page 37 and 38: Chapter 2: The Simple Heap Model Co
Page 39 and 40: Chapter 2: The Simple Heap Model Wh
Page 41: Chapter 2: The Simple Heap Model Fi
Page 45 and 46: Chapter 2: The Simple Heap Model Fi
Page 47 and 48: Chapter 2: The Simple Heap Model Fi
Page 49 and 50: Chapter 2: The Simple Heap Model Ob
Page 51 and 52: Chapter 2: The Simple Heap Model ou
Page 53 and 54: Chapter 2: The Simple Heap Model Pe
Page 55 and 56: Chapter 2: The Simple Heap Model La
Page 57 and 58: Chapter 2: The Simple Heap Model Ul
Page 59 and 60: Chapter 3: A Little More Detail Now
Page 61 and 62: Chapter 3: A Little More Detail It'
Page 63 and 64: Chapter 3: A Little More Detail In
Page 65 and 66: Chapter 3: A Little More Detail Con
Page 67 and 68: Chapter 3: A Little More Detail Bac
Page 69 and 70: Chapter 3: A Little More Detail Alt
Page 73 and 74: Chapter 3: A Little More Detail Wea
Page 75 and 76: Chapter 3: A Little More Detail …
Page 77 and 78: Chapter 3: A Little More Detail GC
Page 81 and 82: What's Coming Next In this next sec
Page 83 and 84: • Use a struct to represent any i
Page 86 and 87: Chapter 4: Common Memory Problems T
Page 88 and 89: Chapter 4: Common Memory Problems V
Page 90 and 91: Chapter 4: Common Memory Problems c
Page 92 and 93:
Chapter 4: Common Memory Problems i
Page 94 and 95:
Chapter 4: Common Memory Problems u
Page 96 and 97:
Chapter 4: Common Memory Problems T
Page 98 and 99:
Chapter 4: Common Memory Problems i
Page 100 and 101:
Chapter 4: Common Memory Problems S
Page 102 and 103:
Chapter 4: Common Memory Problems p
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Chapter 4: Common Memory Problems s
Page 110 and 111:
Chapter 4: Common Memory Problems Y
Page 112 and 113:
Chapter 4: Common Memory Problems v
Page 114 and 115:
Chapter 4: Common Memory Problems {
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Chapter 4: Common Memory Problems [
Page 122 and 123:
Page 124 and 125:
Chapter 4: Common Memory Problems D
Page 126 and 127:
Page 128 and 129:
Chapter 4: Common Memory Problems C
Page 130 and 131:
Chapter 4: Common Memory Problems W
Page 132 and 133:
Page 134 and 135:
Chapter 4: Common Memory Problems [
Page 136 and 137:
Chapter 4: Common Memory Problems A
Page 138 and 139:
Page 140 and 141:
Chapter 4: Common Memory Problems U
Page 142 and 143:
Page 144 and 145:
Chapter 4: Common Memory Problems K
Page 146 and 147:
Chapter 5: Application-Specific Pro
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Section 3: Deeper .NET
Page 180 and 181:
Chapter 6: A Few More Advanced Topi
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Chapter 7: The Windows Memory Model
Page 200 and 201:
Page 202 and 203:
Page 204 and 205:
Page 206 and 207:
Page 208 and 209:
Page 210 and 211:
Page 212 and 213:
Page 214 and 215:
.NET and SQL Server Tools from Red
Page 216 and 217:
.NET Reflector ® Decompile, browse
Page 218 and 219:
SQL Prompt Pro Write, edit, and exp
Page 220 and 221:
SQL Monitor SQL Server performance
Page 222 and 223:
SQL Toolbelt The essential SQL Serv
Page 224:
Brad's Sure Guide to SQL Server Mai
show all

Under the Hood of .NET Memory Management - Simple Talk

Create successful ePaper yourself

Delete template?

Save as template?