>> We also don't measure the early prolog with:
>> 380 Universe::heap()->safepoint_synchronize_begin();
>> 381
>> 382 // By getting the Threads_lock, we assure that no threads are about to start or
>> 383 // exit. It is released again in SafepointSynchronize::end().
>> 384 Threads_lock->lock();
>>
>> I had a measurement there but it was never any time spent there, something to keep in mind at least.
>
> Oh. Can we (should we) move the call to RuntimeService::record_safepoint_begin() before these? I'd
> imagine CollectedHeap::safepoint_synchronize_begin() might take a while in some implementations, and
> Threads_lock acquisition can be contended as well. It's fine to make it in a separate issue to avoid
> tainting this one with artificial "regression".
Also consider moving RuntimeService::record_safepoint_end(); after:
// Release threads lock, so threads can be created/destroyed again.
Threads_lock->unlock();
// Wake threads after local state is correctly set.
_wait_barrier->disarm();
>> 380 Universe::heap()->safepoint_synchronize_begin();
>> 381
>> 382 // By getting the Threads_lock, we assure that no threads are about to start or
>> 383 // exit. It is released again in SafepointSynchronize::end().
>> 384 Threads_lock->lock();
>>
>> I had a measurement there but it was never any time spent there, something to keep in mind at least.
>
> Oh. Can we (should we) move the call to RuntimeService::record_safepoint_begin() before these? I'd
> imagine CollectedHeap::safepoint_synchronize_begin() might take a while in some implementations, and
> Threads_lock acquisition can be contended as well. It's fine to make it in a separate issue to avoid
> tainting this one with artificial "regression".
Also consider moving RuntimeService::record_safepoint_end(); after:
// Release threads lock, so threads can be created/destroyed again.
Threads_lock->unlock();
// Wake threads after local state is correctly set.
_wait_barrier->disarm();
- duplicates
-
JDK-8219436 Safepoint logs correction and misc
- Resolved