Выделен ли размер стека Java физическим или логическим?

Question

Мне было интересно, является ли размер выделенного стека, который мы считаем Java (например, 512 КБ), логическим размером (это означает, что в действительности мы используем более 512 КБ, включая, например, все служебные данные Hotspot), или такое физический предел (это означает, что суммирование всех выделенных Java-объектов в стеке не будет равносильно чему-то вроде 512 КБ)?

Трудно понять это путем тестирования, я бы сказал, как было показано в моем другом посте: Определение использования стековой памяти метода в Java

Я бы хотел какие-то источники, если это возможно!

Спасибо

Answer 1

Размер стека использует виртуальную память до фактического использования.Это означает, что размер вашего стека может составлять 1 МБ для каждого потока, однако размер резидента может быть только 32 КБ.

Это связано с тем, что ОС выделяет страницы (обычно 4 КБ) вашей программе по мере их использования.

например, он выделяет ваш максимальный размер кучи при запуске, но ваша программа не использует столько основной памяти, пока не будет использована каждая страница.

У вас могут возникнуть трудности с поиском этой информации для JVMособенно потому, что это функциональность, предоставляемая ОС, и все программы работают таким образом.то есть это не что-то особенное, что делает JVM.

Answer 2

Я думаю, что различие между физическим и логическим в этом случае немного размыто. Поскольку HotSpot по желанию JIT будет переводить ваш код в собственный код, а результат может зависеть от ряда оптимизаций, можно утверждать, что оба представления правильны.

Или можно сказать, что стек является физическим, но то, что идет в стек, является переменным и не всегда простым для получения из исполняемого кода Java. Например, вызовы функций могут быть встроенными или нет, поэтому для вызова вашей функции из одного места может потребоваться дополнительное место в стеке, а для вызова той же функции из другого места или в другое время может не потребоваться или потребоваться меньше (или Больше). Это называется глубоким встраиванием в этого документа . Если вы помещаете ссылки в стек, их размер также может изменяться (существуют приемы, позволяющие иногда сжимать ссылки в 32 бита даже в 64-битной JVM). Поскольку JIT-компилятор работает асинхронно и принимает некоторые решения на основе профилирования данных из выполнения кода, один и тот же код может иметь разную производительность и, возможно, также использовать стек во время разных запусков.

EDIT: Сборщик мусора, JIT-компилятор и т. Д. Работают в отдельных потоках, поэтому они используют свои собственные стеки вызовов, если вы это подразумеваете под «издержками HotSpot».