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...

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

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

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

>> "скорость запуска приложений увеличилась на 15-20%", а?

> Кроме eclipse что-нибудь сравнивал? Я бы попробовал сравнить скорость запуска, к примеру, jboss

Я к Яве вообще не имею отношения, использую только Eclipse + CDT + PyDev 8)

> когда тот будет оффициально поддерживать 6-ку.

Как сказал бы бирди, "Wow... so much for portability" ;)

> Оптимизации jre не могут оптимизировать скорость работы винта твоего ноута

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

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

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

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

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

>> когда тот будет оффициально поддерживать 6-ку.

> Как сказал бы бирди, "Wow... so much for portability" ;)

Одно дело просто работать (работает), другое - полностью использовать все новые фичи и быть рекомендованным к использованию разработчиками в боевых условиях. Так что не канает.

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

> А время на JIT компиляцию ты учел?

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

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

Может быть. Это одна из моих личных претензий к Яве - то, что она перегоняет байткод в "родной" при кадом запуске приложения в каждой JVM :D

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

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

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

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

Потому что это поставит крест на кросплатформенности. Что касается JIT, то не такое уж это больше неудобство и не такая большая плата за возможность переносить бинарники.

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

Какой крест? Я у себя буду иметь откомпилированную прогу, а распространять байткод. В чем проблема?

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

> Потому что это поставит крест на кросплатформенности. Что касается JIT, то не такое уж это больше неудобство и не такая большая плата за возможность переносить бинарники.

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

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

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

> Потому что это поставит крест на кросплатформенности

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

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

А я тебя вчера на дваче вычислил.

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

>Какой крест? Я у себя буду иметь откомпилированную прогу, а распространять байткод. В чем проблема?

Ты еще учти, что что жаба выполняется внутри управлемой среды (JVM), ее тоже надо будет включать в экзешник (разумеется в виде библиотек), кроме того опять же придется откомпилировать стандартные библиотеки. И память это штука будет жрать столько же. А все ради того чтобы у кого-то эклипс запустился на несколько секунд раньше... Лично мне JIT не мешает.

И у меня есть сильные подозрения что JIT компилит отнюдь не все, именно с этим связаны оптимизации от версии к версии.

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

> Потому что это поставит крест на кросплатформенности. Что касается JIT, то не такое уж это больше неудобство и не такая большая плата за возможность переносить бинарники.
Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled
Т.е. если бы работало по аналогии с man который сначала преформатирует доки, а затем выдергивает из cache

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

> И память это штука будет жрать столько же

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

> А все ради того чтобы у кого-то эклипс запустился на несколько секунд раньше...

Не у кого-то, а у всех. И не только Эклипс.

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

>Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled Т.е. если бы работало по аналогии с man который сначала преформатирует доки, а затем выдергивает из cache

Еще раз повторюсь - это не даст особого прироста и не сократит используемую память т.к. для исполняемое программы все равно придется реализовывать среду исполнения. Кроме того я не уверен что все можно закомпилить в нативный код, а потом подогнать к этому еще и JVM без костылей (Ведь должен же скомполированный экзешник как то обрабатовать например вызов System.gc из программы, причем делать он это должен так же как исполняемый внутри JVM байт код, а значит там должна быть управляемая среда...)

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

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

> а максимум что даст выигрышь в несколько секунд пре старте

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

Ты знаешь, как работает любой latex? Или pch в любом компиляторе. Вот по такому же принципу можно избавить JVM от повторения одной и той же работы при каждом запуске.

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

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

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

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

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

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

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

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

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

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

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

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

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

ilnurathome
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от anonymous

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

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

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

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

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

java-based gentoo? ;)

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

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

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

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

> Официальная дока (MSDN) говорит

не читайте с утра советских газет

> поскольку JIT компилятор может динамически оптимизировать код, а статический компилятор - нет.

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

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

какой плюс? перекомпилить при каждом запуске выйдет дороже однократного компилирования, пусть даже и не всё придётся каждый раз перекомпиливать

> JIT - очень эффективная технология.

...развода покупателей на бабки

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

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

По ссылке ходил? Там почти половина написаного относится к динамической оптимизации для JIT компилятора в случае multi-threading. Все-таки их писанина выглядит как-то авторитетнее твоей :)

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

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

> По ссылке ходил?

какой ссылке? я отвечал на вопрос, более общий чем тема новости.

> Там почти половина написаного относится к динамической оптимизации для JIT компилятора в случае multi-threading.

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

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

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

Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

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

Да и вообще, не в кеше дело. Ладно с ним. Главное, чтобы classpath от sun поставлялся прекомпилиный. Он лежит не в кеше, а там, где Ява. А байткода там дохера, и его компиляция сильно все затормаживает.

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

