Вообще, если придираться, размеры одного и того же объекта в разных поколениях GC(да и в TLAB) могут отличаться. По крайней мере, у такой экзотики как Jikes.
Ну, я сразу сказал что придираюсь :-) Но у проблемы два аспекта, мне кажется: 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. Как все это жило с фактически двумя версиями кода - не помню :-)
Про накладные расходы на организацию памяти -- спасибо, про это легко забыть, да.
Уплотнение объектов, разные компоновки в разных поколениях -- любопытно узнать, что с этим экспериментировали. Я ничего про такое раньше не слышал. Как и про то, что это сейчас где-то применяется. А жаль, интересные вещи могли бы получиться. Но правда кажется, что генерировать код для работы с переменной структурой данных -- то еще удовольствие.
Память сейчас дешевая -- видимо, поэтому особого развития направление не получило.
А в чем проблема с EA? EA (если вы имеете в виду EA+stack allocation) может снизить нагрузку на сборщик мусора в молодом поколении, но мне кажется, он не меняет сколько либо заметно объем зрелого поколения.
Да, это я про stack allocation. Просто это вполне реальный пример(хотя и вырожденный) когда HotSpot меняет раскладку объекта. На стеке у него даже заголовка нет. А попытки sizeof'а в этом случае - типичный гейнзербаг.
Я практически уверен, что только завидев применение Unsafe к объекту -- EA сбежит в ужасе, и сделает вид, что его здесь никогда не стояло. Это очень консервативная оптимизация
Вообще, если придираться, размеры одного и того же объекта в разных поколениях GC(да и в TLAB) могут отличаться. По крайней мере, у такой экзотики как Jikes.
ОтветитьУдалитьЭто любопытно. Хотя вообще логично, что такое может быть, да.
ОтветитьУдалитьА что там меняется в раскладке объекта между поколениями? Где про это можно прочитать?
Ну, я сразу сказал что придираюсь :-)
ОтветитьУдалитьНо у проблемы два аспекта, мне кажется:
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. Как все это жило с фактически двумя версиями кода - не помню :-)
Про накладные расходы на организацию памяти -- спасибо, про это легко забыть, да.
ОтветитьУдалитьУплотнение объектов, разные компоновки в разных поколениях -- любопытно узнать, что с этим экспериментировали. Я ничего про такое раньше не слышал. Как и про то, что это сейчас где-то применяется. А жаль, интересные вещи могли бы получиться. Но правда кажется, что генерировать код для работы с переменной структурой данных -- то еще удовольствие.
Память сейчас дешевая -- видимо, поэтому особого развития направление не получило.
За ссылку спасибо
Вам за блог спасибо :-)
ОтветитьУдалитьА - еще про EscapeAnalysis забыли.
А в чем проблема с EA? EA (если вы имеете в виду EA+stack allocation) может снизить нагрузку на сборщик мусора в молодом поколении, но мне кажется, он не меняет сколько либо заметно объем зрелого поколения.
ОтветитьУдалитьДа, это я про stack allocation. Просто это вполне реальный пример(хотя и вырожденный) когда HotSpot меняет раскладку объекта. На стеке у него даже заголовка нет.
ОтветитьУдалитьА попытки sizeof'а в этом случае - типичный гейнзербаг.
Я практически уверен, что только завидев применение Unsafe к объекту -- EA сбежит в ужасе, и сделает вид, что его здесь никогда не стояло. Это очень консервативная оптимизация
ОтветитьУдалить