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

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

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 .

JDK от Apple

Мне никогда не приходилось использовать 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.

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

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

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

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

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

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

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

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

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.

-- Flaviu Cipcigan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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