LINUX.ORG.RU

Java SE 6 Performance White Paper


0

0

Представлен сравнительный обзор показателей производительности и улучшений в масштабируемости Java стандартной версии 6 (Update 2) в сравнении с предыдущей версией платформы Java 5.0.

Java SE 6 включает несколько новых функций и усовершенствований для повышения производительности во многих частях платформы. Улучшения включают:

  • синхронизованные оптимизации выполнения, оптимизации производительности компилятора;
  • новый параллельный уплотняющий сборщик мусора (Parallel Compaction Collector);
  • более эргономичный параллельный низколатентный сборщик мусора (Concurrent Low Pause Collector);
  • ускорение запуска приложений.
Сравнение современной версии Java SE 6 Update 2 ведётся с предыдущей версией платформы -- Java SE 5 FCS.
Так, например, производительность операций ввода-вывода Java 6 в два раза выше, чем у Java 5.0; производительность корпоративных систем по тесту SPECjbb2005 Benchmark возросла на 70%; производительность Java в популярном тесте VolanoMark Benchmark выросла более чем на 40%; скорость запуска приложений увеличилась на 15-20%.

Также приводятся ссылки на материалы, посвящённые отдельным оптимизациям и тестам. В частности, интерес представляет отимизация сборки мусора и уменьшения потребления памяти в отдельной статье "Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning":
http://java.sun.com/javase/technologi...

Другие ссылки приведены по ходу обзора и в его конце.

>>> Подробности

Ответ на: комментарий от ero-sennin

>Ты троллишь или серьёзно? Ради этого выигрыша всё и затевается.

Мне этот выигрышь не нужен. Тем более ценой такого геморрая.

anonymous
()
Ответ на: комментарий от anonymous

> Мне этот выигрышь не нужен. Тем более ценой такого геморрая.

Тогда я разрешаю тебе и дальше пользоваться тормозной явой и больше здесь не флудить.

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

Ты пишешь на двач. Это доказано.

anonymous
()
Ответ на: комментарий от Bohtvaroh

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

Syncro ★★★★★
()

не плохую они систему там заюзали
>his test was conducted on a Sun Fire V890 with 24 x 1.5 GHz UltraSparc CPU's and 64 GB RAM running Solaris 10

ilnurathome
()
Ответ на: комментарий от xTERM

2 xTERM:
Относительно предкомпиляции явы:
Есть такое понятие, как byte-code-enginering. Это когда классы
генерируются самой программой при запуске (например на основе
каких-нибудь внешних конфигов). Прокэшировать данный момент нет
никакой возможности. При этом данная возможность используется очень
многими библиотеками. Да и в принципе вопрос запуска приложения не
настолько актуален, чтобы ради него вносить в архитектуру
дополнительные огранишения. Хотя конечно, для рядового
пользователя - это не очень удобно, но не критично.

Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с
512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы
даннных и апп сервер, то памяти таки докинул. Не знаю как у вас на
более сильных машинах Eclipse тормозит, явно какие-то глюки в системе.

alebu
()
Ответ на: комментарий от xTERM

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

ilnurathome
()
Ответ на: комментарий от anonymous

> построенная на Java EE (tomcat, lucene и тп) А ну тогда все понятно... Мой совет, остается тем же - смотри что используется и надо ли тебе это. Если надо то не хрен ныть, а если не надо то не хрен запускать... Блин толпа красноглазиков пхпэшников научилась качать непонятно что, непонятно откуда, не зная нужно ли им это вообще, щас посмотрим что такое Zimbra... а ну все понятно. Посмотри ради интереса что такое lucene, сразу станет понятно почему тормоза и откуда гиг оперативки. Если не секрет какой объем данных индексируется? Когда строится индекс? Потому что просто веб морда, так тормозить и жрать столько памяти не может, а вот если к ней прикрутить (причем тупо гвоздями к веб контейнеру) поисковый движок, да запустить это на нескольких гигах (для почтовый базы вариант очень реальный) - тогда ясен болт тормоза будут и память будет потребляться.

