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

dot>>>>ну например List<MyObj>
EP>>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>>Ничего, и не такое жевал.
EP>Так в off-heap тогда смысла мало
Когда как. Очень зависит от юзкейсов. Невозможно сказать: "делай так и будет быстро".

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

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

dot>>

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

EP>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
Двигаешь pos и получаешь элемент. Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?