InlineCacheBuffer question

[Roman Kennke]

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 
cleanups).

> 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:

https://bugs.openjdk.java.net/browse/JDK-8183909

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:

https://bugs.openjdk.java.net/browse/JDK-8132849
https://bugs.openjdk.java.net/browse/JDK-8184751
https://bugs.openjdk.java.net/browse/JDK-8153224

I'd be happy to re-open the discussions around parallel safepoint cleanup.

Roman