МурзикТак как верить никому нельзя, я хочу проверить, где создаются переменные:
1. Примитивные
2. Строки
3. Статические переменные
4. Переменные уровня экземпляра при задании какого-то хитрого ХХ-ключа JVM.

также мне интересно, освобождает ли GC область памяти PermGen.

1. Локальные переменные создаются на стеке. Не важно примитивы или ссылка на объект.
2. Строки это объекты. Живут в куче как все либо в пуле строк. Пул живет в PermGen или MetaSpace.
3. Статические переменные это поля объекта-класса. Они живут в куче, как и сам класс. Скорее всего в PermGen/MetaSpace.
4. Какого такого хитрого ключа?
5. PermGen освобождается.

Это и много другое можно смотреть в профайлерах (например VisualVM) или инструментах разработки - jstat, jconsole, mission control

МурзикКлюч именуется: -XX:+DoEscapeAnalysis
--
+статический контекст -сюда загружаются java-классы со своей структурой, из
которых потом будут создаваться экземпляры, тут же хранятся переменные уровня класса (которые static)
+стек — тут выполняются инструкции описанные в методах и тут же примитивные переменные
+heap — хранятся переменные уровня экземпляра для объектов
+garbage collection — сюда сваливаются уже ненужные переменные из heap
---

С такой терминологией разбираться в Escape Analysis, по-моему рано. Потому что терминология не точная и показывает полное непонимание происходящего.

МурзикНигде больше я не нашел инфу про область памяти garbage collection, посему начал разбираться что и как.

Нет такой "области памяти". Есть "куча", у неё есть "поколения". Есть ещё нативная памяти процесса вне кучи (off heap).

Мурзик+Статический контекст в оригинале называется PermGen

А если идти в ногу со временем, то Metaspace.

Мурзик+Стек - это ThreadStack

"Стек" это "стек". Точный и понятный термин. Даже если не указывать Thread, то спутать с коллекцией java.util.Stack довольно сложно.

Мурзик+heap - состоит из нескольких частей.

Обычно "поколений". Но фрагментация кучи может быть разной в зависимости от реализации сборщика мусора.

МурзикЧто интересно, а если эти переменные поместить в другом методе (не main), создать экземпляр этого класса и выполнить этот метод, то как долго эти переменные будут занимать место в stack?

Какая разница, выполняется метод экземпляра или статический? Ведь локальные переменные все равно живут на стеке.
Тут опять же в вашей терминологии, сложно сориентироваться. Что значит "занимать". Фрейм завершается и на месте старых переменных можно писать новые. Но вот вопрос, когда область памяти заполнена данными, но ещё не перезаписано это "переменная занимает память" или нет?

МурзикДля этого мне и требовался инстрУмент для программного измерения заполненности ThreadStack.

Ну, так инструмент надо было искать, а не самому писать на pure Java.

МурзикЗадавался вопрос - почему я не верю документации от вендора.
Ответ такой: Был я как-то на московской конференции Тома Кайта и он сказал, что надо верить только тому, что прошло через ваши руки здесь и сейчас.
Может что-то измениться - например, выйдет новый релиз, в котором будет изменено именно ЭТО.
Дока писалась для определенной версии java - после этого вышло около 60-ти релизов (версия 1.7.60).
Именно поэтому я очень люблю проверять то, что написано - на заборе вот тоже много чего написано, а за забором - дрова :)
Такие вот мысли.
Возможно вам интересно. Это хорошо что вы продолжаете в этом направлении копаться. Но на самом деле пользы для вас от этого будет мало. Лучше бы разобраться с терминологией сначала, и понять что как работает вообще, а потом уже разбираться в деталях.

Ну, и если очень интересны детали, то по-моему проще всего скачать OpenJDK и смотреть как реализован стэк.

МурзикЧитаем доку:
http://docs.oracle.com/javase/specs/jls/se7/html/index.html

Это не единственная дока. Есть например ещё такая:
http://docs.oracle.com/javase/specs/jvms/se7/html/

