JVM internals - what does the JVM do? — Ian Rogers

[rzen]

интересный ток, кому то наверное баян, прошу простить, остальным, силь ву пле:

phpBB [video]

если интересно узнать больше про Азул:

phpBB [video]

(я к ним никакого отношения не имею если что)

[Zorkus]

Спасибо, не слышал. Надо будет посмотреть.

[rzen]

сразу поискал других его токов но увы, это единственный..

[Zorkus]

Спасибо, послушаю с интересом. Этот выпуск не слышал.

[Zorkus]

Мне нравились рассказы John Rose про JVM, в блоге. https://blogs.oracle.com/jrose/

[dotcom]

Мне всегда интересовало, что Azul при всех великих обещаниях, всех этих умных людях, оставшись практически в одиночку на рынке java процессоров и ускорителей, никак не может ни родить ни продать за столько лет.

[rzen]

вроде продают они нормально. но то что иана потеряли это им конечно минус.

[dotcom]

Продукты и клиенты у них есть. Но судя по 10-му раунду финансирования, как-то не очень хорошо у них дела идут до сих пор. Кстати, о JVM. Кроме "Inside JVM 2" и спецификации, есть ли еще какие-нибудь стоящие внимания фундаментальные труды про внутренности JVM? Отдельных talk'ов много, но хотелось бы связанного и художественного.

[rzen]

Продукты и клиенты у них есть. Но судя по 10-му раунду финансирования, как-то не очень хорошо у них дела идут до сих пор. Кстати, о JVM. Кроме "Inside JVM 2" и спецификации, есть ли еще какие-нибудь стоящие внимания фундаментальные труды про внутренности JVM? Отдельных talk'ов много, но хотелось бы связанного и художественного.

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

если конечно оракл не решит проблему GC, тогда конечно им ловить будет нечего. а пока их JVM значительно лучше штатного.

[Palych]

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

если конечно оракл не решит проблему GC, тогда конечно им ловить будет нечего. а пока их JVM значительно лучше штатного.

Я извиняюсь, но почти ничего не понял.
Кто такой второй баст?
И какие проблемы у оракла с GC?
Какой JVM считается штатным, а какой - лучшим?

[rzen]

у штатной JVM проблема в том, что на время GC жизнь VM останавливается. и чем больше памяти тем дольше это может занимать. конечно есть способы минимизировать эти зависоны, но полностью от них избавиться средствами штатной оракловской JVM (т.н. "HotSpot") не представляется возможным.

второй баст это я так любя назвал айтишный бубль 2000-01го года. как раз в тот период джава начала стагнировать и я, признаться, снял руку с пульса, поскольку был убеждён что джава заканчивается. соответственно жирных клиентов азулу наверное было сложновато найти. когда стало ясно что в лагере джавы зашевелилась жизнь, когда объявили а потом выпустили семёрку, уровень оптимизма повысился, область применения джавы расширилась, думаю нужда в конкурентной сборке мусора для некоторых задач весьма актуальна. что скорее всего положительно скажется на азуле. вполне возможно что они банально надеются что их купит оракл.

[Zorkus]

Я верю сейчас даже в яву не как язык, а как в рантайм-платформу для других языков. Scala, Groovy, Clojure, Jython, JRuby, Rhino и прочее.

Как я смотрю, у HotSpot все коллекторы кроме CMS (concurrent mark sweep, и то пока он может работать с достаточным количеством памяти и дефрагментация кучи не требуется) требуют достаточно больших stop the world pauses, а в CMS так и не смогли полностью побороть фрагментацию. Надо посмотреть как в JRockit сделано.

[rzen]

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

[Flash-04]

у штатной JVM проблема в том, что на время GC жизнь VM останавливается. и чем больше памяти тем дольше это может занимать. конечно есть способы минимизировать эти зависоны, но полностью от них избавиться средствами штатной оракловской JVM (т.н. "HotSpot") не представляется возможным.

в соседней теме мне с пеной у рта доказывали что это не так

[rzen]

