RFR(L) 8153224 Monitor deflation prolong safepoints
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri Apr 5 15:44:31 UTC 2019
On 4/3/19 3:04 AM, Robbin Ehn wrote:
> Hi Dan, Carsten,
>
>>>> However, moving deflate_idle_monitors() from the safepoint cleanup
>>>> phase
>>>> to before the actual garbage collection can wait until we do the
>>>> work to
>>>> decouple triggering of monitor deflation to be independent of the the
>>>> safepoint cleanup phase.
>>>>
>
> If I got the context correct here:
> All cleanups are done before the VM op is execute.
> It is the last thing we do in SS::begin(), so anything added to
> SS::do_cleanup_tasks/ParallelSPCleanupTask is done first in any
> safepoint.
Agreed.
src/hotspot/share/runtime/safepoint.cpp:
void SafepointSynchronize::begin() {
<snip>
// We do the safepoint cleanup first since a GC related safepoint
// needs cleanup to be completed before running the GC op.
EventSafepointCleanup cleanup_event;
do_cleanup_tasks();
post_safepoint_cleanup_event(cleanup_event, _safepoint_counter);
post_safepoint_begin_event(begin_event, _safepoint_counter,
nof_threads, _current_jni_active_count);
SafepointTracing::cleanup();
}
And do_cleanup_tasks() is where we do the deflate idle monitors work.
Dan
>
> /Robbin
>
>>>
>>> SGTM.
>>>
>>>> Speaking of optimizations, it sure would be nice if little changes to
>>>>> java threads could be combined and performed on the way out of the
>>>>> safepoint in one go instead of having lots of iterations of the
>>>>> thread list
>>>>> in various places. Some people have thousands of threads and each
>>>>> traversal
>>>>> of the thread list hurts.
>>>>>
>>>>>
>>>>> Do you have a specific example in mind?
>>>>>
>>>>
>>>> No concrete example for a public mailing list. :(. But do notice that
>>>> independent tasks that require traversals of the thread list are
>>>> already
>>>> fused in ParallelSPCleanupThreadClosure
>>>> <http://hg.openjdk.java.net/jdk-updates/jdk12u/file/fe6c633292ff/src/hotspot/share/runtime/safepoint.cpp#l586>.
>>>>
>>>> If you made deflate_thread_local_monitors
>>>> set jt->omShouldDeflateIdleMonitors to true, then you wouldn't need to
>>>> iterator over all java threads in do_safepoint_work.
>>>>
>>>>
>>>> I think I see what you mean... so when
>>>> ParallelSPCleanupThreadClosure::
>>>> do_thread() calls deflate_thread_local_monitors():
>>>>
>>>> 2250 if (AsyncDeflateIdleMonitors) {
>>>> 2251 // Nothing to do when idle ObjectMonitors are deflated
>>>> using a
>>>> 2252 // JavaThread unless a special cleanup has been requested.
>>>>
>>>> Replace L2251-2 with:
>>>> // Mark the JavaThread for idle monitor cleanup unless a
>>>> // special cleanup has been requested.
>>>> 2253 if (!is_cleanup_requested()) {
>>>>
>>>> Add these three lines:
>>>> if (thread->omInUseCount > 0) {
>>>> // This JavaThread is using monitors so mark it.
>>>> thread->omShouldDeflateIdleMonitors = true;
>>>> }
>>>> 2254 return;
>>>> 2255 }
>>>>
>>>> That will allow this block to go away:
>>>>
>>>> 1695 // Request deflation of per-thread idle monitors by each
>>>> JavaThread:
>>>> 1696 for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt =
>>>> jtiwh.next(); ) {
>>>> 1697 if (jt->omInUseCount > 0) {
>>>> 1698 // This JavaThread is using monitors so check it.
>>>> 1699 jt->omShouldDeflateIdleMonitors = true;
>>>> 1700 }
>>>> 1701 }
>>>>
>>>> Please let me know if I understand what you meant...
>>>>
>>>
>>> This is exactly what I meant.
>>>
>>>
>>> Good. This will be in the next round of code review.
>>>
>>
>> Nice.
>>
>> Carsten
>>
More information about the hotspot-runtime-dev
mailing list