История изменений

И вот это всё вместе у меня варится-варится - да не сваривается. Например, если мы разрешаем простые ссылки между кучами разных активностей, то у нас всё равно в итоге все кучи склеиваются в одну.

Если делать разделяемые между потоками данные как ПСД, то под капотом это будут деревья, и тут достаточно ARC (с атомиками) без необходимости искать циклы. Локальные для потока данные при этом будут обычно короткоживущими, так что тут хорошо подойдут арены. Например, когда по сети приходит json-запрос, то он парсится в арене, где память выделяется линейно. Эта арена потом удаляется сразу, что относительно быстро.

Т.е. вместо поколенческого GC взять комбинацию ARC для разделяемых иммутабельных данных и арены+пулы для мутабельных короткоживущих сессионных данных.

Поколенческий GC – это, вообще говоря, арена «на стероидах». Потому что каждое поколение – это арена, из которой выжившие объекты переносятся в другую, большую по размерам. Это же определяет то, почему поколенческие GC так быстры на выделении памяти (и поэтому их очень любят сетевые приложения). Выделение памяти происходит в арене.

И вот это всё вместе у меня варится-варится - да не сваривается. Например, если мы разрешаем простые ссылки между кучами разных активностей, то у нас всё равно в итоге все кучи склеиваются в одну.

Если делать разделяемые между потоками данные как ПСД, то под капотом это будут деревья, и тут достаточно ARC (с атомиками) без необходимости искать циклы. Локальные для потока данные при этом будут обычно короткоживущими, так что тут хорошо подойдут арены. Например, когда по сети приходит json-запрос, то он парсится в арене, где память выделяется линейно. Эта арена потом удаляется сразу, что относительно быстро.

Т.е. вместо поколенческого GC взять комбинацию ARC для разделяемых иммутабельных данных и арены+пулы для мутабельных короткоживущих сессионных данных.