Report native memory pressure to GC #1514
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reports the native memory pressure of any CsWinRT projected RCWs to the .NET GC. The .NET GC keeps track of managed memory and is not aware of native memory usage of anything that the C# managed objects are holding onto. So, in the case of CsWinRT projected RCWs, the .NET GC is aware of the managed memory usage of CsWinRT's RCW projection implementation, but the native WinRT object being held on can be using much more memory that the GC isn't aware of. By reporting this native memory pressure to the .NET GC, .NET is able to run the GC more often as needed based on memory usage and thereby making sure any collected objects are indeed finalized releasing the native memory. There is another similar change on the WinUI side this works together with which reports WinUI native memory pressure.
GCPressure
attribute on RCWs and how much it indicates to reportIObjectReferences
as they are holding onto WinRT objects. This PR uses a simplified approach to achieving this by reporting it for anyIObjectReference
. In theory, multipleIObjectReferences
can be pointing to the same WinRT object and we don't need to report native memory pressure each time, but we shouldn't have too much of an impact by doing so. In order to do the non-simplified approach, it will require another object allocation which isn't finalized until all theIObjectReferences
held onto by an RCW or was from a QI from it is disposed. This gets more complicated to implement due to needing to wait for all relatedIObjectRefrences
to finalize so deferring on that until there is a need for it.Related: dotnet/runtime#36762
Supersedes: #837