Skip to content
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

Closed
wants to merge 101 commits into from

Conversation

phohensee
Copy link
Member

@phohensee phohensee commented May 4, 2023

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

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires CSR request JDK-8307396 to be approved

Issues

  • JDK-8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM
  • JDK-8307396: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM (CSR)

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

@bridgekeeper
Copy link

bridgekeeper bot commented May 4, 2023

👋 Welcome back phh! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added csr Pull request needs approved CSR before integration rfr Pull request is ready for review labels May 4, 2023
@openjdk
Copy link

openjdk bot commented May 4, 2023

@phohensee The following labels will be automatically applied to this pull request:

  • hotspot-runtime
  • jmx
  • serviceability

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.

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org hotspot-runtime hotspot-runtime-dev@openjdk.org jmx jmx-dev@openjdk.org labels May 4, 2023
@phohensee phohensee changed the title 8304074: [JMX] Add an approximation of JVM process allocated bytes 8304074: [JMX] Add an approximation of JVM bytes allocated on the Java heap May 5, 2023
@phohensee phohensee changed the title 8304074: [JMX] Add an approximation of JVM bytes allocated on the Java heap 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM May 5, 2023
Copy link
Member

@shipilev shipilev left a 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/hotspot/share/services/threadService.hpp Outdated Show resolved Hide resolved
src/hotspot/share/services/management.cpp Outdated Show resolved Hide resolved
src/hotspot/share/include/jmm.h Outdated Show resolved Hide resolved
src/hotspot/share/services/management.cpp Outdated Show resolved Hide resolved
Copy link
Member

@simonis simonis left a 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.

src/hotspot/share/include/jmm.h Outdated Show resolved Hide resolved
src/hotspot/share/include/jmm.h Outdated Show resolved Hide resolved
src/hotspot/share/services/management.cpp Outdated Show resolved Hide resolved
src/hotspot/share/services/management.cpp Outdated Show resolved Hide resolved
@phohensee
Copy link
Member Author

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.

@dholmes-ora
Copy link
Member

@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.

@phohensee
Copy link
Member Author

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?

@dholmes-ora
Copy link
Member

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.

@dholmes-ora
Copy link
Member

A global counter would also need to resurrect Atomic::add(jlong) for all platforms.

@dholmes-ora
Copy link
Member

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.)

@phohensee
Copy link
Member Author

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.

@mlchung
Copy link
Member

mlchung commented May 26, 2023

Thanks for updating the test. The spec looks good. I'll leave the hotspot implementation for David and others to approve.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 26, 2023
@phohensee
Copy link
Member Author

Thanks for your review, Mandy.

Copy link
Member

@dholmes-ora dholmes-ora left a 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) {
Copy link
Member

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'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to "when".

@phohensee
Copy link
Member Author

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.

Copy link
Member

@dholmes-ora dholmes-ora left a 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.

@phohensee
Copy link
Member Author

Thanks for your in-depth review!

@phohensee
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented May 30, 2023

Going to push as commit 3eced01.
Since your change was applied there have been 24 commits pushed to the master branch:

  • 15e0285: 8309110: Build failure after JDK-8307795 due to warnings in micro-benchmark StoreMaskTrueCount.java
  • 4526282: 8308977: gtest:codestrings fails on riscv
  • f600d03: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
  • 07f2070: 8309095: Remove UTF-8 character from TaskbarPositionTest.java
  • 2b186e2: 8309042: MemorySegment::reinterpret cleanup action is not called for all overloads
  • 78aac24: 8308881: Strong CLD oop handle roots are demoted to non-roots concurrently
  • 1f1f604: 8302670: use-after-free related to PhaseIterGVN interaction with Unique_Node_List and Node_Stack
  • d35a550: 8309077: Problemlist compiler/jvmci/TestUncaughtErrorInCompileMethod.java
  • 457e1cb: 8308817: RISC-V: Support VectorTest node for Vector API
  • 7508d9f: 8308906: Make CIPrintCompilerName a diagnostic flag
  • ... and 14 more: https://git.openjdk.org/jdk/compare/77c5adb09e89e013c4bc4982f541110bf76e83a7...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label May 30, 2023
@openjdk openjdk bot closed this May 30, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 30, 2023
@openjdk
Copy link

openjdk bot commented May 30, 2023

@phohensee Pushed as commit 3eced01.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@phohensee phohensee deleted the 8304074 branch May 30, 2023 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated jmx jmx-dev@openjdk.org serviceability serviceability-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.