> тормозит и на более хорошем железе.

А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

По сравнению с нативным кодом на C - конечно.

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

>> тормозит и на более хорошем железе.

> А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

тормозит - это объективный критерий. если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

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

следовательно, эклипс _тормозит_ на хорошем железе.

> По сравнению с нативным кодом на C - конечно.

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

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

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

> Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

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

2. Помимо сохранности кода, при кэшировании скомпилированных классов придется включать еще некоторый механизм контроля версий классов (например, при входе на два разных сайта мы загрузили две разные версии сласса с одним и тем же именем...), что приводит к необходимости заводить систему типа COM, от которой убегает даже Микрософт. Именно это, насколько я понимаю, и сделано в Excelsior JET, и потому этот пакет такой дорогой.

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

> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

Если программа не умеет работать с обменом видеостраниц, то тормозит ее разработчик. (С) корпорация Майкрософт.

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

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

>> Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

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

советую посмотреть, как реализуется кеширование веб-страниц(например, глянуть кеш Вашего браузера) и понять, что версионирование в таком случае не нужно

> что приводит к необходимости заводить систему типа COM, от которой убегает даже Микрософт. Именно это, насколько я понимаю, и сделано в Excelsior JET, и потому этот пакет такой дорогой.

ком тут не нужен. потому что не нужно версионирование.

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

>А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

>По сравнению с нативным кодом на C - конечно.

Только с ним и имеет смысл сравнивать.

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

> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

Только вот программа может рисовать Hello World, а может заниматься парсингом туевой хучи файлов. И все равно вам для оценки тормозопригодности придется сравнивать с аналогами :). Да, я знаю, что emacs распарсит исходники JBOSS быстрее.

> не все явисты это понимают. а если понимают, то начинают прикрываться защищённостью, потом лёгкостью разработки

Это не защита и не прикрытие. Просто надо понимать, чем платишь и за что. Eclipse, приведенный для примера, дает разработчикам RCP - переносимую платформу, что не дает C, по крайней мере, так легко.

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

> Только с ним и имеет смысл сравнивать.

По производительности? А по переносимости будем сравнивать с bash, а по объектной модели будем сравнивать с python? А давайте наоборот - производительность сравним с python, объектную модель - с bash, а перносимость - с С?

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

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

Ты, похоже, вообще ничего о COM не знаешь. А в описанной ситуации достаточно точного хеширования.

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

>> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

> Если программа не умеет работать с обменом видеостраниц, то тормозит ее разработчик. (С) корпорация Майкрософт.

если гуёвая программа тормозит(в описанном мной смысле)[это понятие можно обобщить для любой интерактивной программы], то одного из разработчиков программы надо уволить. но мне, как конечному пользователю нет разницы, кого: разработчика программы, графического тулкита, языка программирования или компилятора/интерпретатора. я вижу, что программа тормозит и точка.

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

>> Только с ним и имеет смысл сравнивать.

>По производительности?

Да. именно по ней. Кукарекали про нативный код? Пусть отвечают за свои слова.

> А по переносимости будем сравнивать с bash, а по объектной модели будем сравнивать с python?

К чему ты это?

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

>> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

> Только вот программа может рисовать Hello World, а может заниматься парсингом туевой хучи файлов.

для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

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

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

В качестве исключения (вроде бы на форуме мы еще не сталкивались..).

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

Теперь вот какая штука. Возможно, эта информация уже устарела, но в свое время Swing (Java GUI API) был написан так, что в качестве коллекций использовался повсеместно класс Vector, чьи методы по ошибке первых проектировщиков были сделаны синхронными (это признал потом сам Гослинг).

Так вот, если JIT умеет правильно определять места, где блокировкой можно пренебречь (а Swing-код по-определению однопочный, хотя и базируется на много-поточном AWT), то это может значительно ускорить выполнение... Вот такие пироги.

Что касается быстроты откомпилированного кода на C. Он будет быстрее в случае каких-нибудь линейных вычислений. Но в случае много-поточного кода и обработки данных со сложной иерархией связка JIT + GC может оказаться быстрее. Но это уже не уровень HelloWorld приложений, а значительно выше... Если бы так было все просто...

Да, кстати, системная библиотек отчасти закеширована в java 6 update 2.

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

> Да. именно по ней. Кукарекали про нативный код? Пусть отвечают за свои слова.

А, в данном случае! В данном случае да.

> К чему ты это?

Уже ни к чему.

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

> напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

Интерактивные программы _вообще_ в java не тормозят. Тормозит конкретно Eclipse. Почему там не показывают червяка и тем более не пускают отдельный процесс (в java это делается тремя байтами) - вопрос не ко мне.

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

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

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

