14 мая 2012 г.

How much memory objects take on JVM, and why this may matter


8 комментариев:

  1. Вообще, если придираться, размеры одного и того же объекта в разных поколениях GC(да и в TLAB) могут отличаться. По крайней мере, у такой экзотики как Jikes.

    ОтветитьУдалить
  2. Это любопытно. Хотя вообще логично, что такое может быть, да.

    А что там меняется в раскладке объекта между поколениями? Где про это можно прочитать?

    ОтветитьУдалить
  3. Ну, я сразу сказал что придираюсь :-)
    Но у проблемы два аспекта, мне кажется:
    1. Кроме "чистого" "How much memory objects take", есть еще и "грязный",
    типа : в young generation/TLAB/LOB выделение памяти идет через bump pointer, но в mature generation есть дополнительные расходы : выделение идет через free-list'ы со своими заголовками + bitmap для обратных ссылок +, к примеру, может быть приторочен счетчик для ссылок (извините, совcем экзотка). То есть сами объекты не меняется но отличаются размером заголовков, и дополнительная память выделяется где-то сбоку. Описание, как это делается у теоретиков, отчасти тут:
    http://www.cs.utexas.edu/~mckinley/papers/mmtk-icse-2004.pdf. Но статья древняя, да.
    Самому интересно посмотреть имеет ли это отношение к реальному HotSpot'у
    2. Не могу сходу найти статью,
    но в той же Jikes кто-то игрался попытаясь поплотнее ужать поля у объектов в young generations (типа чем больше влезет - тем лучше) и правильно их уже выравнивая в mature generations. Как все это жило с фактически двумя версиями кода - не помню :-)

    ОтветитьУдалить
  4. Про накладные расходы на организацию памяти -- спасибо, про это легко забыть, да.

    Уплотнение объектов, разные компоновки в разных поколениях -- любопытно узнать, что с этим экспериментировали. Я ничего про такое раньше не слышал. Как и про то, что это сейчас где-то применяется. А жаль, интересные вещи могли бы получиться. Но правда кажется, что генерировать код для работы с переменной структурой данных -- то еще удовольствие.

    Память сейчас дешевая -- видимо, поэтому особого развития направление не получило.

    За ссылку спасибо

    ОтветитьУдалить
  5. Вам за блог спасибо :-)
    А - еще про EscapeAnalysis забыли.

    ОтветитьУдалить
  6. А в чем проблема с EA? EA (если вы имеете в виду EA+stack allocation) может снизить нагрузку на сборщик мусора в молодом поколении, но мне кажется, он не меняет сколько либо заметно объем зрелого поколения.

    ОтветитьУдалить
  7. Да, это я про stack allocation. Просто это вполне реальный пример(хотя и вырожденный) когда HotSpot меняет раскладку объекта. На стеке у него даже заголовка нет.
    А попытки sizeof'а в этом случае - типичный гейнзербаг.

    ОтветитьУдалить
  8. Я практически уверен, что только завидев применение Unsafe к объекту -- EA сбежит в ужасе, и сделает вид, что его здесь никогда не стояло. Это очень консервативная оптимизация

    ОтветитьУдалить