[GR-57310] NMT simplified virtual memory tracking. #9505
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oracle-contributor-agreement
bot
added
the
OCA Verified
roberttoyonaga
force-pushed
the
nmt-vmem-simple
branch
from
0fecf52 to
60a62b5
Compare
roberttoyonaga
force-pushed
the
nmt-vmem-simple
branch
from
60a62b5 to
3564dce
Compare
christianhaeubl
changed the title
|
Realized I needed to make a small change to consider all image heap regions when determining the size. I'm done making changes now. |
|
Thanks for the PR. I had to change a few things, so I opened another PR based on your changes: #9549. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
This is a simplified version of #8630
This PR adds virtual memory tracking, but makes the assumption that virtual memory is used neatly (no overlapping committed regions etc). Please see the javadoc in
NativeMemoryTrackingfor more info.Notes:
There's 3 approaches we could take with this simplified version.
HeapChunkProvider). This makes the caller responsible for correct instrumentation.NmtVirtualMemoryInfo. Instead, directly queryHeapAccountingwhenever we need to report virtual memory. This is probably less extensible than 1 or 3.VirtualMemoryProviderimplementations. Similar to the original PR. This would ensure we don't miss any allocations if virtual memory becomes used in other places in the future. However, I don't think this is necessary right now since virtual memory is used simply in SVM currently. We can avoid instrumenting in platform specific code.