Кэш кода JVM превышает ReservedCodeCacheSize

У меня есть java-приложение, работающее в докере с флагами на OpenJDK8:

-XX:+UseContainerSupport -XX:MaxRAMPercentage=80.0 -XX:NativeMemoryTracking=summary

и я заметил, что выделение памяти в кэше кода, о котором сообщает инструмент отслеживания собственной памяти, превышает 240MB (значение по умолчанию ReservedCodeCacheSize):

jcmd 1 VM.native_memory summary | grep -i code
-                      Code (reserved=260013KB, committed=60465KB)

который является ~ 254MB зарезервированной памятью. Вот печатный флаг и версия Java:

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep -i reserved
    uintx ReservedCodeCacheSize                     = 251658240                           {pd product}
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (build 1.8.0_262-b10)
OpenJDK 64-Bit Server VM (build 25.262-b10, mixed mode)

Мой вопрос в том, является ли это ожидаемым поведением? Если да, то можно ли рассчитать фактический предел максимального размера кеша кода?

Благодарность!


person t3h_b0t    schedule 23.04.2021    source источник


Ответы (1)


Code в отчете Native Memory Tracking учитывается не только кэш кода, но и несколько других вещей. Отчет включает в себя:

  1. Fixed size spaces reserved with mmap:
    • Code Cache - 240 MB;
    • карта сегментов Code Cache - 1/64 размера Code Cache = 3,75 МБ.
  2. Auxiliary VM structures malloc'ed in the native heap:
    • строки кода, OopMaps, исключение кэши обработчиков, таблицы обработчиков адаптеров и другие структуры для поддержки сгенерированного кода.

      Эти структуры выделяются динамически; для них нет специального лимита, но обычно они составляют лишь небольшую часть всего генерируемого кода (см. строку malloc= в разделе Code отчета NMT).

Обратите внимание, что память reserved на самом деле не потребляет никаких ресурсов, кроме адресного пространства. Для анализа реального использования памяти больше подходит committed.

person apangin    schedule 23.04.2021