RFR(XL): 8203469: Faster safepoints

Robbin Ehn robbin.ehn at oracle.com
Wed Jan 16 11:43:52 UTC 2019


On 2019-01-16 11:31, Aleksey Shipilev wrote:
> I say we call it what it is:
> 
> [93.734s][info][safepoint,stats] Safepoint "Deoptimize", Time since last: 8270801 ns; Reaching
> safepoint: 4899 ns; At safepoint: 457865 ns; Total: 462764 ns
> 
> Also note the temporal ordering: first the timestamp for application stopped time, then time
> intervals for stopping/stopped, then totals.

I'll update to this, thanks.

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

Yes, https://bugs.openjdk.java.net/browse/JDK-8217244

/Robbin

> 
> Cheers,
> -Aleksey
> 
> 


More information about the hotspot-dev mailing list