Washington13 фев 2010 в 19:39

JVM изнутри – организация памяти внутри процесса Java

2 мин

125K

Java *

+20

Комментарии 16

dive 13 фев 2010 в 19:55

Вот это статья (вижу, что в посте есть ссылка) и вот статья, а вот презентация, а то, что выше — это не статья.

Washington 13 фев 2010 в 19:58

все относительно. не считаете статьей — сочтите за заметку :)

dive 13 фев 2010 в 20:00

я не к тому (: просто инвайт никто за эти шесть абзацев не даст. а ведь материал то интересный.

Washington 13 фев 2010 в 20:03

ну мы, по крайней мере, попытались :)

Evengard 13 фев 2010 в 20:02

За что у мну так мало кармы? ( Даже плюс хорошей статье не поставить…

Evengard 13 фев 2010 в 20:17

Иногда я людям поражаюсь…
За обычную похвалу статьи срут в карму…

YasonBy 13 фев 2010 в 22:04

За кармапопрошайничество, весьма плохо завуалированное.

НЛО прилетело и опубликовало эту надпись здесь

Washington 14 фев 2010 в 12:44

Между прочим, в посте говорится не о сборщиках мусора вовсе, как таковых. А о распределении памяти внутри JVM, это несколько другая тема. Сравнивать со статьями по сборщикам мусора (выше) не совсем корректно.

Throwable 16 фев 2010 в 21:22

А меня вот всегда интересовал вопрос, почему бы JVM PermGen и CodeCache не сбрасывать на диск и расшарить для всех процессов JVM? То есть сделать некий кеш-репозиторий, который хранит данные о линковке классов и прекомпилированный код, идентифицируя классы, скажем, по файлу .jar-а из classpath. И сразу решится одна из основных проблем JVM — время запуска апликации. С этой же целью например в виндах и линуксе линкер кеширует информацию о библиотеках.
У меня такое подозрение, что начиная с Java 5, она таскала с собой нечто подобное, но сделанное только для rt.jar. В директории JRE/bin при первом запуске создавался и пух на глазах один файл с расширением типа gst.