gcimpl#1234
Conversation
…d implementation of cross-referencing solution
pesua
left a comment
pesua
left a comment
There was a problem hiding this comment.
В коментарии написано много лишнего, но нет ответа на вопрос что такое достижимость.
| } | ||
|
|
||
| private List<ApplicationBean> getChildren(ApplicationBean bean, | ||
| ArrayList<ApplicationBean> distinctions) { |
There was a problem hiding this comment.
Различия? Не понял названия, теперь сложно понять что происходит.
There was a problem hiding this comment.
Это мое решение проблемы кросс-референса. Я оч долго об неё бился и разбился на несколько вложенных циклов, тонну ифчиков и бесполезный счетчик указателей который можно было не делать.
В итоге переписал практически с нуля (ну, по коммитам кстати видно) и получилось вот это. Щас сяду и порефакторю код с комментами, чтобы было понятнее.
| } | ||
| } | ||
|
|
||
| garbage = garbage.stream().filter(entry -> !(alive.contains(entry))) |
|
|
||
| private List<ApplicationBean> getChildren(ApplicationBean bean, | ||
| ArrayList<ApplicationBean> distinctions) { | ||
| List<ApplicationBean> garbage = new ArrayList<>(); |
There was a problem hiding this comment.
Разве это мусор? Как я понял по коду - наоборот сюда достижимые объекты попадают.
|
Достижимым считается объект, к которому есть обращения. То есть если на него есть ссылки (например методы загруженные в стек обращаются к этому объекту) - объект достижим и удалять его не следует. |
Kiriche
added
ready for review
2 participants
Мое понимание работы сборщика:
Каждый объект - экземпляр класса. Все данные об объекте, включая сигнатуры и описание методов, хранят в куче. Куча, насколько я помню, подразделена на разделы. Эти разделы фактически отвечают за отделение объектов-долгожителей от объектов которые пригодятся приложению непродолжительное количество времени. Если объект не вызывался какое-то количество времени после вызова сборщика мусора - он будет флагнут на сборку и собран при следующей сборке.
Стек - это принцип по которому работает память в случае с методами. В начале и в ходе работы приложения методы могут помещаться на вершину стека. Каждый метод вызывается по очереди, по принципу "последний вошел - первым вышел". По мере того как методы выполняются - также уменьшается и счетчик ссылок на каждый конкретный объект. Таким образом, на основании ссылок, а также статусе объекта в куче, JVM может делать вывод о том, необходимо ли отправлять его на сборку мусора при следующем вызове сборщика.
Сам сборщик работает автоматически и, насколько я знаю, в явную его почти никогда не вызывают. Автоматизм осуществляется за счет достижения верхнего предела памяти, который JVM выделяет тому сегменту кучи, который предназначен для новых объектов.