я с этим не спорю. но я говорил не про это.

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

> Что касается быстроты откомпилированного кода на C. Он будет быстрее в случае каких-нибудь линейных вычислений. Но в случае много-поточного кода и обработки данных со сложной иерархией связка JIT + GC может оказаться быстрее. Но это уже не уровень HelloWorld приложений, а значительно выше... Если бы так было все просто...

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

> Да, кстати, системная библиотек отчасти закеширована в java 6 update 2.

вот это хорошо.

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

> Тормозит конкретно Eclipse.

B NetBeans тоже, по крайней мере с Си++ плагином :)

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

>> напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

> Интерактивные программы _вообще_ в java не тормозят. Тормозит конкретно Eclipse.

netbeans тоже подтормаживает. других жава-приложений сходу вспомнить не могу

> Почему там не показывают червяка и тем более не пускают отдельный процесс (в java это делается тремя байтами) - вопрос не ко мне.

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

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

> советую посмотреть, как реализуется кеширование веб-страниц(например, глянуть кеш Вашего браузера) и понять, что версионирование в таком случае не нужно

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

> ком тут не нужен. потому что не нужно версионирование.

См. выше. Отсутствие версионирования ухудшает итоговое быстродействие. Вопрос в том, приемлемым образом или нет. Микрософт проделал опыт с Вистой, разрешив частичное кэширование. Получилось не очень приемлемо.

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

>Тормозит конкретно Eclipse

Согласен. Только Eclipse со своей SWT, написаной поверх нативных гуевых библиотек тормозит. Остальные же животные (NetBeans например) - ПОЛЗАЮТ!

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

>Так вот, если JIT умеет правильно определять места, где блокировкой можно пренебречь (а Swing-код по-определению однопочный, хотя и базируется на много-поточном AWT), то это может значительно ускорить выполнение... Вот такие пироги.

Да, да, на Swing это заметно ;) Он прямо летает благодаря этим пирогам.

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

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

Это имеет смысл в случае системных библиотек, а они закешированы (java 6).

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

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

Каждый судит со своей колокольни. У меня есть опыт программирования на многих языках, включая так нравившийся мне в школьные годы ассемблер PDP11 (для БК и ДВК). Были проекты, где компилированный C/C++ код был одним из лучших решений. Но мой последний проект такой, где Java или .NET решение по многим параметрам превосходит возможное C/C++/Delphi/Ada решение. В том числе с точки зрения производительности и скорости исполнения, не говоря, уже о времени разработки. Многое зависит от задачи.

Здесь я обычно люблю на ссылаться на отечественную среду моделирования AnyLogic, написанную на Java. По-моему хороший пример того, что было бы очень трудно создать на C...

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

>> netbeans тоже подтормаживает. других жава-приложений сходу вспомнить не могу

> http://www.pulpgames.net/scared/

Быстродействие на уровне машинного кода на P166MMX без ускорения трехмерной графики (ИЛИ БЫСТРЕЕ -- но вот насколько???) -- на Core 2 Duo 7200.

Примеры нехарактерные. Или компьютер слишком мощный...

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

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

> Отсутствие версионирования ухудшает итоговое быстродействие.

непонятно, откуда взято подобное утверждение

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

alebu (18.11.2007 17:49:48)> Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с 512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы даннных и апп сервер, то памяти таки докинул.

В 1998 году я запускал Borland JBuilder 1.0 и 2.0 Enterprise Edition на Pentium 133МГц и 32Мб RAM (потом добавил до 64Мб) с операционной системой WindowsNT 4.0 Workstation. И чё-то всё-таки делал в редакторе кода, писал что-то для работы с GUI и 2D-графикой. Какое-то время изучал возможности Symantec Visual Cafe -- очень прожорливая штука, потому не решился на неё перейти с JBuilder'а.

Конечно, тормоза были во всём, так как оперативной памяти было явно недостаточно, свопило всё что можно при переключении из редактора кода в визуальный дизайнер форм и обратно. Хотя WinAmp в это время проигрывал MP3 без запинок. Обе среды были написаны на C++, а Java 1.1 выступала, видимо, как движок нативных компонентов -- очень странная архитектура, созданная в расчёте на скорость, но не выдерживающая никакой критики по быстродействию. В те времена AWT было ещё не оптимизировано, так что среды на AWT были гораздо тормознее полунативных. Отдельная баблиотека Swing была ещё экспериментальной, так что мечтать о быстрой графике и GUI на Java было рано.

