3

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!

Dmitry Romanov
  • 33
  • 5
  • 1
    How do you ***know*** deoptimization is the culprit? – Jim Garrison Apr 18 '17 at 06:25
  • I don't know, I only assume. This happens on multiple different projects, some of which are very simple and don't use any databases or caches (telegram bot), both on Oracle and OpenJdk (x64). – Dmitry Romanov Apr 18 '17 at 06:31
  • Tried profiling? Did you have a closer look at the memory consumption of those pets for example? – GhostCat Apr 18 '17 at 06:36
  • My first thought would be that the OS has paged out relevant portions of the VM's memory that have to be read back in again from disk. – piet.t Apr 18 '17 at 06:40
  • It might be something totally different, such as your application getting swapped out in favor of other processes. Try logging with `-XX:+PrintCompilation` to test your assumption. – the8472 Apr 18 '17 at 08:03

1 Answers1

0

-XX:-UseCodeCacheFlushing disables 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.

apangin
  • 92,924
  • 10
  • 193
  • 247
  • Thank you for the answer. Looks like you're right, my assumption was pretty immature. I'll try to check other hypotheses and, probably, come back with more data. – Dmitry Romanov Apr 18 '17 at 09:35