anonymous
()

Кстати они механизм шаренных библиотек допилили до нормального уровня, что бы несколько jvm не грузили в память дубликаты либ?

ilnurathome
()
Ответ на: комментарий от Bohtvaroh

>Неправда, с математической точки зрения, время выполнения задачи будет стремиться к нулю. ;-)

В смысле жаба будет сегфолтится, не дойдя даже до начала выполнения задачи? :)

anonymous
()
Ответ на: комментарий от anonymous

>в тех задачах где используются сеть/БД жаба уже ничем не устапает по скорости тем же дельфям

Удивил. Нехватало еще, чтобы бутылочным горлышком в сетевом приложении была не сеть, а жаба О_о

anonymous
()
Ответ на: комментарий от anonymous

>Удивил. Нехватало еще, чтобы бутылочным горлышком в сетевом приложении была не сеть, а жаба О_о

А таких приложений большинство

anonymous
()
Ответ на: комментарий от xTERM

>Во-во. Почему нельзя один раз при инсталляции скомпилировать все свои библиотеки классов? Почему нельзя сохранить скомпилированную из байткода программу? Когда наконец это все будет??? Даже в Parrot это возможно!

Вполне можно. http://www.excelsior-usa.com/jet.html Платите деньги и пользуйтесь. Или пишите самостоятельно - тем более, что код JVM давно уже в OpenSource.

anonymous
()
Ответ на: комментарий от xTERM

>Почему нельзя один раз при инсталляции скомпилировать все свои библиотеки классов? Почему нельзя сохранить скомпилированную из байткода программу? Когда наконец это все будет???

>Почему нельзя откомпилить при установке или при первом запуске и положить результат куда-нибудь в /var/cache?

Нечего вам делать в индустрии информационных технологий с таким пониманием. Потому что заранее нельзя знать, с какой машины загрузятся тебе бинари, с Power4, с OS/400, с Itanium или с x86. Соответственно компилироваться они должны уже на целевой target машине. Не забывайте, что одной из возможностей Java и преимуществ перед Windows является безопасное исполнение загруженного по сети кода в браузере, в апплете. Посмотрите www.danilla777.narod.ru. Сколько секунд у вас займет вычисление 5000х5000 матрицы? Предупреждение: будет сьедено >768Mb памяти

>Возьмем Zimbra. Что такое Zimbra? Это - postfix+cyrus+openldap+mysql+fetchmail+spamassassin+dspam+clamav.

Осталось только сравнить безопасность/безглючность mysql vs J2EE. И подумать, а может быть mysql спрятали специально за J2EE, иначе пришлось бы навешивать на продукт сторонний антивирус/файерволл?

anonymous
()
Ответ на: комментарий от anonymous

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

ilnurathome
()
Ответ на: комментарий от anonymous

Скачал BEA jRockit JRE 6 Update 2 )))

Бенчмарки в инете впечатляют. По ходу дела он-то как раз и выполняет то, о чем мы здесь флеймим: кеширует. Жаль у меня только jEdit, разницы не почувствовал.

xTERM ★★
()
Ответ на: комментарий от anonymous

> Посмотрите www.danilla777.narod.ru. Сколько секунд у вас займет вычисление 5000х5000 матрицы? Предупреждение: будет сьедено >768Mb памяти

Посмотрел.

Машинка: Core Duo T7200 (2 ГГц), память 2 ГБ. Апплет отсчитал 1000х1000 за 20 секунд, заняв 147 МБ памяти вместе с обозревателем (эта цифра, похоже, не зависит от размера матрицы). Степень загрузки процессора обозревателем, явой и т.п. -- менее 1% (не зависит от размера матрицы). 5000х5000 не дождался (должно было быть около 10 минут, вышло существенно больше), но объем занятой памяти и загрузка процессора апплетом все равно очень низкие.

Такое впечатление, что проблема со скоростью переключения контекстов задач интеловским процессором. Это не есть проблема явы. Думаю, на АМД будет более благоприятная картина.

