-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0 #22204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back jsjolen! A progress list of the required criteria for merging this PR into |
@jdksjolen This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 99 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@jdksjolen The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
/label hotspot-runtime |
@jdksjolen |
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.
Looks good.
test/jdk/jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java
Outdated
Show resolved
Hide resolved
Leonid convinced me that it's unnecessary to have the ZGC case for the test, so I removed it. |
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.
Just and observation - you used here the acronym MFT
and it just jumped out at me, then I looked at memoryFileTracker
and it feels inconsistent to me.
Did we ever consider naming it nativeMemoryFileTracker
? Then we would have NMFT
, which extends NMT
better, IMHO.
Just something to keep in mind if we ever feel like cleaning up the names in NMT
area.
src/hotspot/share/nmt/nmtUsage.cpp
Outdated
|
||
{ // MemoryFileTracker addition | ||
using MFT = MemoryFileTracker::Instance; | ||
MFT::Locker lock; | ||
MFT::iterate_summary([&](MemTag tag, const VirtualMemory* vm) { | ||
int i = NMTUtil::tag_to_index(tag); | ||
_vm_by_type[i].reserved += vm->reserved(); | ||
_vm_by_type[i].committed += vm->committed(); | ||
_vm_total.reserved += vm->reserved(); | ||
_vm_total.committed += vm->committed(); | ||
}); | ||
} |
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 am missing something here, in memoryFileTracker.hpp you say:
// All memory is accounted as committed, there is no reserved memory.
// Any reserved memory is expected to exist in the VirtualMemoryTracker.
but here we use MFT to account for both reserved and committed?
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.
Ah, we actually do use VirtualMemory here to track the memory. Never mind!
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.
Yeah, but it is actually 0 :). I wanted to future proof this code, if we ever do use reserved
here. I'll assert that reserved
is 0 with a good message, then we can fix the code if our assumptions change.
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.
Sorry, I was pretty confused here. We need to remove the reserved additions, otherwise we double-account reserved memory.
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.
LGTM
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.
That matches the comments from src/hotspot/share/nmt/memoryFileTracker.hpp
I've seen the issue of overcounting pop-up couple of times recently - can we write a test that checks and would have caught the issue we ran into just here?
Cheers Gerard. I'm not entirely sure of how to write a test for catching this, if you have any ideas that'd be great. /integrate |
Going to push as commit 2ea0364.
Your commit was automatically rebased without conflicts. |
@jdksjolen Pushed as commit 2ea0364. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Background
With the implementation of JDK-8312132 we added the
MemoryFileTracker
(MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC.The fix
I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the
VirtualMemoryTracker
. I also added an explicitrun
usingZGC
to the failing test, to ensure that any actual regressions are found.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204
$ git checkout pull/22204
Update a local copy of the PR:
$ git checkout pull/22204
$ git pull https://git.openjdk.org/jdk.git pull/22204/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22204
View PR using the GUI difftool:
$ git pr show -t 22204
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22204.diff
Using Webrev
Link to Webrev Comment