На соседних машинках с такой же аппаратной конфигурацией люди работали в Delphi 2.0 более-менее комфортно. Можно было гонять по 10 мегабитной сети огромные по тем временам наборы данных. Да и Java-приложения при работе с удалёнными СУБД на SQL не отличались по скорости, но вот GUI сильно тормозил, и поэтому дельфины, привыкшие к моментальной реакции интерфейса на действия офисного пользователя, воротили нос от этого "кошмара".

У меня всегда было предчувствие (не смутил даже первый запуск JBuilder'а 1.0 на Pentium 133/16Мб) что Java всё-таки будет мэйнстримом и со временем станет лучше Delphi. А те, кто занимался разработкой в Delphi, к стыду своему перестанут считать Java тормозной игрушкой. Так и вышло.

С открытием Eclipse и ускорением разработки NetBeans в 2001-2002 годах всё менялось буквально на глазах. Нативные среды разработки не обзаводились никакими преимуществами даже в плане быстрого рефакторинга, а тем временем Java увеличила производительность чуть ли не в разы с каждой новой версией java 1.2 -> 1.3 -> 1.4 ->... Теперь же Eclipse, IDEA и NetBeans фактически являются мэйнстримом средств разработки, а фавориты Delphi и VS -- вчерашний день.

Железо тоже увеличивало производительность линейно. Обычные компы уже в 2005 году стали иметь процессор с частотой от 2ГГц с внешней быстрой шиной от 1ГГц и память от 1Гб и выше. Таким образом, увеличение производительности железа и алгоритмическая оптимизация обеспечили почти квадратичное повышение производительности платформы Java, и она всё больше переставала быть "тормозной игрушкой" в руках жабофилов.

В том же году (2005г.) продолжался "Мобильный бум" и распространение J2ME-игр, но скорее всего две параллельные вселенные J2SE и J2ME никак не связаны между собой. Хотя скорость разработки игр напрямую зависела от производительности настольной версии Java и компилятора javac, а также от скорости работы эмулятора.

"Новые" интерпретирующие технологии на основе XML, SOAP и впоследствии AJAX не уничтожили Java, а придали ей большую живучесть и приспособляемость, несмотря на старания Microsoft вкупе с .Net.



gaa (18.11.2007 20:52:03)>тормозит и на более хорошем железе. а Вы своё лечение самовняшением оставьте, это в недалёком будущем может привести к аутизму

Значит я болен с 1998 года (когда у меня тогда даже компьютера своего не было). И ещё несколько миллионов разработчиков на Java заразились этой болезнью и неизлечимо больны... Прям какая-то эпидемия ходит по планете с 1995 года. ;)

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

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

>Это имеет смысл в случае системных библиотек, а они закешированы (java 6). Потом нужно понимать, что сам парсинг байт-кода - это мизерная часть обработки. Сложность JIT - в исполнении.

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

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

> Каждый судит со своей колокольни. У меня есть опыт программирования на многих языках, включая так нравившийся мне в школьные годы ассемблер PDP11 (для БК и ДВК). Были проекты, где компилированный C/C++ код был одним из лучших решений. Но мой последний проект такой, где Java или .NET решение по многим параметрам превосходит возможное C/C++/Delphi/Ada решение. В том числе с точки зрения производительности и скорости исполнения, не говоря, уже о времени разработки.

давайте сразу достанем линейки :)

> Многое зависит от задачи.

да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

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

>alebu (18.11.2007 17:49:48)> Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с 512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы даннных и апп сервер, то памяти таки докинул.

>В 1998 году я запускал Borland JBuilder 1.0 и 2.0 Enterprise Edition на Pentium 133МГц и 32Мб RAM (потом добавил до 64Мб) с операционной >системой WindowsNT 4.0 Workstation. И чё-то всё-таки делал в редакторе кода, писал что-то для работы с GUI и 2D-графикой. Какое-то время изучал возможности Symantec Visual Cafe -- очень прожорливая штука, потому не решился на неё перейти с JBuilder'а.

>Конечно, тормоза были во всём, так как оперативной памяти было явно недостаточно, свопило всё что можно при переключении из редактора кода в визуальный дизайнер форм и обратно. Хотя WinAmp в это время проигрывал MP3 без запинок. Обе среды были написаны на C++, а Java 1.1 выступала, видимо, как движок нативных компонентов -- очень странная архитектура, созданная в расчёте на скорость, но не выдерживающая никакой критики по быстродействию. В те времена AWT было ещё не оптимизировано, так что среды на AWT были гораздо тормознее полунативных. Отдельная баблиотека Swing была ещё экспериментальной, так что мечтать о быстрой графике и GUI на Java было рано.

