Що таке ReservedCodeCacheSize та InitialCodeCacheSize?

86

Може хто - то будь ласка , поясніть , який варіант JVM ReservedCodeCacheSizeі InitialCodeCacheSizeє? Зокрема, коли / чому я хотів би це змінити? Як я можу визначити, який розмір потрібний?

Ось що сказано в документах:

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

java  jvm  jvm-hotspot 
— Рагу
джерело
2
У цій публікації написано:> -XX: ReservedCodeCacheSize = 32 м. Зарезервований розмір кешу коду (у байтах) - максимальний розмір кешу коду. [Solaris 64-розрядна версія, amd64 та -server x86: 48м; в 1.5.0_06 і раніше, Solaris 64-bit та and64: 1024m.] Я просто хочу виправити, що згадана верхня межа на 48m повинна бути друкарською помилкою. Це 2048м.
— Лассе Аагрен

Відповіді:

73

ReservedCodeCacheSize(і InitialCodeCacheSize) - це опція для (точно вчасно) компілятора Java Hotspot VM. В основному він встановлює максимальний розмір кешу коду компілятора.

Кеш може заповнитись, що призводить до таких попереджень:

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)

Зазвичай ви не змінювали це значення. Я думаю, що значення за замовчуванням досить добре збалансовані, оскільки ці проблеми трапляються лише в дуже рідкісних випадках (на мій досвід).

— Джеха
джерело
1
Приємно. Які є значення за замовчуванням і до чого їх слід збільшувати, якщо ми бачимо "CodeCache заповнений". увага?
— axel22
3
@ axel22: Значення фактично залежать від платформи та версії JVM; значення з документа для Sun JVM: Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and amd64: 1024m.]Не знаю значення OpenJDK. Помірного приросту повинно бути достатньо (попереднє встановлення 1024 м було більше, ніж добро - зло).
— jeha
12

@jeha відповідає на все, що я хотів знати з цього питання, крім того, для якого значення встановлювати параметри. Оскільки я не писав код, який я розгортав, я не мав особливої ​​видимості в розмірі пам'яті, який він мав.

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

  1. Запустіть jconsole на своїй машині
  2. Знайдіть правильний ідентифікатор процесу та приєднайте до нього jconsole (це займе кілька хвилин)
  3. Перейдіть на вкладку "Пам'ять"
  4. У спадному списку "Діаграма:" виберіть "Пул пам'яті" Кеш-код ""

  5. Знову ж таки, це може зайняти кілька хвилин для оновлення екрана, і тоді ви повинні побачити щось на зразок: Зображення кешу коду jconsole

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

    Бен.

    1024 МБ за замовчуванням, ймовірно, перестаралися, але 48 МБ за замовчуванням, здається, недостають ...

— Тварина451
джерело
Хороша пропозиція .... Я намагаюся з -J-XX: ReservedCodeCacheSize = 512м
— MarcoZen
Netbeans не починали з 512 м, а з
— 256 м
І після тестування протягом приблизно 2 днів я можу сказати, що налаштування не виявило жодного / будь-якого помітного поліпшення, а натомість зробило мережу п’янистим. У підсумку я просто видалив його.
— MarcoZen
3

Хороший досвід навчання від команди інженерів Indeed та проблеми, з якими вони стикалися при переході на 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

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

Нижче наведено дві відомі проблеми в jdk7u4 + щодо змивання CodeCache:

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

Ця проблема продуктивності та проблема того, що компілятор не вмикається знову, була розглянута в JDK8. Щоб обійти їх у JDK7u4 +, ми можемо збільшити розмір кешу коду за допомогою параметра ReservedCodeCacheSize, встановивши для нього значення, яке перевищує розмір компільованого коду, щоб CodeCache ніколи не заповнювався. Іншим рішенням цього є вимкнення змивання CodeCache за допомогою параметра -XX: -UseCodeCacheFlushing JVM.

Вищезазначені проблеми були виправлені в JDK8 та його оновленнях.

Тому цю інформацію варто згадати для систем, що працюють на JDK 6 (з вимкненою змивкою коду) та 7.

— Андре Стейнресс
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.