I use Java primarily for writing pet projects, which are idle most of the time. And after being idle for hours/days response time increases to seconds (up to 10s), then slowly decreases back to 200-300ms.
As far as I understand, this happens because of JIT deoptimization (optimized code becomes marked as a zombie, removed and later compiled again).
Is there any way to forbid JVM to deoptimize code unless code cache is full? Java 9's AOT looks like the best solution for this case, but I still haven't managed to make it work.
UPD: And as always, the right solution is the obvious one. Looks like the problem was actually caused by swap. Despite 12 GB of ram, 6 of which were free, about 100 MB of every JVM's memory was swapped to HDD after a while.
Nevertheless @apangin's answer can be useful for someone else who run into the same situation, so I leave this question here. Thanks all!
-XX:-UseCodeCacheFlushingdisables sweeping compiled methods altogether.Though this is the answer to the given question, I highly doubt this will resolve your original problem.
When an application is idle, NMethod sweeper is also idle. It is also unlikely that JIT compilation is so slow that it takes tens of seconds before the hot code is (re-)compiled. Flushed file caches, stale network connections etc. are more likely reasons for such slowdowns.