>На соседних машинках с такой же аппаратной конфигурацией люди работали в Delphi 2.0 более-менее комфортно. Можно было гонять по 10 мегабитной сети огромные по тем временам наборы данных. Да и Java-приложения при работе с удалёнными СУБД на SQL не отличались по скорости, но вот GUI сильно тормозил, и поэтому дельфины, привыкшие к моментальной реакции интерфейса на действия офисного пользователя, воротили нос от этого "кошмара".

>У меня всегда было предчувствие (не смутил даже первый запуск JBuilder'а 1.0 на Pentium 133/16Мб) что Java всё-таки будет мэйнстримом и со временем станет лучше Delphi. А те, кто занимался разработкой в Delphi, к стыду своему перестанут считать Java тормозной игрушкой. Так и вышло.

>С открытием Eclipse и ускорением разработки NetBeans в 2001-2002 годах всё менялось буквально на глазах. Нативные среды разработки не обзаводились никакими преимуществами даже в плане быстрого рефакторинга, а тем временем Java увеличила производительность чуть ли не в разы с каждой новой версией java 1.2 -> 1.3 -> 1.4 ->... Теперь же Eclipse, IDEA и NetBeans фактически являются мэйнстримом средств разработки, а фавориты Delphi и VS -- вчерашний день.

>Железо тоже увеличивало производительность линейно. Обычные компы уже в 2005 году стали иметь процессор с частотой от 2ГГц с внешней быстрой шиной от 1ГГц и память от 1Гб и выше. Таким образом, увеличение производительности железа и алгоритмическая оптимизация обеспечили почти квадратичное повышение производительности платформы Java, и она всё больше переставала быть "тормозной игрушкой" в руках жабофилов.

>В том же году (2005г.) продолжался "Мобильный бум" и распространение J2ME-игр, но скорее всего две параллельные вселенные J2SE и J2ME никак не связаны между собой. Хотя скорость разработки игр напрямую зависела от производительности настольной версии Java и компилятора javac, а также от скорости работы эмулятора.

>"Новые" интерпретирующие технологии на основе XML, SOAP и впоследствии AJAX не уничтожили Java, а придали ей большую живучесть и приспособляемость, несмотря на старания Microsoft вкупе с .Net.

>gaa (18.11.2007 20:52:03)>тормозит и на более хорошем железе. а Вы своё лечение самовняшением оставьте, это в недалёком будущем может привести к аутизму

>Значит я болен с 1998 года (когда у меня тогда даже компьютера своего не было). И ещё несколько миллионов разработчиков на Java заразились этой болезнью и неизлечимо больны... Прям какая-то эпидемия ходит по планете с 1995 года. ;)

неплохо сказано ;)

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

>для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

То есть когда ты в Vim|Emacs|VisualStudio нажимаешь "Run", у тебя среда компилирует проект и запускает его менее чем за 1/25секунды? Круто. Ничего что у меня в Eclipse я жду немножко дольше? А, кстати, когда ты нажимаешь "Поместить" на странице http://www.linux.org.ru/view-message.jsp?msgid=2278155 понимаешь ли ты, что тормозит не сама Java, которая обрабатывает твое нажатие, а твое сообщение еще успевает поместиться в базу и уже потом Java отдает тебе страницу с твоим ответом?

Кстати, когда maxcom поставит на LOR Java 6.0 update 3? Хотелось бы посмотреть, как форум залетает

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

> Да, да, на Swing это заметно ;) Он прямо летает благодаря этим пирогам.

Юмор оценил :)

А теперь серьезно. Те же операции с графикой отнимают куда больше времени, чем соблюдение синхронности Vector. И правильное использование ClipRectangle занимает куда более важное место.

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

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

Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

> да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

Но у меня нет такого ощущения, по крайней мере, ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

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

> Кстати, когда maxcom поставит на LOR Java 6.0 update 3? Хотелось бы посмотреть, как форум залетает

А с чего ему быстрее летать? Документ по ссылке старый. У меня java и та новее: build 1.6.0_02-b06.

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

>ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

Пропустили. Уже пробегала новость про внутриядерную JVM и драйвер на Java в Solaris. :)

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

>У меня java и та новее: build 1.6.0_02-b06.

А у меня всё равно длиннее:
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

:))

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

>А теперь серьезно. Те же операции с графикой отнимают куда больше времени, чем соблюдение синхронности Vector. И правильное использование ClipRectangle занимает куда более важное место.

Опереции с графикой начали оптимизировать с Java2 1.4. Тогда уже было задействовано аппаратное ускорение 2D (например, Swing для отрисовки своих контролов в Windows уже тогда работал через DirectDraw).
Класс Vector переписали с использованием нового каркаса Java Collections Framework тоже в той же версии, если мне не изменяет память.
Потом начали проводить разные оптимизации в JVM.

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

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

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

Т.е. он выбрасывает виртуальные вызовы, если есть только одна реализация, делает инлайнинг и т.п.

