InlineCacheBuffer question

Roman Kennke rkennke at
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 mailing list