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 и является самым "производительным".