В теории, можно было бы использовать "грубую" JIT-компиляцию приложений для ускорения запуска. Но на практике, это помогает только для стандартных библиотек.

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

> Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled

Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH

Кроме безопасности JAR нужно сначала на CRC проверить - в итоге не понятно, что будет быстрее.

> Т.е. если бы работало по аналогии с man
man не исполняет, а отображает данные из кеша. Разница понятна?

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

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

Нет.

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

> Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH
1. Нет ты че загoняешься, тебе что предлагают elf бинарес делать, для этого есть нативные java компиляторы
2. целостность файлов в должна обеспечивать система, в частности selinux
3. Кто помешает проге прописать в ~/.bashrc скрипт в котором используется LD_PRELOAD_PATH на вредоносный код под ~/sysfuck и как это повлияет на систему в целом. (Без использования java.)
4. некуй под рутом работать и запускать от его имени критические сервисы
5. в /var/cache/jvm/ кидать только либы из jdk/jre и проги установленные в /usr/bin etc, а в ~/tmp/jvm_cache пользовательские проги если ему разрешено их пускать
6. если имеется в виду топик про
http://www.linux.org.ru/view-message.jsp?msgid=2276232
то не LD_PRELOAD_PATH, а LD_LIBRARY_PATH

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

Хоть фраза адресовалась и не мне, рискну ответить.

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

Так на кой ляд мне это шило надо, если приложение уже установлено? На кой ляд гонять компиляцию при _каждом_ запуске? Греем окружающее пространство, близим тепловую смерть вселенной?

Вообще, меня давно интересовал вопрос: если уж делаете свой убер-переносимый байт-код, почему бы не компилить его до машинных инструкций в момент _инсталляции_, а не запуска? Повторюсь: на кой ляд при каждом запуске делать recompile?... Или вы каждый новый запуск выполняете на новом железе?...

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

>>для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

> То есть когда ты в Vim|Emacs|VisualStudio нажимаешь "Run", у тебя среда компилирует проект и запускает его менее чем за 1/25секунды? Круто. Ничего что у меня в Eclipse я жду немножко дольше?

среда(я обычно юзаю kdevelop) мне _мгновенно_ начинает показывать логи компиляции, а не подвисает как эклипс на пару секунд.

> А, кстати, когда ты нажимаешь "Поместить" на странице http://www.linux.org.ru/view-message.jsp?msgid=2278155 понимаешь ли ты, что тормозит не сама Java, которая обрабатывает твое нажатие, а твое сообщение еще успевает поместиться в базу и уже потом Java отдает тебе страницу с твоим ответом?

здесь я вижу, что тормозит веб-интерфейс.

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

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

> Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

смысл: затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

разделить легко: если для разных архитектур процессора/системы используется один и тот же код - то это "виртуалка"

>> да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

> Но у меня нет такого ощущения, по крайней мере, ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

цитирую санок: http://www.sun.com/software/learnabout/java/

The Java platform is the ideal platform for network computing. Running across all platforms -- from servers to cell phones to smart cards -- Java technology unifies business infrastructure to create a seamless, secure, networked platform for your business.

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

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

>> Ничего не поставит. пользователь по прежнему будет запускать class/jar а кэш хранится в /var/cache/java/precompiled

> Уже кучу раз писалось. Такой подход - реальная дыра в безопасности. Почему? Почитай, хотя бы. топик про LD_PRELOAD_PATH

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

не надо делать из JVM Ос в ОС. пусть жава исполняет бинарники, а системными делами пусть займётся система.

> Кроме безопасности JAR нужно сначала на CRC проверить - в итоге не понятно, что будет быстрее.

зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

> Т.е. если бы работало по аналогии с man man не исполняет, а отображает данные из кеша. Разница понятна?

нет.

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

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

> Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

смысл: затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

дополню:

Так чем же мне так не нравится дорогой форк?

Тем, что я наблюдал в нашем проекте одну утилитку, написанную на Java, которая вызывалась за сеанс работы около сотни раз. Программа была несложной, фактически обёрткой для ssh.

Всё было хорошо, программка работала достаточно шустро, пока с нахдывом оптимизаторской активности мы её не переписали. Даже не на C, а на Tcl. В итоге мы сэкономили 20% времени рабочего цикла нашей программы!

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

Вывод: место java-ы - выделенные сервера баз данных с веб-мордой:

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

2. сетевое взаимодействие тоже не быстро

3. менеджер памяти в языках с "мусорщиками" эффективен в случае сферической VM в вакууме, т.е. если процесс этого языка - единственный и никто с ним за память не борется. Пример, почему при двух или более жручих до памяти процессах с мусорщиками система будет дестоко свопиться, я приводил тут: http://www.linux.org.ru/jump-message.jsp?msgid=2251759&cid=2253260

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

