Java 8: от PermGen к MetaSpace

[@barker]

Ну ооочень странно оформлен перевод. Половина статьи и та в третьем лице как-то.

[@1nd1go]

А куда будет писаться пул стрингов и оберток?

[@xnike]

Согласно Java SE 7 Features and Enhancements пул стрингов уже сейчас хранится в хипе для JDK 7, а не в пермгене:

Area: HotSpot
Synopsis: In JDK 7, interned strings are no longer allocated in the permanent generation of the Java heap, but are instead allocated in the main part of the Java heap (known as the young and old generations), along with the other objects created by the application...

[@eReS]

Для Android это актуально. Часто кучи не хватает, приходиться писать нативные либы… Скорее бы!

[@Sauron]

Нет, для Android это не актуально ибо там не Оракловская JVM а Dalvik.

[@eReS]

Не думаю что Google это себе не перетащит. Собирается все же OpenJDK/OracleJDK

[@eReS]

Мне нравиться хабр, одно минусануло и понеслось… И в карму гадят, не стесняются. Раньше такого не было.

[@SSiarhei]

А что вы собственно хотели?

> Для Android это актуально.
Совершенно нет, уже пояснили почему.

>Часто кучи не хватает
Почитай иди что такое куча, что такое PermGen, а потом жалуйся что минусуют.

[@qxfusion]

у Android его Google Dalvik кардинально отличается по своему устройству от Oracle/IBM JVM — собственно поэтому на ней и нельзя запустить обычный jar без компиляции в DEX

[@Sauron]

В Dalvik нет такой штуки как PermGen в Оракловском HotSpot. Там есть Zygote, но он работает не так как PermGen, соответственно те модификации PermGen, которые Оракл планирует произвести в HotSpot, для Dalvik не релевантны. Фактически эти изменения не релевантны ни для одной имплементации JVM кроме HotSpot — ни IBM JVM, ни JRockit (на основе которого Оракл, собственно, и вносит эти изменения) не имеют PermGen.

[@Sauron]

P.S.
> Фактически эти изменения не релевантны ни для одной имплементации JVM кроме HotSpot
Хм, нужно уточнить — ни для одной популярной JVM (в которые я включаю HotSpot, JRockit, IBM JVM и Azul Zing — которая, насколько мне известно, PermGen не имеет — поправьте если не прав).
Есть JVM вроде HP-UX JVM, в которых PermGen передран с HotSpot, но вряд-ли многим прийдётся с такими сталкиваться.

[@GreyCat]

Оно вроде умерло лет 7-8 назад, не? Даже на 1.5 не перетаскивали (если даже не на 1.4), вроде…

[@Sauron]

Да вроде как живое — h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXJAVAHOME
Но даже если б померло уже, суть в том что есть много малоизвестных JVM, и я за все не могу сказать, есть там permanent generation или нет, и ограничен ли размер permgen по умолчанию.

[@GreyCat]

Ух ты %) Оно даже теперь живое как комплект патчей на Hotspot — т.е. фактически ее отдельной JVM считать теперь и не стоит. А насчет совсем отдельных — полностью согласен.

[@u_story]

Т.е. мы больше никогда не увидим надпись: «java.lang.OutOfMemoryError: PermGen space»? :(((

[@Sauron]

Не беда, его заменит «java.lang.OutOfMemoryError: Metadata space» (-;

[@Akvel]

Интересно как будет работать tomcat на 1.8 с его давней нелюбовью выгружать классы (без танцев с бубном)

[@antonarhipov]

Выгрузкой классов сервер не занимается. Если Tomcat «не выгружает» класс то в этом виновато ваше же приложение, и ваш же код (или библиотеки)

[@Akvel]

Вы хотите со мной поспорить или просто хотели что-нибуть написать в теме? :-)

[@Apx]

Что то я не понимаю. Весь профит который мы теперь будем получать это только то, что теперь не надо передавать аргумент в jvm и другое сообщение в стектрейсе? Ну клёво, только зачем? Разве кто то когда то запрещал указать размер пермгена размером с нативный?)

[@Sauron]

Вот потому я свои выводы и дописывал (-:

Запрещать то оно никто не запрещает, но это уже не обязательно, что делает жизнь сильно проще и для программера, запускающего билд скрипт локально, и тем более для конечного пользователя, запускающего на своей машине десктопное приложение на Java.

Если от программера еще можно требовать, чтоб он указывал при каждом запуске JVM XX:MaxPermSize=<кол-во оперативы>, то от конечного пользователя требовать такое — жестоко.

[@Apx]

С другой стороны десктопное приложение на java для end user'a которое просто съедает всю его память, это тоже пикантно и необычно) Я бы например обо****я если бы мои 16 гигов дома занял какой то процесс декстопного приложения на жабе)

[@Sauron]

Ну зачем же так сразу всю память — просто переваливает за MaxPermSize, возможно кратковременно.

[@dime]

Преимуществ минимум два.

Первое очевидное — таки не нужно писать цифру в параметр и вообще оно может динамически расти.

Второе ещё круче — оно может не только динамически расти, но ещё и динамически уменьшаться. Что упрощает работу разных средств горячей замены кода, типа JRebel (они, вроде, и сами это как-то умеют, но через гланды автогеном, а тут настоящая сборка мусора)

[@Caiiiycuk]

Радует то что они мержат JRockit, в некоторых аспектах она круче. По памяти точно могу сказать что она расходует ее заметно меньше. Запуск текущей Oracle JVM отъедает порядко 300mb виртуальной памяти минимум, и на сервере с 1ГБ оперативы не удавалось запустить более 3 приложение на java, с JRockit таких ограничений нет практически отжирает ровно столько сколько прописанно в -Xmx.

[@miolini]

Класс, теперь на облачных виртуальных серверах с memory bubble можно меньше телодвижений делать. Еще смог бы jre уметь память обратно системе возвращать, было бы совсем хорошо.