Индекс форумов |
Исходное сообщение |
---|
"Выпуск Java SE 20" Отправлено Аноним, 22-Мрт-23 18:48 |
Ну допустим аллокации быстрые, т.к. до следующего GC цикла с компактификацией менеджеру кучи не нужно искать какое-нибудь свободное место подходящего размера. Но это не отменяет того, что непрямой доступ (по ссылке, которая по сути, неявный указатель) сохраняется и даже если объекты сидят в начале памяти, GC не делает их группировку по смыслу при размещении по фактическим адресам в памяти, так сказать. Т.е. допустим есть несколько List коллекций, даже если прошло сжатие кучи и все списки перемещены и "уплотнены" в начале кучи, это абсолютно не значит, что объекты не перемешаны друг относительно друга в рандомном порядке (т.к. GC работает в несколько параллельных потоков, намеренно не синхронизированных, ордеринг по размещению в памяти не сохраняется). А это выливается в то, что когда проц грузит данные в кэши, то в кэш-линиях соседствуют друг с другом данные, не связанные по смыслу. Из-за чего cache miss постоянный и связанные с ним издержки. В каком-нибудь хайлоаде с могучим RPS это имеет значение. Не зря же исписали кучу статей и исследований про data oriented programming и mechanical sympathy. Поэтому все и просят постоянно, чтобы добавили в язык "плоские" структуры и аллокацию на стеке, чтобы затрагивать хип только когда нужно, а не "почти всегда". |
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования. |
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |