rkennke at redhat.com
Tue Nov 21 20:40:01 UTC 2017
Am 21.11.2017 um 21:15 schrieb Tony Printezis:
> Hi all,
> I’ve been looking at the safepoint behavior of one of our services and I
> noticed that around 55% of the safepoints that happen don’t execute a VM
> operation. I’d need to confirm this, but I assume they only happen in
> order to do some cleanup (SafepointSynchronize::is_cleanup_needed()
> returns true, which in JDK 8 translates to !InlineCacheBuffer::is_empty()).
This is true. This cleanup is done regularily to clean up zombie
nmethods and deflate idle monitors (and some other relatively minor
> I’m not familiar with the InlineCacheBuffer at all. How important is it
> to execute InlineCacheBuffer::update_inline_caches() at regular
> intervals? Would a modified heuristic, like "a safepoint is required if
> the buffer is >P% full" (maybe in conjunction with increasing the buffer
> size) be reasonable? Or maybe increase the value of
> GuaranteedSafepointInterval? Or both?
I think such a modified heuristic would be reasonable.
> Note that the overhead of the non-VM op safepoints is actually
> negligible. I’d just like to try to cut down the number of safepoints we
> do, as we had issues in the past with safepoint initiation taking too long.
I can feel your pain.
There are some ongoing (or infact not-yet-started) efforts to cut this
down. One is concurrent monitor deflation:
Another one is using multiple threads for nmethod sweeping (I proposed a
mechanism to do that some months ago, but has been stalled because
upstream didn't want it back then), here's some related issue around that:
I'd be happy to re-open the discussions around parallel safepoint cleanup.
More information about the hotspot-compiler-dev