Что такое ReservedCodeCacheSize и InitialCodeCacheSize? - PullRequest
Новая
       1

Что такое ReservedCodeCacheSize и InitialCodeCacheSize?

78 голосов
/ 22 сентября 2011

Может кто-нибудь объяснить, что такое опция JVM ReservedCodeCacheSize и InitialCodeCacheSize?В частности, когда / почему я хотел бы изменить это?Как мне определить, какой правильный размер?

Вот что говорят документы:

-XX: ReservedCodeCacheSize = 32m Размер зарезервированного кеша кода (в байтах) - максимальный кеш кодаразмер.[Solaris 64-bit, amd64 и -server x86: 2048m;в 1.5.0_06 и более ранних версиях Solaris 64-bit и and64: 1024m.]

Ответы [ 4 ]

69 голосов
/ 22 сентября 2011

ReservedCodeCacheSize (и InitialCodeCacheSize) - это опция для (точно вовремя) компилятора виртуальной машины Java Hotspot. По сути, он устанавливает максимальный размер кеша кода компилятора.

Кэш может заполниться, что приводит к следующим предупреждениям: 

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

Гораздо хуже, когда за ним следует Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

Когда установить эту опцию?

  1. при сбоях компилятора Hotspot
  2. для уменьшения памяти, необходимой JVM (и, следовательно, для риска сбоев JIT-компилятора)

Обычно вы бы не меняли это значение. Я думаю, что значения по умолчанию достаточно хорошо сбалансированы, потому что эти проблемы возникают только в очень редких случаях (в моем опыте).

12 голосов
/ 03 июня 2014

@ jeha отвечает на все, что я хотел узнать из этого вопроса, кроме значения, для которого нужно установить параметры. Поскольку я не писал код, который развертывал, у меня не было особой видимости занимаемой памяти.

Однако вы можете использовать jconsole, чтобы присоединиться к запущенному процессу Java, а затем использовать вкладку «Память», чтобы узнать размер кеша кода. Для полноты выполните следующие шаги (среда Linux VM, хотя я уверен, что другие среды похожи):

  1. Запустите jconsole на вашем компьютере
  2. Найдите правильный идентификатор процесса и подключите к нему jconsole (это займет несколько минут)
  3. Перейдите на вкладку «Память»
  4. В раскрывающемся списке «Диаграмма:» выберите «Пул памяти« Кэш кода »»

  5. Опять же, для обновления экрана может потребоваться несколько секунд, а затем вы должны увидеть что-то вроде: jconsole code cache image

    Как видите, мой кэш кода использует около 49 МБ. На данный момент у меня все еще был стандарт, который указан в документации (и @jeha) 48 МБ. Конечно, отличная мотивация для меня, чтобы увеличить настройку!

    Бен.

    1024 МБ по умолчанию, вероятно, переусердствовали, но 48 МБ по умолчанию, кажется, переусердствовали ...

2 голосов
/ 15 сентября 2016

Хороший опыт обучения у команды разработчиков действительно и проблемы, с которыми они столкнулись при переходе на jdk 8.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

Вывод: Jdk 8 требуется больше кеша кода JDK 7

Размер кодового кэша по умолчанию для JRE 8 составляет около 250 МБ, примерно в пять раз больше, чем 48 МБ по умолчанию для JRE 7. Наш опыт показывает, что JRE 8 нуждается в таком дополнительном кодовом кэше.На данный момент мы переключили около десяти сервисов на JRE 8, и все они используют примерно в четыре раза больше кодового кэша, чем раньше.

0 голосов
/ 04 октября 2016

из https://blogs.oracle.com/poonam/entry/why_do_i_get_message:

Ниже приведены две известные проблемы в jdk7u4 +, связанные с сбросом CodeCache:

  1. Компилятор может не перезапуститься даже после CodeCacheпосле аварийной очистки занятость уменьшается почти вдвое.
  2. Аварийная очистка может привести к высокой загрузке ЦП потоками компилятора, что приведет к общему снижению производительности.

Эта проблема с производительностью и проблема повторного включения компилятора была решена в JDK8.Чтобы обойти это в JDK7u4 +, мы можем увеличить размер кэша кода, используя параметр ReservedCodeCacheSize, установив для него значение, превышающее размер компилируемого кода, чтобы CodeCache никогда не переполнялся.Другим решением этой проблемы является отключение очистки CodeCache с помощью параметра JVM -XX: -UseCodeCacheFlushing.

Вышеупомянутые проблемы были исправлены в JDK8 и его обновлениях.

Так что эту информацию стоит упомянуть для систем, работающих на JDK 6 (с отключенной очисткой кода) и 7.

...