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

Question

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

• IBM J9
• Oracle JRockit - http://www.oracle.com/technology/products/jrockit/index.html
• Apache Harmony - http://harmony.apache.org/
• Тот, что в OS X (если Mac), который выглядит как Sun с Aqua Swing.
• OpenJDK

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

• Азул - http://www.azulsystems.com/
• Google App Engine Java - http://code.google.com/intl/da/appengine/docs/java/overview.html

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

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

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

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

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

Answer 1

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

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

Answer 2

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 хорошо известна своими функциями устранения неполадок (более продвинутыми, чем JVM от Sun), меня не убеждают различия на уровне GC.

И JVM от Sun имеет большое преимущество перед 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.

Answer 3

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

To allow developers to easily take advantage of the dedicated DFP hardware, IBM 
Developer Kit for Java 6 has built-in support for 64-bit DFP through the 
BigDecimal class library. The JVM seamlessly uses the DFP hardware when 
available to remove the need for computationally expensive software-based decimal
arithmetic, thus improving application performance.

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

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

Answer 4

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

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

Я склонен к 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.

Answer 5

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

Answer 6

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

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

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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