Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>ну например List<MyObj>
EP>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
Ничего, и не такое жевал.

EP>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.

EP>3. Лишние индерекции внутри List никуда не делись.
List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.

EP>>>И кто и как создаст эти newMyObj?
dot>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>"в общем-то и вся разница по факту." — да?
EP>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
Берёт что? Код-то тривиальный.
Вместо

class BusinessData
{
  private int a;
  private int b;
  int getA() {return a}
  int getB() {return b}
}

пишем

class BusinessData
{
  private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
  private int pos;
  int getA() {return buf.getInt(pos)}
  int getB() {return buf.getInt(pos+4)}
}

List<> просто проставляет pos соответственно.