-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
JDK-8261644: NMT: Simplifications and cleanups #2539
Conversation
👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into |
Webrevs
|
@tstuefe - Thanks for keeping cleanups separated from bug fixes. That always |
Thanks Dan. I updated the description. I'm very careful after JDK-8261520. Manual tests went through, nightlies at SAP are scheduled. BTW this patch is a preparation for the fix for JDK-8261520. |
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.
These changes look great. Thank you!
@@ -138,7 +138,7 @@ MallocSite* MallocSiteTable::lookup_or_add(const NativeCallStack& key, size_t* b | |||
MallocSiteHashtableEntry* head = _table[index]; | |||
while (head != NULL && (*pos_idx) <= MAX_BUCKET_LENGTH) { | |||
MallocSite* site = head->data(); | |||
if (site->flag() == flags && site->equals(key)) { | |||
if (site->equals(key, flags)) { |
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.
Does this now assert when it used to just return false if memflags didn't match?
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.
Yes, and it seems this actually fired tonight on s390x. Which indicates that the call stack frame skipping is off and we do skip too much. I opened https://bugs.openjdk.java.net/browse/JDK-8261556 to track this, and here I will restore the old behavior for now. That is also cleaner since this RFE should not have brought behavioral changes.
AllocationSite(stack, mtThreadStack), | ||
_base(base), | ||
_size(size) | ||
{} |
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.
nit: can you put {} on the same line as _size ?
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.
Done.
@tstuefe 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 91 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 |
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 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.
Looks good!
Thanks Coleen and Zhengyu! /integrate |
@tstuefe Since your change was applied there have been 93 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 5caf686. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Hi,
may I please have reviews for this RFE?
While working on NMT I found a number of possible cleanups and simplifications. I avoided mixing these cleanups with fixed and instead put them into this cleanup RFE.
There should be no behavioral changes in this patch.
de-templatize
AllocationSite<E>
since E was used as simple data holder for child classes; the same effect can be had with traditional inheritance with less and clearer code (also IDEs get less confused)AllocationSite
child classesSimpleThreadStackSite
,VirtualMemoryAllocationSite
,MallocSite
were simplified.As for
SimpleThreadStackSite
, we can get rid of the separate data holder classSimpleThreadStack
entirely by merging its members directly intoSimpleThreadStackSite
. In theory we could do the same for the data holder classesMemoryCounter
andVirtualMemory
forMallocSite
andVirtualMemoryAllocationSite
too but this would cause larger ripples so I stopped there.removed the SimpleThreadStackSite(address base, size_t size) constructor (the one not taking a call stack) by slightly rewriting its sole user
made
AllocationSite
immutableremoved unused default constructors from
MallocSite
andMallocSiteHashTableEntry
since they were not neededremoved unused methods
set_callsite()
,hash()
,equals()
fromMallocSiteHashTableEntry
There was a subtle incorrectness where
AllocationSite::equals()
would only compare callstack and disregard the MEMFLAGS member. Theoretically, if two callstacks end with the same lowest frame, they should always reference the same single allocation, so that's okay. But if the call stack capturing was not precise enough (eg skipping too many low frames) we may accidentally lump several allocation sites together which could have different MEMFLAGS. I added an assert to check that. (Update: seems this assert really fires on s390x, so this is a real problem. I opened [1] to track this and restored the old behavior.).NativeCallStack
: Removed thefillStack
argument from the first constructor to avoid having to evaluate it in this hot constructor. Its true in almost all cases.Also removed the
toSkip
default value. Instead, I added an explicit default constructor.Moved the malloc site table tuning statistics printing from memtracker.cpp down into a new function
MallocSiteTable::print_tuning_statistics()
. When implemented insideMallocSiteTable
, that coding does not need a walker object anymore and becomes a lot simpler. In particular, we don't have to rely on implicit knowledge about walking order, which made the code complex and was vulnerable against subtle errors. New code is more compact and simpler. Before removing the old implementation, I ran both statistics side by side for a couple of scenarios (eg really bad hash code implementations) and the output was identical.[1] https://bugs.openjdk.java.net/browse/JDK-8261556
Tests:
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2539/head:pull/2539
$ git checkout pull/2539