Убийца или сценарий, который сделает другую JVM лучшим выбором, чем Sun JVM?

Для Java SE есть несколько JVM, доступных для работы на x86:

плюс некоторые пользовательские предложения для работы на сервере:

Другие платформы:

  • Sun Solaris JVM - лучшая масштабируемость, чем x86?
  • (edit) Компилятор GNU для Java - http://gcc.gnu.org/java/ - может компилироваться в собственный код на нескольких платформах.

У Sun JVM есть явное преимущество с программой jvisualvm, которая позволяет проверять исполняемый код во время выполнения. Есть ли какие-либо технические преимущества любой другой JVM, которая могла бы сделать ее лучшим выбором для разработки и / или производства?

Другими словами, есть ли способ или сценарий убийства, который окупит затраты времени / усилий / денег на другую JVM?

(Пожалуйста, также предложите дополнительные JVM, если они будут хорошим выбором).

Источник

10 ответов

Решение

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

В Mission Control есть множество функций, которые отсутствуют в VisualVM, например, онлайн-детектор утечки памяти, анализатор задержки, интеграция с Eclipse, JMX.logging в файл. и т. д. Если вы хотите сравнить VisualVM с Mission Control, здесь приведены примечания к выпуску и документация для последней версии.

Источник

IBM J9

Такую речь о продажах вы можете прочитать или услышать о J9:

IBM выпустила SDK для Java 6. Двоичные файлы продукта доступны для Linux на x86 и 64-битной AMD, а AIX для PPC для 32- и 64-битной. В дополнение к поддержке спецификации платформы Java SE 6, новый SDK также фокусируется на: обмен данными между виртуальными машинами Java, расширенная диагностическая информация, отслеживание стека операционной системы, обновленный инструмент jdmpview, стабильность платформы и производительность.

Кто-то скажет, что у IBM SDK есть некоторые преимущества, помимо скорости, что использование и расширение PermGenSpace намного лучше, чем в Sun SDK или GCJ (не имеет большого значения для клиентских приложений, но тяжелые серверы J2EE, особенно серверы портала, могут действительно вызывает Sun JDK изжога). Но, согласно этой статье, сравнивающей Sun с IBM JVM GC, оказывается, что производительность памяти зависит в основном от приложения, а не от виртуальной машины.

Так что, хотя верно то, что IBM JVM хорошо известна своими функциями устранения неполадок (более продвинутыми, чем Sun JVM), меня не убеждают различия на уровне GC.

И у Sun JVM есть большое преимущество перед IBM, по крайней мере, по Solaris: поставщики DTrace. На самом деле, я в основном работал с Weblogic на Solaris, поэтому JVM от Sun всегда был естественным выбором.

Oracle JRockit

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

Apache Harmony

Я могу ошибаться, но для меня Harmony состоит из пожертвований кода от IBM (преимущества: сообщество занимается поддержкой), и я не совсем понимаю, почему мне следует рассматривать Harmony, а не IBM J9.

Apple's JDK

Мне никогда не приходилось использовать Mac для производства, поэтому я не могу ответить. Я просто помню, что Apple понадобилось некоторое время для сборки Java 6, и я не знаю почему. Возможно, это не рационально, но это вызывает у меня подозрения.

OpenJDK

Я знаю, что некоторые поставщики предлагают производственную поддержку (например, RedHat с RHEL 5.3+, см. Эту запись в блоге) для OpenJDK, поэтому это может быть вариантом для платформ, не поддерживаемых Sun. Однако, если кто-то не скажет мне, что делает OpenJDK лучше, чем у Sun, я думаю, что я установлю Sun JVM на поддерживаемые платформы.

Так что для меня выбор на самом деле: JVM от Sun, если только я не буду запускать некоторые вещи Websphere, в этом случае я бы выбрал IBM J9. Но, честно говоря, я никогда не сталкивался с ситуацией, которую я не мог решить с помощью JVM от Sun, и которая могла бы оправдать (временную) замену на IBM, поэтому я не могу точно сказать, насколько хороши функции устранения неполадок. Но я признаю, что могу страдать от недостатка знаний о JVM от IBM.

Источник

Некоторые приложения, такие как финансовая и вычислительная наука, извлекли бы большую пользу из аппаратных реализаций с десятичной плавающей запятой. IBM выпустила серию процессоров ( POWER6, мэйнфреймы z9 и z10), которые реализуют стандарт IEEE 754-2008 с десятичной плавающей запятой. Последний IBM JDK может использовать аппаратное ускорение для BigDecimal s.

 Чтобы позволить разработчикам легко использовать преимущества выделенного оборудования DFP, IBM 
Developer Kit для Java 6 имеет встроенную поддержку 64-битного DFP через 
BigDecimal библиотека классов. JVM без проблем использует оборудование DFP, когда 
доступны для устранения необходимости в вычислительно дорогостоящих программных десятичных
арифметика, тем самым улучшая производительность приложений.