anonymous
()
Ответ на: комментарий от ero-sennin

> Почему нельзя откомпилить при установке или при первом запуске и положить результат куда-нибудь в /var/cache?

А смысл?

Могу судить по опыту работы в оффтопичном дот-нете. Для нашего приложения испытывал два варианта инсталяции: (1) с предварительной компиляцией в бинарник (ngen); (2) без предварительной компиляции (just-in-time).

Хотя остановился-таки на первом варианте, разницы большой не заметил. Официальная дока (MSDN) говорит, что предварительная компиляция в бинарник лишь помогает уменьшить время стартапа, но само приложение при этом может потерять в скорости во время исполнения, поскольку JIT компилятор может динамически оптимизировать код, а статический компилятор - нет.

К тому же, в единицу времени далеко не все части кода используются. Даже во время одного запуска. Это справедливо для больших приложений. Еще один плюс в пользу JIT.

Думаю, что ситуация в Java совершенно аналогична. JIT - очень эффективная технология.

dave ★★★★★
()
Ответ на: комментарий от ilnurathome

>> Соответственно компилироваться они должны уже на целевой машине.

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

...А в кэше скомпилированный код, лежащий на диске, может быть изменен вредоносной программой, следовательно, надо вводить механизм контроля за сохранностью кэша... Короче говоря, получаем в результате дотнет+TPM, что НИЧУТЬ не быстрее. Ей-Богу, в Сане спецы не хуже (мягко говоря) микрософтовских, и вариант предварительной компиляции с кэшированием был рассмотрен и ранее -- и отброшен. Микрософт подобрал и пытается допиливать, попутно пропихивая негодную модель "безопасности" на основе довереннной платформы (Виста + Симбиан 90). В результате получается так же медленно, в разы более громоздко и с кучей дыр.

anonymous
()
Ответ на: комментарий от xTERM

>хм. У меня Eclipse на FreeBSD c 1 Гб оперативы и старым Athlon XP 2000+ летает даже на _пятой_ яве. Шестую не пробовал.

Советую попробовать.Java SE 6 Update 3 уже в Коллекции портов: ports/java/jdk16

У меня FreeBSD 6.3-PRERELEASE.

Для сборки JDK 1.6 требуется Diablo-JDK15. Сам комплект Diablo по большей частью в бинарных архивах. Сборка Diablo-JDK много времени не займёт, если используется в системе движок Gecko, который указан в /etc/make.conf, иначе придётся ждать сборки Мозиллы :)

Далее есть нюанс такой, что после инсталляции JDK 1.6 по умолчанию в системе будет использоваться Diablo-JDK/JRE -- Java 5.0 вообще используется для сборки и работы многих полунативных приложений, включая Eclipse и OpenOffice. Так что для гарантированного запуска Java-приложений под JDK/JRE 1.6 необходимо и достаточно переименовать каталог /usr/local/diablo-jdk-1.5.0. Запустить в командной строке: >java -version, чтобы удостоверится, что доступна версия 1.6.0.

Насчёт Eclipse скажу, что она у меня не заработала с JDK 1.6. Но NetBeans 5.5.1, распакованная из архива в домашний каталог (не из портов), запустилась и работает стабильно. Другие java-приложения заметно проворны и быстры, по быстродействию GUI практически неотличимы от нативных Gtk-приложений.

iZEN ★★★★★
() автор топика
Ответ на: комментарий от ilnurathome

> Кстати они механизм шаренных библиотек допилили до нормального уровня, что бы несколько jvm не грузили в память дубликаты либ?

У шаренных библиотек есть минуc - нужно все равно расшаривать статические объекты этих библиотек между разными jvm. Поэтому усложняется доступ к этим статическим объектам. Отсюда падает производительность таких шаренных библиотек.

Чудес не бывает, а в Сан работают очень неглупые люди.

dave ★★★★★
()
Ответ на: комментарий от iZEN