s/нахдывом/нахлывом/ :)

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

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

> Уже пробегала новость про внутриядерную JVM и драйвер на Java в Solaris. :)

А в этой идее что-то есть! :)

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

> затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

Но затраты на запуск обычно несопоставимы с затратами на исполнение. Вот - в чем вопрос.

Но так не всегда. Как я понял, вы каждый раз вызывали к жизни JVM на очень непродолжительное время. То есть, JVM стартовала около сотни раз за сеанс работы. Циклически выполняло простенькую работу и завершалось. Так?

Если да, то оформление Java кода как Corba-сервера, постоянно висящего в памяти, было бы более лучшим решением. Или же все приложение должно было бы быть на Java, вызывающим некоторые куски на C. Это если бы очень хотелось сделать именно на Java.

А маленькие утилиты писать на Java - не совсем правильно. Здесь согласен.

Что касается GC. Есть задачи, где он нужен. В случае C его приходится изобретать самому. В случае Java он предоставлен самой средой. Во многих таких случаях (не real-time) второе решение предпочтительнее.

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

>> затраты на запуск есть при любом способе запуска кроме запуска нативной программы. да и то динамическую линковку можно посчитать за интерпретируемость :)

> Но затраты на запуск обычно несопоставимы с затратами на исполнение. Вот - в чем вопрос.

Зависит от задачи. См. исходники uname или date.

> Но так не всегда. Как я понял, вы каждый раз вызывали к жизни JVM на очень непродолжительное время. То есть, JVM стартовала около сотни раз за сеанс работы. Циклически выполняло простенькую работу и завершалось. Так?

Да. Использование java было заметным просчётом.

> Если да, то оформление Java кода как Corba-сервера, постоянно висящего в памяти, было бы более лучшим решением. Или же все приложение должно было бы быть на Java, вызывающим некоторые куски на C. Это если бы очень хотелось сделать именно на Java.

Кошмар. Совершенно не применимо к нашему продукту, в котором на java была только второстепенная утилита.

> А маленькие утилиты писать на Java - не совсем правильно. Здесь согласен.

> Что касается GC. Есть задачи, где он нужен. В случае C его приходится изобретать самому. В случае Java он предоставлен самой средой. Во многих таких случаях (не real-time) второе решение предпочтительнее.

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

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

