The new block needs to be just above the "ThreadsListHandle tlh;"
line in order to preserve all of the existing checks...
More below...
On 7/16/18 2:22 PM, Hohensee, Paul wrote:
I believe you could move the code ahead of the call to
validate_thread_id_array() because that method just checks
I believe you could move the code ahead of the call to
validate_thread_id_array() because that method just checks for thread ids <= 0.
diff -r 3ddf41505d54 src/hotspot/share/services/management.cpp
--- a/src/hotspot/share/services/management.cpp Sun Jun 03 23:33:00 2018 -0700
+++
Hi,
Thank you for all the help.
I added the code suggested by Paul and ran my small microbenchmark. The
optimized getThreadAllocatedBytes now takes 57 ns if fed with the ID of the
current thread. All calls that aren't for the current thread will be a bit
slower. As far as I am concerned,
I saw Daniels comment too late, but using THREAD instead
of JavaThread::current() indeed makes the new method again a bit simpler
and faster (now 33 ns instead of 35 ns).
JVM_ENTRY(jlong, jmm_GetCurrentThreadAllocatedMemory(JNIEnv *env))
return THREAD->cooked_allocated_bytes();
JVM_END
On Mon,
Hi Jc,
It looks good to me.
Thanks,
Serguei
On 7/16/18 10:58, JC Beyler wrote:
Hi all,
Small RFR to update a HeapMonitor test that had two issues:
a test was wrong and the test was not
Hi all,
Small RFR to update a HeapMonitor test that had two issues: a test was
wrong and the test was not allocating enough to get to an expected sample
count. Instead of allocating 10 times more and hit some OOM on the test
framework, the webrev allocates in chunks and gets the number of
Hi Jc,
It looks good to me.
Thanks,
Serguei
On 7/16/18 12:37, JC Beyler wrote:
Hi all,
Small RFR to update two HeapMonitor tests to remove test
failures when resetting a test data
Given your requirements, and that my proposal is slower, yours is better. :)
There’s no technical reason why we can’t add what you’re asking for (and
everyone who’s weighed in so far is in favor), but what do people think of
adding the rest of the missing getCurrentThread* methods? These would
Hi all,
We need at least one more review before pushing it.
Thanks,
Serguei
On 7/16/18 16:07, JC Beyler wrote:
Hi all,
The CSR has recently been approved, could someone else
review
Hi Gary,
I'm still not totally sold on adding the higher timeout, but I'm
ok with it. I guess my main reservation is that is seems
unnecessary (we don't currently have timeout issues with these
tests).
thanks,
Chris
I agree that timeouts should be very rare and that a shorter timeout
helps during test development. These tests were written a long time
ago and the test developers are no longer available for ongoing
adjustments.
These tests were not designed to be performance regression tests.
They typically
11 matches
Mail list logo
