Комментарии 8
Мне кажется что в нынешних реалиях SerialGC это не столько про экономию памяти, сколько про работу в ситуации когда JVM доступно только одно процессорное ядро.
Известно что JVM, по умолчанию в такой ситуации, запускает именно SerialGC, видимо потому, что все остальные GC не дают никаких выигрышей, если для нужных им дополнительных потоков у окружения доступных процессорных ядер нету.
И это не редкая ситуация в реальности, когда люди запускаю приложение в какой-нить виртуальной ноде с единственным доступным процессорным ядром. А потом удивляются.
А память... я сильно сомневаюсь, что кто-то реально живет с SerialGC чтобы память экономить.
Только epsilon, только хардкор
А как работает сборщик мусора в 1С? Что аж приходится перезапускать рабочий процесс по памяти...
Может кто скажет, сколько тактов процессора занимает обращение
object->member
с учетом, что объект подвержен сбору мусора и сначала надо найти в какой куче он лежит.
На С++ с учетом девиртуализации это занимает минимальное возможно время, то есть просто обращение к памяти по адресу. А вот в Java для меня загадка.
ps это вопрос который я задаю много лет и никто из джавистов еще не ответил.
Ну я бы ожидал, что jvm не надо ничего искать в момент вызова. Даже если куча с точки зрения gc поделена на сектора, это ведь всего лишь один из возможных вариантов. Почему куче не быть сплошным куском в памяти, как noop gc? Механизм вызова при этом вряд ли стал бы меняться.
Вот тут описывается сам invokevirtual
https://blogs.oracle.com/javamagazine/post/mastering-the-mechanics-of-java-method-invocation
А тут говорят о том, как jvm поддерживает ссылки в актуальном состоянии
https://stackoverflow.com/questions/9465767/if-the-jvm-keeps-moving-objects-around-when-it-does-gc-how-does-it-resolve-refe
Сборка мусора в Java. Часть №1. Обзор сборщиков мусора и их различий