Skip to content

Commit

Permalink
Update xml/System/GC.xml
Browse files Browse the repository at this point in the history
Co-authored-by: Genevieve Warren <[email protected]>
  • Loading branch information
Maoni0 and gewarren authored Jan 9, 2025
1 parent 3441ec1 commit e4b29a3
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion xml/System/GC.xml
Original file line number Diff line number Diff line change
Expand Up @@ -126,7 +126,8 @@ The following example uses several GC methods to get generation and memory infor
<format type="text/markdown"><![CDATA[
## Remarks
The common pattern of releasing native resources is via a finalizer on the type. If a managed object uses native memory, it could free that native memory in its finalizer. The garbage collector only knows about managed memory and schedules collections based on this knowledge. Imagine a scenario where a small managed object is associated with a large amount of native memory usage and this managed object now lives in gen2. A gen2 GC may not happen for quite some time which means this large amount of native memory will not be released till the next gen2 happens. The runtime provides the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to help with this scenario. The runtime keeps an internal record of how much these APIs added and removed, and triggers a gen2 GC if deemed productive. So this is not a feature of the GC but rather something that the runtime provides to trigger GCs.
The common pattern for releasing native resources is via a type's finalizer. If a managed object uses native memory, it can free that native memory in its finalizer. The garbage collector only knows about managed memory and schedules collections based on this knowledge. Imagine a scenario where a small managed object is associated with a large amount of native memory usage, and this managed object now lives in gen2. A gen2 GC might not happen for some time, which means the large amount of native memory won't be released until the next gen2 happens. The runtime provides the <xref:System.GC.AddMemoryPressure%2A> and <xref:System.GC.RemoveMemoryPressure%2A> methods to help with this scenario. The runtime keeps an internal record of how much memory pressure these APIs added and removed, and triggers a gen2 GC if deemed productive. So this is not a feature of the GC but rather something that the runtime provides to trigger GCs.
If you have a convenient place to call these APIs, you don't necessarily have to have a finalizer. For example, when a specific method on the type is called you know you can release the native memory, you can call the <xref:System.GC.RemoveMemoryPressure%2A> method at that point instead of having a finalizer.
Expand Down

0 comments on commit e4b29a3

Please sign in to comment.