CR feedback

Author: Maoni0

xml/System/GC.xml

@@ -126,9 +126,9 @@ 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.
+ If you have a convenient place to call these APIs, you don't necessarily have to use a finalizer. For example, if you know you can release the native memory when a specific method on the type is called, you can call the <xref:System.GC.RemoveMemoryPressure%2A> method at that point instead of having a finalizer.
 
 > [!CAUTION]
 >  You must ensure that you remove exactly the amount of pressure you add. Failing to do so can adversely affect the performance of the system in applications that run for long periods of time.
@@ -1697,9 +1697,9 @@ The following example demonstrates the use of the <xref:System.GC.GetGeneration%
           <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.
+ If you have a convenient place to call these APIs, you don't necessarily have to use a finalizer. For example, if you know you can release the native memory when a specific method on the type is called, you can call the <xref:System.GC.RemoveMemoryPressure%2A> method at that point instead of having a finalizer.
 
 > [!CAUTION]
 >  You must ensure that you remove exactly the amount of pressure you add. Failing to do so can adversely affect the performance of the system in applications that run for long periods of time.