This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
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.
Add property HardLimitBytes to GCMemoryInfo #25437
Add property HardLimitBytes to GCMemoryInfo #25437
Changes from 6 commits
9035562
b095f24
a9c48ae
6447db8
c485038
cb8f824
a92324c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the
last_gc_memory_load
relative tototal_physical_mem
; or relative to*totalAvailableMemoryBytes
?Either this or the previous line looks wrong. When memory load is
100%
, I thinkloadBytes
should be equaltotalAvailableMemoryBytes
.It may be best to get rid of the
*lastRecordedMemLoadPct
argument, and just dividelastRecordedMemLoadBytes
andtotalAvailableMemoryBytes
on the CoreLib side.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
last_gc_memory_load is relative to total_physical_mem. the problem is we do have a GetMemoryLoad that needs the actual memory load.
I would really prefer our original API proposal that had both the total physical memory and the hardlimit for the GC heap 'cause we do care about both. and I don't think it's unreasonable for the users to know about both. either that or we have another API (internal) that gets the actual physical memory load.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
last_gc_memory_load
is relative tototal_physical_mem
. IftotalAvailableMemoryBytes
is less thantotal_physical_mem
, then it will be impossible forlast_gc_memory_load
to ever reach 100% -- it would be at mosttotalAvailableMemoryBytes / total_physical_mem * 100
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The primary reason why we have introduced the
GCMemoryInfo
API is to allow folks to build self-tuning caches.Could you please review the places where this API is used currently (our
TlsOverPerCoreLockedStacksArrayPool
in particular - not sure whether there is anything else) and validate that it works correctly in all cases (regular VMs, containers, hardlimit)?The current code for this is here:
coreclr/src/System.Private.CoreLib/shared/System/Buffers/TlsOverPerCoreLockedStacksArrayPool.cs
Line 303 in 4ca032d
This is used by the internal experimental
MemoryLoadChangeNotification
APIs. Is this API used by anything?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the impl in TlsOverPerCoreLockedStacksArrayPool.cs looks correct - it could be improved (for example it could say only trim if the size it trims could actually make a difference in memory pressure) but I don't think we are doing that for 3.0.
it seems awkward to have to fit the 2 numbers (actual physical memory and hardlimit) into 1. and if we don't want to have to call the diagnostics API to retrieve the physical memory (which also seems awkward for GC) our original proposal seems more sensible to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What logic do we think would need to look at physical memory rather than the hard limit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have received a lot of feedback in 2.x about ArrayPool keeping too much memory over time. We have seen people taking extreme measures like poking the ArrayPool via private reflection to make it release the memory. We have implemented the trimming at the last minute to mitigate the situation.
If the ArrayPool trimming does not take the hardlimit into account, I expect that we are going to hear the same feedback again from folks who try to use the hardlimit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right I'm agreeing with your assessment. I'm mostly wondering when you'd need the actual physical memory vs the hard limit (the other should probably be exposed where we have the other process specific APIs Process.*)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(My reply was for Maoni's comment.)
I agree that the actual physical memory does not seem to be necessary to build decent trimming heuristic.
I think that there are 4 numbers to feed into a decent basic trimming heuristic:
HeapSizeBytes
andTotalAvailableMemoryBytes
in the current API.MemoryLoadBytes
andHighMemoryLoadThresholdBytes
in the current API.When either of these gets too close to its limit, it is a signal to trim caches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have opened https://github.com/dotnet/coreclr/issues/25552 on ArrayPool not respecting GCHardLimit.