-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM #13814
Conversation
👋 Welcome back phh! A progress list of the required criteria for merging this PR into |
@phohensee The following labels 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 lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
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.
Some comments follow.
src/java.management/share/classes/sun/management/ThreadImpl.java
Outdated
Show resolved
Hide resolved
src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java
Outdated
Show resolved
Hide resolved
test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java
Outdated
Show resolved
Hide resolved
test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java
Outdated
Show resolved
Hide resolved
test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java
Outdated
Show resolved
Hide resolved
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 in general. Please find my comments inline.
…ava heap by the JVM
…ava heap by the JVM
…ava heap by the JVM
…ava heap by the JVM
src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java
Outdated
Show resolved
Hide resolved
src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java
Outdated
Show resolved
Hide resolved
Yes, it seems to have happened when I did a merge of this branch with jdk master, which latter must have been in a strange state. Unfortunately, git merge didn't complain at all, so I didn't check before pushing. |
@phohensee not clear if you saw my comment a couple of days ago about why the monotonic increasing check in the test can't work. |
Yes, I saw your comment and have been thinking about how to fix it, but haven't come up with anything. Ramki (ysr) pointed out that walking the thread list using SMR is very expensive when there are 1000s of threads, and that there isn't much overhead to collecting per-thread statistics: a thread local counter is incremented when TLABs are retired or there are direct allocations of large objects in eden or the old gen. So, he suggested adding an atomic increment of a global counter whenever a thread local counter is incremented. Atomic operations have been completing in the LLC (i.e., on-chip) for some time now, so the overhead is pretty small. What do you think, shall I reimplement that way? |
A global allocation counter sounds like a potential bottleneck to me and everyone has to pay for it. I'd want to see broad performance measurements for that and hear what the GC folk have to say. |
A global counter would also need to resurrect Atomic::add(jlong) for all platforms. |
The monotonicity issue can be addressed by tracking the last total and never reporting a smaller value. (Much as we used to cache the current time to avoid it going backwards.) |
I added a high water mark to getTotalThreadAllocatedBytes (under a lock, lest we have a monotonicity issue on the high water mark), and updated the tests per Mandy's request. |
Thanks for updating the test. The spec looks good. I'll leave the hotspot implementation for David and others to approve. |
Thanks for your review, Mandy. |
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.
High watermark changes seem fine in principle but not sure about borrowing the MonitoringSupport_lock
to do the locking. At a minimum this comment should be expanded:
./share/runtime/mutexLocker.hpp:extern Mutex* MonitoringSupport_lock; // Protects updates to the serviceability memory pools.
@@ -300,11 +302,16 @@ private static long checkResult(Thread curThread, | |||
return currSize; | |||
} | |||
|
|||
private static void reportUnexpected(Exception e, String reason) { |
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: 'when' or 'where' seems a more appropriate name than 'reason'
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.
Changed to "when".
…to MonitoringSupport_lock declaration
Changed the MonitoringSupport_lock comment to "Protects updates to the serviceability memory pools and allocated memory high water mark". The lock was introduced to serialize updates to the G1 memory pool stats, but given that doesn't happen very often, and the name, imo it's reasonable to use it in a more general fashion. |
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.
Nothing further from me. Thanks.
Thanks for your in-depth review! |
/integrate |
Going to push as commit 3eced01.
Your commit was automatically rebased without conflicts. |
@phohensee Pushed as commit 3eced01. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814
$ git checkout pull/13814
Update a local copy of the PR:
$ git checkout pull/13814
$ git pull https://git.openjdk.org/jdk.git pull/13814/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13814
View PR using the GUI difftool:
$ git pr show -t 13814
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13814.diff
Webrev
Link to Webrev Comment