bulle_anСогласен, все это сильное упрощение, которое может быть не совсем точным.

И не только "не совсем точным", но и наглухо не верным. PermGen служит другим задачам, а не подбирает объекты после Tenured.

bulle_anЕдинственно верный ответ вы найдете в исходниках OpenJDK

Это тоже в корне не верно. Поведение GC в Oracle JVM достаточно не плохо документировано. При чем тут OpenJDK, не совсем понятно.

bulle_anНебольшая ремарка - в Permanent Generation располагаются те данные, на которые ссылаются в протяжении всего времени работы приложения.
Смотря что называть "приложением". В любом случае это заблуждение. Классы их PermGen можно выгружать.

bulle_anТе классы, которые загружены базовым загрузчиком, загрузчиком расширений и системным. Определения всех классов приложения, в том числе и классов самой JVM - имена классов, информация о пуле констант, массивы объектов и массивы типов, ассоциированных с классом, внутренние объекты, создаваемые JVM , информация используемая для оптимизации. Статические члены, код методов (статических и не статических).
Слишком много своих домыслов.

redwhite90Часто люди любят ругаться такими словами. Дайте что-нить почитать, чтоб просветиться.
http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf
Вот подборка отличных статей для Hotspot
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html

Heap она же "куча" это способ управлять памятью. Тривиальный способ работы с объектами в С++, например, - выделить память, записать туда состояние объекта. После использования вызвать деструктор и освободить память. Этот подход является очень медленным. Резервировать и освобождать память на каждый объект отдельно - очень затратно для большого числа объектов.
Поэтому альтернативным подходом является "куча". Это зарезервированная под объекты область памяти процесса, которая управляется каким-то отдельным под-процессом. В случае Java это JVM и её GC. С одной стороны по памяти накладно резервировать сразу большое количество. Зато это даёт хороший прирост производительности. Удаление объектов, например, не стоит почти ничего.

PermGen - особая область кучи, для хранение объектов, которые вряд ли придется удалять. К таким объектам относятся классы, загрузчики и пул строковых констант.

Стек - это такая структура данных ( http://en.wikipedia.org/wiki/LIFO_(computing)). Последний кто попадёт в стек выйдет из него перым. Через стек организована работа процедурных языков. Каждая процедура имеет свои переменные, и вызывает другие процедуры. Переменные, которые принадлежат процедурам, хранятся в стеке. То есть, для того чтобы вызвать другую процедуру, нужно где-то сохранить свои переменные, вызвать под-процедуру, а по выходу из неё как-то восстановить состояние. Так как вызовы под-процедур могут иметь большую вложенность, то очень удобно хранить состояние каждой под-процедуры в стеке. А при выходе из процедуры, восстанавливать переменные из стэка.

Java в стеке хранит только локальные переменные. За что её часто критикуют. C#, например, изначально позволяет хранить на стеке структуры данных. Недавно прошла инфа о том что возможность добавления структур в Java изучается. И есть шанс что в Java 9 они появятся.

Йуный джавистЪВ C++ тоже есть куча.
Я где-то утверждал что её там нет? В С++, помимо тривиального, доступны разные способы управления памятью для объектов. В том числе и "куча". А что?

Сергей АрсеньевBlazkowiczПоэтому альтернативным подходом является "куча". Это зарезервированная под объекты область памяти процесса, которая управляется каким-то отдельным под-процессом.
Всю жизнь под кучей (heap) понимал кусок памяти в котором в произвольном порядке находятся (могут находиться) разнородные объекты. Когда успело смениться определение?
Оно точно так же притянуто за уши как и ваше и на документальность не претендует.

Сергей АрсеньевЯ в том смысле, что способ хранения куча, стек, область программы и т.п. - вещи перпендикулярные необходимости выделять память и ее освобождать. Меняется только способ реализации.
Вы как-то не так интерпретировали мой коментарий и сами исправляете свою интерпретацию. Я нигде не писал что куча отменяет надобность выделять память.
Есть тривиальный способ выделения памяти перед созданием объекта. И освобождением её после использования объекта. А есть куча - выделение некоторой области памяти заранее под будущие объекты. По-моему это логично и очевидно. Почему вдруг вы решили что наличие кучи вдруг как-то отменяет выделение памяти, мне не понятно. Если с каким-то конкретным тезисом не согласны, так хотя бы цитировали его. Потому что в этой цитате

авторПоэтому альтернативным подходом является "куча". Это зарезервированная под объекты область памяти процесса, которая управляется каким-то отдельным под-процессом.
Я как-то ошибок не наблюдаю.

Сергей АрсеньевBlazkowicz Этот подход является очень медленным. Резервировать и освобождать память на каждый объект отдельно - очень затратно для большого числа объектов.
Поэтому альтернативным подходом является "куча".
Это чьи слова?
Ошибка в чем?

Сергей Арсеньев Правильнее IMHO алтернативным подходом является куча, которая управляется каким-то отдельным под-процессом , если брать Ваши слова.
М-да. Проехали. Мне вас не понять.

Atum1раньше текли в ограниченном объеме ,который и назывался Permanent Generation, а теперь текут в хипе , где памяти больше :)
Нет. Не в хипе, а в metaspace, который вне хипа.