Но это только спецификации на язык и виртуальную машину. Реализация спецификаций может содержать свои алгоритмы и структуры. Главное чтобы они не перечили спецификации.

Мурзик Обратите внимание на дату - 2013-02-28
Я правильно понимаю, что с тех пор java изменялась отдельно от доки?

Вы уделяете внимание каким-то совершенно не важным мелочам. Почему надо обращать внимание на дату? JLS это не полное описание работы всего и вся. Это спецификация на то как должна работать система. Изменяется она не часто. Разве что вносятся небольшие правки. Это совершенно не значит что в реализации ничего не меняется.

МурзикВсе, что нашел в доке про память:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields, and array elements are stored in heap memory. In this chapter, we use the term variable to refer to both fields and array elements.


Правильно. Что наводит нас на мысль, что JLS поможет не особо.

Мурзик Возможно, я не владею технологией поиска или ищу там, где светло (или куда указывает yandex.ru по словам java 7 memory model) - помогите пож-ста найти там, где темно.
Заранее спасибо.
Вы не владеете терминами. И это первое с чем стоит ознакомится.
Memory model:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4
Это вообще не о том:
http://en.wikipedia.org/wiki/Java_Memory_Model

Мурзик,

Какая конкретно задача? Посмотреть как утроет стек потока в Hotspot?

О! Открыл для себя интересную фичу.
VisualVM -> Heap Dump -> Summary -> Threads at the heap dump -> Show Threads
Показывает дамп потоков с локальными переменными. По-моему только теми, которые на кучу ссылаются. Примитивов не наблюдаю.

МурзикНа этой странице я попытался найти слово heap - 2 совпадения.
Тут же слово perm находится тоже 2 раза.

Получается крамольная весЧь - java скрывает структуру памяти.
По крайней мере, в доке о поколениях или (составных частях) памяти heap не говорится. Буду рад ссылкам на оф. доку, где мои слова будут опровергнуты.

Это по ОраклиНому - попытайтесь, например в доке по Oracle12c найти описание таблицы sys.ltxid_trans. А в TransactionGuard она очень хорошо используется :)

Где же можно овладеть этими терминами, как не в первоисточнике?
Потому что работа GC она не покрывается спецификацией. GC у разных JVM может работать совершенно по-разному. И может даже вообще без GC.
Тема большая. С наскока будет не просто:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Мурзик,

И ещё полезных ссылок:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html

Кстати, забудьте про yandex. Его зона доминирования заканчивается рунетом.

МурзикПолучается, что структура памяти - все эти heap (и порожденный им PermGen)/stack у каждой JVM своя?
Да. Можно так сказать.

МурзикПопутно возник еще один вопрос - может ли GarbageCollector, освобождая память heap, освободить память, занимаемую процессом ОС?
Мне кажется это не совсем задача GC.
JVM может уменьшит размер кучи, если решит что она излишне велика для насущных задачь.
Под Windows раньше была такая бага, что JVM не могла вернуть мапять в ОС. Актуальна ли она сейчас - не знаю.

Ссылки по теме
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6498735
https://blogs.oracle.com/jonthecollector/entry/the_unspoken_the_why_of

МурзикАктуальна
Пруфлинк?

МурзикБуду рад конструктивной критике.
http://www.sql.ru/forum/rules.aspx Рекомендуется:
Для повышения удобочитаемости сообщений - пользоваться специальными кодами для выделения слов (b, u, i, color) ( но не злоупотреблять ими ) и тегом форматирования исходных кодов src .

МурзикЗапуск с ключом -XX:+UseParallelGC
-XX:+UseAdaptiveSizePolicy ?

МурзикБуду рад конструктивной критике.
Вот. То же самое. Но, какое оформление!
http://www.stefankrause.net/wp/?p=14

МурзикБесполезняк - не чистит:

А на линухе?

МурзикПостарался не перестараться с оформлениями - а то за синими деревьями не увидим леса, в который чем дальше, тем непонятнее. И хоть меняй ты мусороуборщика, хоть не меняй ...
Дорогой дневничок...