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

Ответ 1

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

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

Ответ 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, выясняется, что производительность памяти зависит в основном от приложения и не столько от VM,

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

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

Oracle JRockit

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

Гармония Apache

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

Apple JDK

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

OpenJDK

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

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

Ответ 3

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

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.

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

Ответ 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-код из своей базы данных (через хранимую процедуру). Он включает некоторые оптимизации, которые помогают db работать быстрее в этом сценарии.

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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