Java Digest: Java 15 Superclass/Hierarchy gap — еще одна оптимизация памяти «for free»
Статья простым языком о реальном размере объектов в памяти от Шипилева: ссылка по его блогу shipilev.net.
Вкратце:
Проблема: размер объектов в памяти кратно 8 байтам (16, 24, 32...), т.е. при размере объекта в 17 байт выделяется 24. При наследовании все хуже — каждый наследник так же может содержать «пустые» байты.
Решение: в Java 15 реализовали (уже в превью) возможность использовать «пустые» байты наследниками, наследниками наследников и тд по всей иерархии наследования
Результат: более компактный размер кучи, ускорение доступа к объектам\филдам. И да — нам не нужно менять сорцы, перекомпилировать и тд — все сделает VM
Edit: это предложение на следующий дайджест
OpenJDK Project Valhalla Releases LW2 Prototype. Если тема вам не интересно, то просто запомните что теперь value types называются inline classes.
Как я понимаю пришли к новому имени «records» (Records (Preview)). И если кратко из последнего:
1) Обьявляются почти как классы, только со списком филдов («components»):
record Point(int i, int j) {
public Point(int i, int j) {
this.i = i;
this.j = j;
}
}
, где «record components» (int i, int j) по дефолту и неявно private final.
2) В отличие от классов с суперпарентом Object, создан новый супер парент:
The direct superclass of a record type R is java.lang.Record.
В точку!
Лучше опишите подробнее что имеется в виду под «отобразить на экране»
Возможно это список из названий товаров с минимальным набором кнопок «Добавить» «Удалить» — и это пару часов работы, а возможно это отображение магазина с описаниями, картинками, отзывами, картой отделений, возможностью оплаты и т.д — и это несколько месяцев разработки, дизайна и т.д.
Возможно у вы уже видели приложения с подобной структурой — приведите их для примера (например hotline, olx)
И мне напишите, пожалуйста)
Только «Соло» может «гарантировать» что ты 100% выучишь слепой набор за 100 уроков
Немного не то. Здесь не стоит задача обрабатывать массивы объектов или снизить нагрузку на процессор. Задача: компактно разместить в памяти разные объекты, которые наплодил пользователь. Плюс задел на будущее
Как пример проблемы: программа создает 3 объекта Person, x4 AuthToken, x100 JsonToXmlAbstractFabric... которые по факту используются программой раз в сто лет, но должно «жить» в памяти постоянно
В случае с RGB (приведение к единому размеру, обработка блоками и тд) — это уже оптимизация специфической задачи\алгоритма. Хотя и здесь приятнее иметь более компактные чанки