>по быстродействию GUI практически неотличимы от нативных Gtk->приложений. Ммм... не знаю-не знаю... у меня еклипс работает _заметно_ медленней, особенно редактор - а он собсно основное что мне нужно. на сколько то содержательных файлах он заметно тормозит(на _порядок_ тормознее виндового эклпса) при чём сумневаюсь, что это проблема гтк...

theos ★★★
()
Ответ на: комментарий от theos

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

А что за JRE? Надеюсь не gij...

anonymous
()
Ответ на: комментарий от dave

> У шаренных библиотек есть минуc - нужно все равно расшаривать статические объекты этих библиотек между разными jvm

Это что, какие-то специфично Явовские разделяемые библиотеки? o_O

tailgunner ★★★★★
()

Неудивительно, что мнение о тормознутости явы в народе ходит. При таком приросте производительности. :)

grustnoe ★★
()
Ответ на: комментарий от tailgunner

>Это что, какие-то специфично Явовские разделяемые библиотеки? o_O

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

anonymous
()
Ответ на: комментарий от anonymous

> уникален рамках одной JVM.

> Вот статический контекст при шареных библиотек придется разделять

Если он уникален только в рамках JVM - разделять между кем?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> У шаренных библиотек есть минуc - нужно все равно расшаривать статические объекты этих библиотек между разными jvm

> Это что, какие-то специфично Явовские разделяемые библиотеки? o_O

Наш товарищ ilnurathome хотел, "что бы несколько jvm не грузили в память дубликаты либ". Кажется, что-то такое давно замутили эппловцы в своей реализации JDK. Но как я уже писал, у подобного подхода есть свои минусы.

dave ★★★★★
()
Ответ на: комментарий от anonymous

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

Госпадиии, man classloader!

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

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

anonymous
()
Ответ на: комментарий от tailgunner

> Если он уникален только в рамках JVM - разделять между кем?

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

В случае оффтопика все сложнее. Там есть домены. И разные домены могут разделять одни и те же библиотеки (только подписанные). Наверное, на примере дотнета объяснить это было бы проще (все же он более низко-уровневый, чем Java). Но ведь ты не знаком с этой штукой?

dave ★★★★★
()
Ответ на: комментарий от anonymous

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

Честно говоря, я ничего не понял, но мысль разовью :) Например, в томкате или другом web-контэйнере для каждого web-приложения свой класслоадер, который при этом по поведению отличается от общепринятой модели делегирования класслоадеров в java. То есть библиотека в WEB-INF/lib перекрывает соответствующую библиотеку в server/lib. Слишком примитивно подходишь к вопросу.

Bohtvaroh ★★★★
()
Ответ на: комментарий от dave

>> Если он уникален только в рамках JVM - разделять между кем?

> Представь, что есть некий участок памяти, разделяемый между всеми JVM

Уфф. Так эти данные уникальны только в рамках одной JVM или среди всех запущенных JVM?

> Туда и грузятся эти шаренные библиотеки

То есть это библиотеки Ява-классов, а не нормальные shared libraries операционной системы?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>То есть это библиотеки Ява-классов, а не нормальные shared libraries операционной системы?

Нет что вы - это библиотеки PHP...

anonymous
()
Ответ на: комментарий от anonymous

>Нет что вы - это библиотеки PHP...

Ананимусы жгут

anonymous
()
Ответ на: комментарий от iZEN

Попробовал NetBeans 6 на BEA jRockit... С учетом того, что это самая тормознутая прога из всех которые я нашел, то она все-таки подтормаживала. Но такого кошмара как раньше нету.

xTERM ★★
()
Ответ на: комментарий от xTERM

> Попробовал NetBeans 6 на BEA jRockit... С учетом того, что это самая тормознутая прога из всех которые я нашел, то она все-таки подтормаживала. Но такого кошмара как раньше нету.

Вахъ, а eclipse? :)

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

Правильно, но ведь есть и корневой класслоадер, который в случае разделения библиотек между несколькими JVM должен быть общим, а теперь скажи чей статический контекст он должен держать? Значит нужно хранить пул статических контекстов, для каждого процесса - свой контекст.

anonymous
()

