Деоптимизация JVM JIT после простоя

Я использую Java в основном для написания домашних проектов, которые большую часть времени простаивают. А после простоя в течение нескольких часов/дней время отклика увеличивается до секунд (до 10 с), затем медленно снижается обратно до 200-300 мс.

Насколько я понимаю, это происходит из-за JIT деоптимизации (оптимизированный код помечается как зомби, удаляется, а затем снова компилируется).

Есть ли способ запретить JVM деоптимизировать код, если кеш кода не заполнен? AOT Java 9 выглядит лучшим решением для этого случая, но мне до сих пор не удалось заставить его работать.

UPD: И как всегда правильное решение очевидно. Похоже, проблема действительно была вызвана свопом. Несмотря на 12 ГБ оперативной памяти, 6 из которых были свободны, через некоторое время около 100 МБ памяти каждой JVM было заменено на жесткий диск.

Тем не менее ответ @apangin может быть полезен для кого-то, кто столкнулся с такой же ситуацией, поэтому я оставляю этот вопрос здесь. Спасибо всем!


java performance jvm jit jvm-codecache
person Dmitry Romanov    schedule 18.04.2017    source источник
comment
Откуда вы знаете, что виновата деоптимизация?   -  person Jim Garrison    schedule 18.04.2017
comment
Я не знаю, я только предполагаю. Это происходит в нескольких разных проектах, некоторые из которых очень просты и не используют никаких баз данных или кешей (телеграмм-бот), как в Oracle, так и в OpenJdk (x64).   -  person Dmitry Romanov    schedule 18.04.2017
comment
Пробовали профилировать? Например, вы внимательно изучили потребление памяти этими домашними животными?   -  person GhostCat    schedule 18.04.2017
comment
Моей первой мыслью было бы то, что ОС выгрузила соответствующие части памяти виртуальной машины, которые должны быть снова считаны с диска.   -  person piet.t    schedule 18.04.2017
comment
Это может быть что-то совершенно другое, например, ваше приложение будет заменено другими процессами. Попробуйте войти в систему с помощью -XX:+PrintCompilation, чтобы проверить свое предположение.   -  person the8472    schedule 18.04.2017

Ответы (1)


arrow_upward
0
arrow_downward

-XX:-UseCodeCacheFlushing полностью отключает скомпилированные методы очистки.

Хотя это является ответом на данный вопрос, я очень сомневаюсь, что это решит вашу первоначальную проблему.

Когда приложение бездействует, чистильщик NMethod также бездействует. Также маловероятно, что JIT-компиляция настолько медленная, что занимает десятки секунд до (повторной) компиляции горячего кода. Сброшенные кэши файлов, устаревшие сетевые соединения и т. д. являются более вероятными причинами таких замедлений.

person apangin    schedule 18.04.2017
comment
Спасибо за ответ. Похоже, вы правы, мое предположение было довольно незрелым. Я постараюсь проверить другие гипотезы и, возможно, вернусь с дополнительными данными. - person Dmitry Romanov; 18.04.2017