Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typos #1409

Merged
merged 1 commit into from
Jan 14, 2017
Merged

typos #1409

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
typos
  • Loading branch information
@noopcat
noopcat authored Jan 14, 2017
commit 680e1c50725d068b17ee14ac4f9150a149a89a17
2 changes: 1 addition & 1 deletion docs/standard/garbagecollection/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ The garbage collector serves as an automatic memory manager. It provides the fol

The .NET GC is generational and has 3 generations. Each generation has its own heap that it uses for storage of allocated objects. There is a basic principle that most objects are either short lived or long lived. Generation 0 is where objects are first allocated. Objects often don’t live past the first generation, since they are no longer in use (out of scope) by the time the next garbage collection occurs. Generation 0 is quick to collect because its associated heap is small. Generation 1 is really a second chance space. Objects that are short lived but survive the generation 0 collection (often based on coincidental timing) go to generation 1\. Generation 1 collections are also quick because its associated heap is also small. The first two heaps remain small because objects are either collected or are promoted to the next generation heap. Generation 2 is where all long lived objects are. The generation 2 heap can grow to be very large, since the objects it contains can survive a long time and there is no generation 3 heap to further promote objects.

The GC has has an additional heap for large objects called the Large Object Heap (LOH). It is reserved for objects that are 85,000 bytes or greater. A byte array (Byte[]) with 85k elements would be an example of a large object. Large objects are not allocated to the generational heaps but are allocated directly to the LOH.
The GC has an additional heap for large objects called the Large Object Heap (LOH). It is reserved for objects that are 85,000 bytes or greater. A byte array (Byte[]) with 85k elements would be an example of a large object. Large objects are not allocated to the generational heaps but are allocated directly to the LOH.

Generation 2 and LOH collections can take noticeable time for programs that have run for a long time or operate over large amounts of data. Large server programs are known to have heaps in the 10s of GBs. The GC employs a variety of techniques to reduce the amount of time that it blocks program execution. The primary approach is to do as much garbage collection work as possible on a background thread in a way that does not interfere with program execution. The GC also exposes a few ways for developers to influence its behavior, which can be quite useful to improve performance.

Expand Down