у штатной JVM проблема в том, что на время GC жизнь VM останавливается. и чем больше памяти тем дольше это может занимать. конечно есть способы минимизировать эти зависоны, но полностью от них избавиться средствами штатной оракловской JVM (т.н. "HotSpot") не представляется возможным.

в соседней теме мне с пеной у рта доказывали что это не так

не видел тот тред, возможно люди имели ввиду альтернативный JVM? тогда возможно.

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

кстати в токе эта тема замечательно раскрыта.

[Flash-04]

вот, пожалуйста:

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

http://forum.privet.com/viewtopic.php?f ... 0&start=75

[rzen]

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

но я не стану в ту разборку лезть, там поопытнее меня жависты уже отметились.

[Flash-04]

не предусмотрено проксирование чтения объектов в процессе их перемещения в памяти в процессе сборки/дефрагментации

что интересно, в Win16 это было, но потомы было выброшено.

[valchkou]

картинка взята из белых бумаг от сана
http://java.sun.com/j2se/reference/whit ... epaper.pdf
согласно ей паузу можно значительно уменьшить, но не сосвсем убрать.
дока относится к java 5, но ничего новее я так и не видел.
Если у кого есть update дайте почитать.

[Palych]

вот, пожалуйста:

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

http://forum.privet.com/viewtopic.php?f ... 0&start=75

Раз уж меня процитировали - поясню: полностью избавиться от full GC на сильно нагруженых системах мне лично не удавалось, но уменьшить частоту до пары раз в неделю получалось...

[Flash-04]

правда?! но как Холмс?
я в "своем" приложении вижу GC каждые несколько минут...
кстати, а такая задержка GC не приведет к резкому росту аллокированной памяти?

[Zorkus]

вот, пожалуйста:

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

http://forum.privet.com/viewtopic.php?f ... 0&start=75

Раз уж меня процитировали - поясню: полностью избавиться от full GC на сильно нагруженых системах мне лично не удавалось, но уменьшить частоту до пары раз в неделю получалось...

Это на Hotspot, какой версии? Стандалон приложение, или внутри appserver-a? В каком generation, каким сборщиком? Что-то прям очень уж хорошо. Полностью избавиться от FullGC нельзя постольку, поскольку нельзя вся объекты делать такими короткоживущими, чтобы они прибирались короткими сборками в young gen.

Хотя по логике..Если это не EJB сервер, а простая standalone числодробилка, все крупные долгие объекты выделил раз и навсегда, а в процессе работы создаются в больщих количествах только всякие локальные промежуточные матрицы и коллекции, которые живут очень мало - тогда наверное можно, но все равно слабо верится.

[rzen]

standalone числодробилке паузы сборщика волнуют меньше всего. это как раз в приложениях в которых нужна интерактивность (с юзером или другими системами) асинхронные паузы сбивают с толку.

[Zorkus]

standalone числодробилке паузы сборщика волнуют меньше всего. это как раз в приложениях в которых нужна интерактивность (с юзером или другими системами) асинхронные паузы сбивают с толку.

Я числодробилку привел как пример,где эти паузы можно уменьшить (по крайней мере я вижу как). Я не думаю, что юзер может заметить latency какое-то из за GC. В подавляющем числе задач (для Java) нужен общий thoughtput, а не гарантированный отклик (кроме бирж, может еще некоторых видов биллинга). Есть тут на форуме разработчики биржевого ПО?

[rzen]

standalone числодробилке паузы сборщика волнуют меньше всего. это как раз в приложениях в которых нужна интерактивность (с юзером или другими системами) асинхронные паузы сбивают с толку.

Я числодробилку привел как пример,где эти паузы можно уменьшить (по крайней мере я вижу как). Я не думаю, что юзер может заметить latency какое-то из за GC. В подавляющем числе задач (для Java) нужен общий thoughtput, а не гарантированный отклик (кроме бирж, может еще некоторых видов биллинга). Есть тут на форуме разработчики биржевого ПО?

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

биржевое ПО в частности задержек не любит. ладно обработка потока транзакций и генерация отчётов (ну задержали на полсекунды, не беда) а совсем другое задержать заявку на полсекунды, это врядли кому понравится. вот на них азуловцы и прицеливаются главным образом как я понял.