RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread

[Mandy Chung]

On 9/3/19 12:38 PM, Hohensee, Paul wrote:
> Minor update in new webrev http://cr.openjdk.java.net/~phh/8207266/webrev.05/.

I only reviewed the library side implementation that looks good.  I 
expect the serviceability team to review the test and hotspot change.

> Need a confirmatory review to push this. If I understand the rules correctly, it doesn't need a Reviewer review since Mandy's already reviewed it, it just needs a Committer review.

You need another reviewer to advice the following because I was not 
close to the ThreadsList work.

2087   ThreadsListHandle tlh;
2088   JavaThread* java_thread = tlh.list()->find_JavaThread_from_java_tid(thread_id);
2089
2090   if (java_thread != NULL) {
2091     return java_thread->cooked_allocated_bytes();
2092   }

This looks right to me.

test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java

- "ThreadAllocatedMemory is expected to be disabled");
+ "TEST FAILED: ThreadAllocatedMemory is expected to be disabled");

Prepending "TEST FAILED" in exception message (in several places)
seems redundant since such RuntimeException is thrown and expected
a test failure.

+ // back-to-back calls shouldn't allocate any memory
+ size = mbean.getThreadAllocatedBytes(id);
+ size1 = mbean.getThreadAllocatedBytes(id);
+ if (size1 != size) { Is there anything in the test can do to help 
guarantee this? I didn't closely review this test. The main thing I 
advice is to improve the reliability of this test. Put it in another 
way, we want to ensure that this test change will pass all the time in 
various test configuration. Mandy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190912/e8ac3a8b/attachment-0001.html>