Basil A. SidorovSiemarglТ.е 180Мб этого мало?Вы правда считаете, что Seamonkey на скриншоте в двух местах - просто так?Я думаю что надо пояснять свою мысль.

У меня она была проста - компилятор в памяти => несколько сотен Мб.

А в чем суть сравнения с Сеаманки я не понимаю - современный браузер гораздо сложнее текстового редактора jEdit и содержит внутри себя кучу интерпретаторов CSS/HTMLK/JS и мало ли что еще.
Тогда уж с Netsurf сравнивать.

Но повторяю, я идею из слинкованного скриншота не оценил - ну запросили зарезервировать память Яве - она и система сделали, но память виртуальная и пока что ни на что не влияет.

Leonid KudryavtsevSiemarglчто надо пояснять свою мысль.

У меня она была проста - компилятор в памяти => несколько сотен Мб.

Хотелось бы видеть откуда взялась цифра "несколько сотен"

По ощущениям, там даже несколько десятками не пахнет. Накладные расходы по памяти для Java 1.6 были порядка 32 Mb под скомпилированный код (можно уменьшить или увеличить). Сколько занимает собственно код самого компилятора, не знаю. Но сомневаюсь, что это больше десятка - двух десятков мегабайт. Т.е. на мой взгляд, накладные расходы и до 100 Mb не дотягивают.
Несколько сотен - до 400Мб можно наблюдать при компиляции чего то большого С++ что gcc, что clang.
Поскольку уровень оптимизации в Яве сравним - то можно предположить, что и затраты на компиляцию будут сравнимыми - язык конечно проще, но не сильно.

"По ощущениям" - метрика конечно еще та, но:
- поковыряв доступными системными инструментами Rammap/vmmap, я конкретики тоже не увидел.
- Helloword должен загрузить как минимум интерпретатор - но он потребляет 12Мб

С этой стороны непонятно, куда используется память.

Еще погуглил на тему Java Mission Control - нашел кое что интересное
-

Basil A. Sidorov...Утверждать, что компилятор промежуточного представления в машинный код (бэкэнд) требует столько же ресурсов, что и "полный фарш" (фрон и бэк) - так же странно, как и предполагать, что, после загрузки с диска, мегабайты машинного кода раздуются до сотен мегабайт.Да, с первым утверждением я согласен (недодумал) - фронтенд С++ должен потреблять львиную долю ресурсов.

Со вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно.

Basil A. Sidorov..Далее, на моём скриншоте можно увидеть, что "нативный" браузер, загрузив одну страничку требует вдвое больше памяти, чем "ява-пюре" текстовый редактор с вполне приличным функционалом.
У кого как, но лично у меня возникает вопрос - если вполне простая задача обработки данных (отображение несложной HTML страницы веб-сервера) требует сотен мегабайт памяти для данных , то какая разница - сколько экономит нативный код, если объективный пользователь это разницу не сможет даже измерить. Я уж молчу о "почувствовать"?
Нахрена нужен это крестовый поход за "натуральный продукт" и против "богомерзких промежуточных представлений"?Давайте сравнивать огурцы таки с огурцами -
Jedit vs Notepad++
потребляет в 3.5 раза больше памяти и ввода-вывода при загрузке, и стартует (в виртуалке - а скоро все там будем) 5.4 сек против 1.5 сек
Вполне себе можно прочувствовать и измерить. Кажется уже обсуждали.

Basil A. Sidorov..
Накойхер было поднимать безоглядный киеш?А это и не кипешь - это собственно положительная реакция на нововведение. Вот скоро выйдет Java9, померяем и сравним - стало ли лучше и насколько.

ИзопропилSiemargl5.4 сек против 1.5 сек
твоя работа в постоянном перезапуске приложения заключается?

Не вздумай работать с приложениями AutodeskЭто да, мне иногда нужно просмотреть сотню-другую dwg-файлов. Чтобы не тр-ься с DЦП TrueView, я просто говорю - присылайте сразу в pdf

maytonSiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно.
Нет. Не превращаются. Ну.... не все 52Мб. Если вы запустите java -verbose:class то увидите спул работы Classloaders.
Грузится не весь rt.jar а только те classes которые есть в зависимостях.

Кстати этот аспект повлиял на введение модулей в Java9.Ок, но это приличная разница между п- и машкодом
-распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и
-загрузить 4кб по нужному смещению из dll

предков еще можно выбрать по имени каталога, которое совпадает с иерархией классов, но вот перекрестные зависимости.....

Leonid Kudryavtsev,

https://blogs.oracle.com/poonam/why-do-i-get-message-codecache-is-full-compiler-has-been-disabled
Немного не впечатляет