а может не надо кучу сборщиков мусора? МОЖЕТ ПРОСТО НЕ МУСОРИТЬ??? потрясающая манера - цеплять себе гири на йайтса.....

>Нечего вам делать в индустрии информационных технологий с таким >пониманием. Потому что заранее нельзя знать, с какой машины загрузятся >тебе бинари, с Power4, с OS/400, с Itanium или с x86. Соответственно >компилироваться они должны уже на целевой target машине. Не забывайте, >что одной из возможностей Java и преимуществ перед Windows является >безопасное исполнение загруженного по сети кода в браузере, в апплете.

убей себя об стену. ftp://ftp.sap.com/pub/sapgui/java/710 даже сап не осилил с разных блядь машын загрузку. кто захочет супротив булькнуть - читать про вебклиента с загрузкой апплетов. молчал бы. пыонэры запаланили планету(С)не помню

божэ, как страшно жыть. пипл на лоре похожэ тотально отупел.

anonymous
()
Ответ на: комментарий от xTERM

>С учетом того, что это самая тормознутая прога из всех которые я нашел, то она все-таки подтормаживала. Но такого кошмара как раньше нету.

Однако все равно жаба медленнее Си на операциях с массивами http://www.sql.ru/forum/actualthread.aspx?tid=495453

anonymous
()
Ответ на: комментарий от anonymous

> Правильно, но ведь есть и корневой класслоадер, который в случае разделения библиотек между несколькими JVM должен быть общим, а теперь скажи чей статический контекст он должен держать? Значит нужно хранить пул статических контекстов, для каждого процесса - свой контекст.

А что понимается под корневым класслоадером? Bootstrap classloader? Тогда я не вижу, что он может разделять? Базовые библиотеки? Тогда одна jre начинает зависеть от другой, и при падении одной упадёт вторая.

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

Это сигнал к восстанию! Воодушевленные ананимусы схватили палки и идут громить яву!!

xTERM ★★
()
Ответ на: комментарий от anonymous

> божэ, как страшно жыть. пипл на лоре похожэ тотально отупел.

Мальчик, перестань прогуливать русский в школе. ;-)

Bohtvaroh ★★★★
()
Ответ на: комментарий от tailgunner

> Уфф. Так эти данные уникальны только в рамках одной JVM или среди всех запущенных JVM?

Чую, что подходим к главному. Данные уникальны, а управляющий ими код - общий. Поэтому нужно учитывать текущий контекст (то есть текущую jvm) исполнения при обращении к этим шаренным (статическим) данным из общего кода. Грубо говоря, нужна дополнительно одна или несколько косвенных адресаций, которые не нужны были бы в случае монопольного владения библиотекой всего одной jvm. Андерстенд?

В случае Java все это не более, чем детали возможной (!) реализации. То есть, можно обойтись без всего этого. А вот бедным моновцам пришлось это все реализовывать, поскольку это явно определено в разделе .NET application domains.

dave ★★★★★
()
Ответ на: комментарий от anonymous

>У меня два гига рамы + кор два дуо, с четырьмя метрами кеша. Жаба тормозит, следовательно жаба - говно

У меня гиг рамы + Celeron-1700. Java не тормозит. Следовательно - у тебя руки из чего-то того, о чём ты говоришь :D

KRoN73 ★★★★★
()
Ответ на: комментарий от Bohtvaroh

> Тогда одна jre начинает зависеть от другой, и при падении одной упадёт вторая.

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

dave ★★★★★
()
Ответ на: комментарий от anonymous

>> Я мерял время "теплого старта", естественно - и Eclipse, и Java должны были быть уже в памяти.

> А время на JIT компиляцию ты учел? Может он все это время перегонял байт код в инструкции проца?

а дорогой форк - это неизлечимая жопа любых ненативных языков

gaa ★★
()
Ответ на: комментарий от xTERM

> Почему нельзя один раз при инсталляции скомпилировать все свои библиотеки классов? Почему нельзя сохранить скомпилированную из байткода программу?

java-based gentoo? ;)

gaa ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.