redwhite90Но ничего не написано по предназначение кадждого из сборщиков мусора.
Подразумевается, что каждый из них придуман для своей корневой точки?
Нет. Это разные алгоритмы, каждый со своими плюсами и минусами.
https://blogs.oracle.com/jonthecollector/entry/our_collectors
Serial - самый старый способ сборки мусора. Он однопоточный. Его проблема в огромных паузах, когда JVM останавливает все свои потоки для сборки мусора. При этом он является самым высокопроизводительным. Не плохо подходит для задач массовой обработки.
Длинные паузы (stop-the-world) в JVM это большая проблема как для GUI, так и для серверных приложений. Поэтому следующим шагом стала разработка алгоритмов для уменьшения этих пауз.
Parallel - это тот же алгоритм что и Serial, но оптимизированый для многопоточного выполнения - больше потоков работает - короче пауза.
CMS - это более новый алгоритм, который позволяет свести паузы к минимуму или даже избавится от них в определенных условиях.
Основная проблема CMS и остальных алгоритмов в том что они сканируют все живые объекты. И это становится нереально тяжелым процессом, когда живых объектов в JVM 4Гб и более.
Поэтому был разработан новый алогоритм G1 - который сегментирует кучу и позволяет делать сборку в отдельных сегментах. Тем самым влияние размера кучи и количество живых объектов на паузы уменьшает.

Каждый же новый алгоритм GC является более сложным, что приводит к дополнительному уменьшению производительности. Поэтому-то serial и является самым "производительным".

redwhite90ок. по алгоритмам прошлись. А используется какой? выбирается в runtime или зависит от версии jvm или ещё как-то?
Ну, либо алгоритм задаётся параметрами. Либо выбирается в зависимости от версии, размера кучи, серверной\клиентской JVM и пр.
Например вот:
http://www.techpaste.com/2012/02/20/default-jvm-settings-gc-jit-java-heap-sizes-xms-xmx-operating-systems/#more-3569

redwhite90и кстати tenured это новое название old generation?
Во-первых назавание не новое совсем.
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
Во-вторых, грубо-говоря, да. Но точные названия могут отличатся в разных алгоритмах.

redwhite90С точки зрения GC память делится на
young generation
old/tenured generation
permgen/metaspace

Это сегментирование кучи, а не памяти. Если называть вещи конктреными именами, а не обобщеными, то в этих классификациях появится смысл.

redwhite90С точки зрения способа и хранения и соответствия внешнему источнику(RAM, жёсткий диск...) данных(чувствую, что неправильно выразился - поправьте пожалуйста) память можно поделить на:

При чем здесь Java?

redwhite90heap
stack

Что с ними?

redwhite90Есть ли связь между этими классификациями?

они все имеют отношение к компьютерам и слову "память"?

redwhite90Ок. а GC чистит только heap получается?

Ну, да. Только не понятно как теперь metaspace очищается. Он, ведь, вне кучи.

redwhite90назовите пожалуйста эти конкретные имена;) не совсем понял о чем речь.
Мне тоже сложно понять о чем речь, когда с разговора о сегментировании кучи приплетается вопрос о разделении панями на оперативную и постоянную.

redwhite90ну всмысле а они называют это native heap.
Как интересно теперь называть обычный heap чтобы не запутаться.
Java Heap

Leonid KudryavtsevТупой вопрос, а что такое "native heap" ? Что понимается под "native", в смысле, вместо GC, работают через обычные C-ные malloc/free ? Нафига ?
Чтобы хранить там служебные данные JVM, которые в Java куче хранить смысла нет. Во-первых потому-что пользовательский код их слабо контролирует. Во-вторых потому что наличие их в Java куче сказывается на производительность. И в-третих потому что нативную кучу проще увеличивать, чем Java heap.
Во что это выльется со временем, сказать сложно.

redwhite90BlazkowiczПоэтому был разработан новый алогоритм G1 - который сегментирует кучу и позволяет делать сборку в отдельных сегментах.
То есть до появления этого алгоритма не было такиз понятий как Old/young generation и permgen?
Нет. Возможно, я не достаточно точно выразился.
Сегментация кучи на поколения, существовала ещё в Java 1.3. Про более ранние версии не скажу точно.
G1 сегментирует кучу на карты (cards), позволяя сканировать отдельные карты на предмет объектов, которые нужно переместить. Таким образом нет необходимости сканировать ВСЕ живые объекты в куче, как это делают другие алгоритмые в случае полной сборки.

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