Это очень сложный случай, но если у вас есть мэйнфрейм z10 под рукой и вы хотите использовать его десятичный модуль с плавающей запятой в Java, то IBM JVM будет лучшим выбором, чем Sun JVM.

- Флавиу Кипчиган

Источник

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

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

Я склонен к IBM, потому что я работал там несколько лет назад. Я лично не занимался разработкой jvm, но я помню, что акцент группы разработчиков jvm был на следующих моментах:

  • Собственная оптимизация сборки мусора. Это включает в себя не только более быстрый GC, но также и больше параметров конфигурации, таких как GC для сервера и клиента. Это было до того, как Sun предложила аналогичные варианты.
  • Гораздо быстрее (x10) собственная производительность с интерфейсом JNI. Это было особенно важно в то время, когда Eclipse/WSAD начали набирать обороты, и SWT активно использовался. Если ваше приложение часто использует JNI, то я думаю, что вам стоит сравнить IBM JDK с Sun JDK.
  • Стабильность и надежность. Я думаю, что это актуально, только если вы покупаете коммерческую поддержку у IBM, например SLA для уровня обслуживания (WebSphere и db2, кластерная среда и т. Д.). В этом случае IBM будет гарантировать стабильность своих предложений, только если вы используете их jvm.

Что касается OpenJDK, я рекомендую вам взглянуть на эту историю OpenJDK. Насколько я понимаю, OpenJDK 7 будет практически идентичен Sun jdk 7, поэтому производительность, скорее всего, будет одинаковой. Основными отличиями будут лицензирование и небольшие компоненты, такие как webstart.

Oracle jvm полезен, если вы хотите запустить Java-код из вашей базы данных (через хранимую процедуру). Он включает в себя некоторые оптимизации, которые помогают БД работать быстрее в этом сценарии.

Как уже говорили другие, Sun догоняет своих конкурентов. Я думаю, что за 1,4 дня различия были гораздо более заметными, но не так сильно сегодня. Что касается jvisualvm, другие поставщики также предлагают аналогичные инструменты, поэтому я не думаю, что это проблема.

Наконец, есть еще одна метрика (хотя и немного противоречивая), показывающая, насколько серьезно эти поставщики относятся к своим ВМ. Это количество связанных патентов, которые они выдают. Это может быть полезно, если вам нужно убедить своего начальника или если вы любите читать патенты:)

Патентный поиск: IBM и Java - 4559 патентов.

Патентный поиск: оракул и ява - 323.

Источник

Не совсем JVM, но все же реализация Java: gcj. Преимущество заключается в поддержке многих процессоров, поэтому, если вы выбираете один из встроенных процессоров, gcj может быть вашим единственным выбором. Кроме того, поскольку это настоящий компилятор (а не просто JIT), вы экономите накладные расходы на компиляцию JIT (как в памяти, так и в циклах) на встроенной цели.

Источник

Несколько лет назад (JDK1.4) разные JVM имели разные преимущества:

  • IBM JVM могла выполнять дампы кучи (программно, по сигналам или по OOM), а утилита heaproot была очень полезна для отслеживания утечек памяти (менее навязчиво, чем профилировщики). Ни у какого другого JVM такого не было.

  • У JRockit было много полезных опций, которых не было у JVM Sun, - параллельный сбор. Это было также (намного) быстрее (и более стабильно, чем Sun VM).

Сегодня у Солнца есть эти особенности, но я уверен, что есть и другие. Скорость может быть одна. Стратегии сбора мусора другое.

Если вы используете WebLogic, некоторые ошибки в Sun JVM могут привести к ошибкам в WebLogic. Эти ошибки, скорее всего, будут устранены быстрее в JRockit.

Источник

Еще в дни Java 1.4 моя команда использовала IBM JVM для большой системы сообщений, работающей в Linux. Почему мы это сделали? Потому что мы тестировали разные JVM! JRockit был на самом деле самым быстрым, но иногда он падал, поэтому не очень хорош для производства.

Как всегда с этими вещами, измерьте это!

Источник

На собственном опыте и по достоинству я вижу простоту в дизайне IBM GC. Различные и новые GC от Sun, без сомнения, превосходны и предлагают множество опций настройки на мельчайших уровнях, но даже в некоторых наиболее активных веб-приложениях, которые я знаю, они обрабатывают тяжелые / агрессивные новые объекты и сохраняют много в куче кеша, я редко вижу, что GC когда-либо превышает 1%, даже пытаясь удержать низкий след. Конечно, мы могли бы настроить его лучше, но отдача уменьшается.

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

Теперь я мог бы упомянуть о дюжине элементов, которые IBM и Sun должны реализовать для убийственной JVM, но не в рамках вашего вопроса, который я предполагаю:)

Источник

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

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

Источник

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

Источник
Другие вопросы по тегам