Читаю серию статей про gc.
есть пара вопросов
https://habrahabr.ru/post/269707/#comment_8633685 Например, если при малой сборке JVM не удается укладываться в отведенное вами время, размер младшего поколения может быть уменьшен. Если не удается достигнуть заданной пропускной способности, а с задержкой проблем нет, то размер поколения будет увеличен. И так далее.

При этом следует иметь в виду, что в статистике игнорируются сборки мусора, запущенные вами вручную.



Как можно запустить сборку мусора вручную?

и второй вопрос:

https://habrahabr.ru/post/269621/ Рассмотрим такую ситуацию: У нас есть молодой объект A и ссылающийся на него объект B, уже заслуживший место в старшем поколении. В какой-то момент времени оба этих объекта стали нам не нужны и мы обнулили все имеющиеся у нас ссылки на них. Очевидно, объект A можно было бы удалить в ближайшую малую сборку мусора, но для того, чтобы получить это знание, сборщику пришлось бы просмотреть всё старшее поколение и понять, что объект B ссылающийся на A, тоже является мусором, а следовательно их оба можно утилизировать. Но анализ старшего поколения не входит в план малой сборки, так как является относительно дорогой процедурой, поэтому объект А во время малой сборки будет считаться живым.

https://habrahabr.ru/post/269621/ Таким образом, чаще всего для целей малой сборки мусора объект считается мертвым и подлежащим утилизации, если до него невозможно добраться по ссылкам ни из объектов старшего поколения, ни из так называемых корней (roots), к каковым относятся ссылки из стеков потоков, статические члены классов и т. п. При полной сборке мусора могут анализироваться оба поколения, поэтому здесь сборщик может плясать только от корней.

Эти две цитаты идут в тексте последовательно. Как я их понял они друг другу противоречат. В первой говорится, что старшее поколение не сканирует при minor gc, а во второй пишут, что при minor gc объект считается мертвым если до него не добраться п о ссылкам ни из объектов старшего поколения, ...

Так как же мы узнаем, что до объекта не добраться из старшего поколения если мы это самое поколение сканировать не будем?

Blazkowicz Объект А считается живым, так как на него есть ссылка из старого поколения. В чем противоречие?

Противоречие с этой фразой:
habrТаким образом, чаще всего для целей малой сборки мусора объект считается мертвым и подлежащим утилизации, если до него невозможно добраться по ссылкам ни из объектов старшего поколения, ни из так называемых корней (roots), к каковым относятся ссылки из стеков потоков, статические члены классов и т. п. При полной сборке мусора могут анализироваться оба поколения, поэтому здесь сборщик может плясать только от корней.

Как я понимаю этот абзац, чтобы удалить объект из young generation нам нужно понять нет ли ссылок на него в old generation. Как я понимаю для этого нам нужно сканировать old generation.

habr Но анализ старшего поколения не входит в план малой сборки, так как является относительно дорогой процедурой, поэтому объект А во время малой сборки будет считаться живым.

Blazkowiczquestioner,

Вот ещё хороший ответ с объяснением как именно это работает
http://stackoverflow.com/a/3849058

Спасибо. Получается просто прогуляться по old generation мы можем, а вот анализироваться он не будет уже при minor gc

BlazkowiczДо Card Table не дочитал?

Дочитал. Понял, что суть его в том, чтобы весь old не сканировать, а только те его участки, в которых могут быть ссылки на young.

А вот принцип, я не уверен, что понял верно.

old generation делится на сегменты некоторого фиксированного размера(его можно менять кстати?). Допустим сегментов 1000.
создаем булеан массив на 1000 элементов.
в каждом сегменте n-ое количество объектов. Так вот если у объекта(из old generation) меняется какая-либо внутренняя ссылка, то карта считается грязной.
после того как объект попал в old generation, то видимо у него не может быть ссылок на young изначально. и поэтому по умолчанию карта чистая.

булеан элемент в массиве соответствует карте. карта соответствует некоторому количеству объектов

Blazkowicz,
я так понимаю это 4 точки откуда gc начинает поиск мусора:
автор-Локальные переменные и параметры методов
-Java Потоки
-Статические переменные
-Ссылки из JNI


При этом gc чистит только heap.
А как же область памяти стек, в котором хранятся локальные переменные и параметры методов ?

Что-то я совсем запутался.

всего ведь бывает java использует

heap
stack
Permanent Generation/metaspace
Code Cache(я так понимаю для нативности)

Насколько я понимаю структура используемой памяти задаётся gc.

а стек в этой иерархии где?
Чистится ли стек?
локальные переменные таки в хипе или в стеке?

Blazkowicz,

BlazkowiczЯ вообще не понимаю зачем ты пытаешься понять ТОЧНЫЙ алгоритм работы GC, не ознакомившись обзорно, хотя бы с алгоритмами и фазами.

Я почитал про структуру хипа, про young/old gen, про serial,parallel,cms/g1, в курсе про minor/major gc. Понимаю что такое STW.
Что ещё почитать?

Просто не понятно почему говорят, что локальные переменные создаются на стеке, а чистим мы их в хипе. Мне непонятно как они туда попадают.

BlazkowiczЛокальные переменные это ссылки же и примитивы.

Это многое объясняет

BlazkowiczquestionerНасколько я понимаю структура используемой памяти задаётся gc.
Нет.


В G1 ведь память по другому менеджит.

поколения те же, но ведь они разбросаны вразнобой

BlazkowiczquestionerВ G1 ведь память по другому менеджит.
поколения те же, но ведь они разбросаны вразнобой
Но это всё происходит внутри кучи и не относится к тем типам памяти, которые ты перечисляешь в этой теме.

ошибся, надо было написать структуру хипа, а не памяти.

Blazkowicz,

авторПо умолчанию и малая и полная сборка задействуют многопоточность. Малая пользуется ею при переносе объектов в старшее поколение, а полная — при уплотнении данных в старшем поколении.

Каждый поток сборщика получает свой участок памяти в регионе Old Gen, так называемый буфер повышения (promotion buffer), куда только он может переносить данные, чтобы не мешать другим потокам. Такой подход ускоряет сборку мусора, но имеет и небольшое негативное последствие в виде возможной фрагментации памяти:


После major gc parallel-ым gc в old gen данные будут полностью уплотнены или только в рамках участка, отданного потока?

questionerданные будут полностью
объекты
questionerотданного потока?

потоку