> Только вот если уж взялся использовать gc в огромных масштабах, то приходится давать приложению отдельный сервер :(

Необязательно сервер. Это может быть клиентское приложение. См. IDE уровня IDEA, NetBeans или Eclipse. Более того, многие части оффтопичного VS также написаны на .NET. По-крайней мере, интерфейс для компонентов - дотнетовский.

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

>> Только вот если уж взялся использовать gc в огромных масштабах, то приходится давать приложению отдельный сервер :(

> Необязательно сервер. Это может быть клиентское приложение. См. IDE уровня IDEA, NetBeans или Eclipse.

Выделенный сервер -- компьютер, на котором запущено _одно_ java_приложение. Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

> Более того, многие части оффтопичного VS также написаны на .NET. По-крайней мере, интерфейс для компонентов - дотнетовский.

Ну и? Не понял, к чему это

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

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

А почему бы и нет?

> зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.

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

> Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

Значит, есть в каком направлении развиваться. Ограничений, накладываемых самой JVM, здесь не вижу. Несколько JVM вполне могут кооперироваться.

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

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

> Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.
А вы не думали над тем под фат, что можно подменить подменить и либы в каталоге с jdk/jre, там хватает чего поменять
и вообще подменить java.exe файл на типа "format c:"

Проблемы пользователей фат не есть наша забота. Юзаешь фат под систему ССЗБ.

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

>Тем, что я наблюдал в нашем проекте одну утилитку, написанную на Java, которая вызывалась за сеанс работы около сотни раз. Программа была несложной, фактически обёрткой для ssh.

> Всё было хорошо, программка работала достаточно шустро, пока с нахдывом оптимизаторской активности мы её не переписали. Даже не на C, а на Tcl. В итоге мы сэкономили 20% времени рабочего цикла нашей программы!

>gaa (*) (19.11.2007 14:45:17)

Это ошибка в проектировании. Java предназначена для тех ситуаций, когда запускает раз и работает долго или очень долго. Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

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

>Это ошибка в проектировании. Java предназначена для тех ситуаций, когда запускает раз и работает долго или очень долго. Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

Либо решение номер два. Смотрим в примере в JDK, как грузить явовскую машину. Загрузили ее из C разок и время от времени вызываем ее методы/работаем с Java данными.

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

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

> А почему бы и нет?

Тут недавно была в новостях статья про "ограничение доступа к linux". Там было написано про программу, проверяющую подпись любого исполняемого файла при его запуске. Советую заметить, что она была привязана ко всей системе, а не к отдельной VM.

>> зачем проверять crc у закешированного бинарника? пусть поддержанием целостности занимается фс. или у Вас FAT?

> Java работает на разных платформах. В том числе и на FAT. Поэтому целострость ФС в общем случае не может гарантировать.

FAT - платформа? Вау!

Повторяю: не надо тащить в JVM базовые функции операционной системы. А поддерживать совместимость с ненадёжной ФС под управлением ненадёжной ОС, лишь бы на ней ничего не навернулось - это вроде называется "костылём".

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

>> Потому что если их два(например, eclipse и jboss, с которыми я в текущий момент имею дело), то начинается игра "вгони противника в своп".

> Значит, есть в каком направлении развиваться.

А если мне нужна быстрая технология _сегодня_, а не теоретическая возможность, что когда-нибудь её ускорят? Выход один: использовать другую технологию ;)

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

Отлично, покажу ограничение(кстати, надо было Вам сходить по ссылке, я его уже описал):

"Вопрос такой: а память, зажранная каждым java-процессом для ОС как выглядит? Как занятая. Хотя в большинстве случаев из-за сборщика мусора и прочих прибамбасов управляемой памяти реально используется не более половины её. Но системе об этом жабка сказать не может, потому при большом количестве таких приложений(именно потому я и говорил про единственный процесс в системе), система будет свопиться, и в своп могут попасть в т.ч. и используемые данные а не только неиспользуемая, но не неосвобождённая требуха. Вот это мне не нравится."

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

_Как_ мусорщик узнавал о том, что запустилось прожорливое приложение? Не может он этого прямым безкостыльным способом узнать. (анализ вывода /usr/bin/free я считаю костыльным методом, т.к. он не определяет факта наличия "прожорливого" процесса)

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

> Unix-way на Java пишется немного по другому. В отдельных класслоадерах грузятся нужные классы, из них создаются объекты, после отработки - ссылки на объекты и класслоадеры прибиываются. Вуаля, получаем быстрое решение.

Это _не_ unix way, т.к. всё ограничено JVM и из внешнего скрипта это так же легко как и grep не заюзаешь.

> Либо решение номер два. Смотрим в примере в JDK, как грузить явовскую машину. Загрузили ее из C разок и время от времени вызываем ее методы/работаем с Java данными.

Это неудобно, т.к. к java-программе добавляется какая-то интерактивность, что влечёт кучу дополнительного кода и test cases.

Напоминаю, что вменяемым выходом оказалось отказаться от java-утилиты.

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

> "Вопрос такой: а память, зажранная каждым java-процессом для ОС как выглядит? Как занятая. Хотя в большинстве случаев из-за сборщика мусора и прочих прибамбасов управляемой памяти реально используется не более половины её. Но системе об этом жабка сказать не может, потому при большом количестве таких приложений(именно потому я и говорил про единственный процесс в системе), система будет свопиться, и в своп могут попасть в т.ч. и используемые данные а не только неиспользуемая, но не неосвобождённая требуха. Вот это мне не нравится."

Понятно. Вообще, эта тема выходит далеко за рамки ЛОРа. В .NET для этого случая есть костыль в виде Application Domains (несколько разделенных приложений внутри одного процесса). Были попытки сделать нечто подобное и для Java. Возможно, что некоторые из них реализованы.

> _Как_ мусорщик узнавал о том, что запустилось прожорливое приложение? Не может он этого прямым безкостыльным способом узнать. (анализ вывода /usr/bin/free я считаю костыльным методом, т.к. он не определяет факта наличия "прожорливого" процесса)

Честно говоря, мне трудно отвечать за разработчиков GC.. но могу предположить, что они просто оценивают количество доступной в системе памяти, как виртуальной, так и физической.

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

Хотя бы потому-что jvm может это делать многократно (с отдельными кусками кода) по итогам исполнения нативного кода, переоптимизируя на лету те куски, которые по ее мнению исполняются недостаточно эффективно (чего мы никогда не узреем в том же c/cpp и т.п.), что при запуске серверных долгоиграющих программ (а ява - она все-таки для серверов) все-таки эффективнее. Кроме того, сравнивать яву вообще можно только с .net, потому-что сектора применения схожи. А писать дектопные приложения на яве есть смысл только если их нужно попроще интегрировать с другими ява-приложениями или если это обусловлено проектом. Также как в большинстве случаев не имеет практического смысла писать на C систему с распределенными транзакциями, например.

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