LINUX.ORG.RU

Oracle анонсирует бесплатную и Premium версии Java VM

 , ,


1

2

Адам Мессингер (Adam Messinger), вице-президент Oracle по разработке, заявил на конференции QCon, что Oracle будет разрабатывать две версии JVM на основе OpenJDK: платную и бесплатную.

Мессингер не объяснил, чем Premium будет отличаться от бесплатной, но, похоже, она будет работать быстрее и поддерживать дополнительные способы взаимодействия с Java-библиотеками, разрабатываемыми самой Oracle.

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

★★☆☆

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 2)

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

> Трэйдерские программы работают исключительно на С/С++ и даже РАЗГОВОРОВ о применении Java/.Net там нету.

:-)

Расскажите мне пожалуйста как задействовать SSE или NEON из Java

Как правило - native call, если не устраивает производительность того, что сгенерил JIT.

Overhead в Java при вызове Native кода обычно больше чем выиграх от его использования.

Когда ты последний раз его замерял? То-то же. Ну если ты из тех, кто использует SSE для того, чтобы сложить два числа, то ССЗБ. А если тебе надо сделать сложные вычисления - пишется на С. Но только эта часть. Вся обертка делается на нормальном языке.

Ты, солнышко, расскажи, сколько раз на дню тебе приходится писать свой memory allocator. И про то, насколько быстро он работает, в том числе в многопоточных программах. И про то, как ты передаешь данные из потока в поток. А то всякие там new и delete в плюсах зело тормозны по сравнению с аналогами в жабе. В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды. В Haskell - та же картина. При этом выделение и освобождение - thread-safe.

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

а почиму крузис ни на жабе написан?

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

>экологический ущерб от работы АЭС на порядки меньше

Редко, зато метко. Превед из Чернобыля.

читаем внимательно: от работы, а не от катастрофы

shty ★★★★★
()
Ответ на: комментарий от rtvd
#include <string>

#include <iostream>

int foo(const std::string &x) {

   return x=="bar";

}

int main(int argc, char **argv) {

   std::cout << foo(false) << std::endl;

}

man g++ (hint: -Wconversion)

Еще страшилки с C++ FQA закопипастишь, чтобы было убедительнее про микросекундные отклики на джаве/хаскеле?

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

уже ж делают относительно компактные реакторы. ну и всякие апл и атомные ледоколы никто не отменял.

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

> man g++ (hint: -Wconversion)

И сколько еще мне надо -Wwtf вкатать, чтобы этот язык стал прямоходящим?

Еще страшилки с C++ FQA закопипастишь, чтобы было убедительнее про микросекундные отклики на джаве/хаскеле?

Не веришь - твое дело. Тут много такого быдла тусуется, что «не верит». Вот только аргументов и конкретных примеров у них мало находится. Самым весомым пока что был аргумент про SSE. Но и то, слабовато. В большинстве программ SSE код занимает очень маленькую нишу и обычно выносится в отдельную часть, написанную хоть даже на С.

В общем, если хочешь - раздувай щеки и верь в свое нереальное превосходство. Я уверен, это очень приятно. %)

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

Ну что же ты так? Мог бы и покрасивей слиться.

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

>> можно тынц на то, что Oraclt ограничивает сферу применения OpenJDK?

http://www.google.ca/search?q=ASF+TCK+problem&ie=utf-8&oe=utf-8&aq=t&rls=org....

Ога =))) Ваши сведения не полны ;)

ASF не занимается OpenJDK. Совсем.

ASF разрабатывает Harmony, который к OpenJDK никакого отношения не имеет. У них разные родословные. Так что Oracle пинает именно параллельные разработки, дабы все развивали канонический OpenJDK.

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

>> стоит посмотреть на астериск к примеру ;)

Да, давайте сравним его с аналогичным на Java

давай сравним =))) вы знаете открытый VoIP на java?

я знаю только закрытые. Работал закрытый намного стабильнее asterisk и не падал в core dump после 4-5 часов работы. Причем core уносил весь сервер целиком... в java-же теоретически должен был отвалиться только тред отдельного соединения, а остальные продолжить работу ;)

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

java-же теоретически должен был отвалиться только тред отдельного соединения, а остальные продолжить работу ;)

Это только теоретически, на практике относительно часто бывает, что проблема в треде роняет всю JVM вместе со всеми приложениями, которые в ней крутяться.

Т.е. тупо core dump запущенной jvm.

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

Работал закрытый намного стабильнее asterisk

Название у закрытого есть? Или он внутрикорпоративный?

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

>И сколько еще мне надо -Wwtf вкатать, чтобы этот язык стал прямоходящим?

Воинствующее неосиляторство. Помнится, ты про джаву писал, что надо уметь ее использовать, а кто не умеет, тот ССЗБ. Так вот тут хрестоматийное ССЗБ.

Не веришь - твое дело. Тут много такого быдла тусуется, что «не верит». Вот только аргументов и конкретных примеров у них мало находится.

Это не религия, тут не вопрос веры. Изначально в джаве больший оверхед по быстродействию/памяти, поэтому использовать ее в time critical приложениях почетно, но странно. Хотя я не отговариваю, наоборот, хотелось бы видеть у конкурентов больший прогресс: еще более простые интерпретируемые языки вместо джавы/джита, еще более автоматизированное управление памятью, динамическую типизацию вместо кондовой статики, функционально верные, неизменяемые структуры данных.

В общем, если хочешь - раздувай щеки и верь в свое нереальное превосходство. Я уверен, это очень приятно. %)

Никогда не делаю так. Психологическая проекция? %)

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

>> java-же теоретически должен был отвалиться только тред отдельного соединения, а остальные продолжить работу ;)

Это только теоретически, на практике относительно часто бывает, что проблема в треде роняет всю JVM вместе со всеми приложениями, которые в ней крутяться.

Т.е. тупо core dump запущенной jvm.

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

Хотя если у меня подобного не было - это не значит что не было никогда. В каком приложении / коде подобная бага?

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

Это только теоретически, на практике относительно часто бывает, что проблема в треде роняет всю JVM

Подтверждаете? Ссылки на пруф.


Т.е. тупо core dump запущенной jvm.

За многие годы использования JVM и в хвост и в гриву редко видел core dump. В основном это было из-за:
1. Битых шрифтов
2. JNI
3. Баги в JVM от Apple со stack overflow
4. Проблемы с памятью (битые плашки памяти)

Korwin ★★★
()

Ужас. Почему чтото столь прекрасное как Java должно было попасть в грешные руки чегото столь ужасного как Oracle...

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

> Ужас. Почему чтото столь прекрасное как Java должно было попасть в грешные руки чегото столь ужасного как Oracle...

Большинство смотрит со стороны и видит как большой монстр приобрел маленького монстрика и вытворяет с маленьким монстиком непотребства. :)

Весь вопрос в восприятии.

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

Подтверждаете? Ссылки на пруф.

Да, личный опыт. Приложение - Tomcat5.5/Jira/Confluence jdk 1.6

За многие годы использования JVM и в хвост и в гриву редко видел core dump.


Относительно часто - это условно, конечно такое бывает редко. В добавок к вашим причинам - ошибки выделения памяти jvm -> application.

Битую память не рассматриваем, очевидно.

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

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

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

При запуске с определенными ключами OutOfMemoryError вызывает падение JVM с дампом, чтобы отловить проблему. Обычно это используется для отладки. В нормальном режиме нехватка памяти вызывает исключение в момент применения new (и сильную деградацию производительности, т.к. сборка мусора проводится очень часто).

Продукты от Atlassian любят кушать память, запускать их с меньше 2 гб памяти я бы не стал.

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

> Тебя спросили про то, где твои микросекундные Java программы крутятся.

Я тебе ничего не должен, расслабься. Не веришь - иди лесом. Демонстрировать тебе свой код и даже говорить где он работает я не намерен.

Я на Java немало написал и считаю тебя дешёвым брехлом без доказательств.

А я считаю тебя дурачком. Ты даже не можешь сформулировать, что у тебя медленно работает и и понять почему. Подозреваю, что ты из тех, кто обожает Spring/EJB/прочую хрень, и удивляется, что у него такая лажа выходит. Мне с тобой не по пути. :-)

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

При запуске с определенными ключами OutOfMemoryError вызывает падение JVM с дампом, чтобы отловить проблему.

Нет, я не об OOM (OOM - это обычное дело, нормальная ситуация), падает без намеков на нехватку памяти, скорее от несоответствия выделенной и физической, либо в каких-то связках с планировщиком, который ВНЕЗАПНО решает кусок в своп засунуть в силу третьих причин.

Продукты от Atlassian любят кушать память, запускать их с меньше 2 гб памяти я бы не стал.

Я много лет использую их и в курсе этих требований, спасибо за напоминание. )

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

[quote]И сколько еще мне надо -Wwtf вкатать, чтобы этот язык стал прямоходящим?[/quote]

Нужно не в -Wwtf вкатывать, а руки выпрямлять. И касается это не только C, а любого языка. Программист либо умеет использовать язык, либо не умеет. Третьего не дано. А быдлокодерам всегда то язык кривой, то еще что-нибудь.

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

>Это только теоретически, на практике относительно часто бывает, что проблема в треде роняет всю JVM вместе со всеми приложениями, которые в ней крутяться.

Т.е. тупо core dump запущенной jvm.

Интересно, что у меня жабная программа под AIX 6.1 так падала. Так после разбирательств баги были не в жабе а кернеле AIXa.

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

>Я тебе ничего не должен, расслабься. Не веришь - иди лесом. Демонстрировать тебе свой код и даже говорить где он работает я не намерен.
:)
Это в общем-то подтверждение того, что выш пост о микросекундах отклика на Java был просто враньём.

grim ★★☆☆
() автор топика
Ответ на: комментарий от dimag

>A RBC CM Monaco по вашему на C++ написана?
Кто такая Монако? если аналитика то там всего хватает.
Мы говорим об одном и том-же Royal Bank Capital Markets?

grim ★★☆☆
() автор топика
Ответ на: комментарий от rtvd

>Синхронизованны ли сервера и сколько их никак не влияет на принятие и обработку данных с них.
Задача обеспечить реакцию серверов в пределах нескольких микросекунд.

grim ★★☆☆
() автор топика
Ответ на: комментарий от rtvd

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

выбравших низкоуровневый язык

С++ высокоуровный язык. Вы книжку недочитали. И был высокоуровневым, даже когда я его лет 15 назад преподавал в университете.

на котором даже такое говно компилируется

А то, что на С++ можно написать корявый код, так это ни для кого не секрет. Только таким корявцам быстро под зад дают.
Как говортся нет ума - считай калека.
Для таких на упаковке арахиса пишут - не засовывайте в нос - можете задохнуться а на микроволновках «не сушите домашних животных»

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от rtvd

>Ну если ты из тех, кто использует SSE для того, чтобы сложить два числа, то ССЗБ.
:) а как-же «Когда ты последний раз его замерял? То-то же. »
:) Ну, поделитесь своими замерами или как всегда - информация строго секретная :)

Ты, солнышко,

Я, в общем-то не гомофоб, но всё-же давайте держаться рамок приличия.

расскажи, сколько раз на дню тебе приходится писать свой memory allocator.

Не каждый год.
А что в это трудного, кстати?
Кроме того их уже такое количество написано, что в общем-то и натрягаться не нужно.

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

Shared memory - быстрее не придумали.

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

Очень глупо писать безотносительные значения.
Кроме того в C++( и mono) есть денные на стэке. времени на резервирование тратится раз в 1000 меньше.
Но я об этом уже писал.

grim ★★☆☆
() автор топика
Ответ на: комментарий от VoDA

>ASF не занимается OpenJDK. Совсем.
Очень странно что вы только сечас это заметили.

Так что Oracle пинает именно параллельные разработки, дабы все развивали канонический OpenJDK.

Об этом и речь с самого начала.

grim ★★☆☆
() автор топика
Ответ на: комментарий от VoDA

>Работал закрытый намного стабильнее asterisk и не падал в core dump после 4-5 часов работы.
Это просто напросто голословный набор утверждений.
Я предлагал сравнить его на на моём домашнем сервере, на котором ещё и bittorrent клиент на С++ крутится. И не падает как и Астрикс.

Вот давйте запустим на этом сервере Azureus+ваш любимы на Java сервер и сравним результаты через недельку. Или вы можете сами провести такой эксперимент и нам расскажете.

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

>> ASF не занимается OpenJDK. Совсем.

Очень странно что вы только сечас это заметили.

я об этом знал еще когда Sun только размышлял об открытии java ;)

PS забили ибо вроде оба все поняли.

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

>> Работал закрытый намного стабильнее asterisk и не падал в core dump после 4-5 часов работы.

Это просто напросто голословный набор утверждений.

для меня это факт ибо присутствовал при этом.

Я предлагал сравнить его на на моём домашнем сервере, на котором ещё и bittorrent клиент на С++ крутится. И не падает как и Астрикс.
Вот давйте запустим на этом сервере Azureus+ваш любимы на Java сервер и сравним результаты через недельку. Или вы можете сами провести такой эксперимент и нам расскажете.

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

Не пользуюсь torrent с сервера - лениво настраивать =)

А какие результаты вы хотите сравнить? запущу я вполне себе обыкновенный Apache Tomcat - простоит неделю с 1-2 сессиями в параллель и ЧТО? какие параметры будем сравнивать?

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

>>В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды.

Очень глупо писать безотносительные значения.
Кроме того в C++( и mono) есть денные на стэке. времени на резервирование тратится раз в 1000 меньше.

Представь себе, в java тоже так делается, если есть возможность.

Кстати, не подскажешь ли, где купить такое же железо как у вас? Если у вас выделение на стеке занимает в 1000 раз меньше чем 1-3 наносекунды, то либо у вас ооочень умный CPU, либо его частота - порядка сотни гигагерц. Может ваш C++ софт крутится на машинах марсиан? Тогда все, вопрос снят. Почет и уважуха.

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

>>Ты, солнышко,

Я, в общем-то не гомофоб, но всё-же давайте держаться рамок приличия.

Я вообще-то с детьми привык общаться по-доброму и нежно. :)

Кстати.. Хочешь, чтобы у тебя среди клиетов были еще и Credit Suisse? Им вот пришлось для каких-то задач купить машинку, что называется Azul 2000 series (up to 768 processing cores on 16 processor chips with 768 GB of memory). Может предложишь им свои услуги, и перепишешь их Java софт на C++? Сэкономишь им кучу денег.

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

> Где это жабикам платят «достойно»? Если по всяким там dice судить, жабики нищебродят.

Вообще-то, те, кто платят достойно, обычно не вывешивают объявления на dice. Они сами ищут людей в «рыбных местах». На крайний случай, обращаются к специализированным рекрутерам. И это не зависит от языка программирования или даже специализации.

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

>А какие результаты вы хотите сравнить? запущу я вполне себе обыкновенный Apache Tomcat - простоит неделю с 1-2 сессиями в параллель и ЧТО? какие параметры будем сравнивать?
Домашний сервер это ARM 1Ghz/512mb RAM
Сравнивать будем запустится ли оно вообще azureus+ваш аналог астерикса.

ps
Я видел Астерикс в работе небольших конторах(до 1000 человек на телефонах) и связью он обеспечивал без проблем, хотя логи я конечно-же не смотрел. Может он и падал.

pps
В принципе я просто хотел сказать что всему своё место. Инормально написанная программа на С++ не падает годами. Пример - Беларусьтелеком где стоят системы АПУС, с аптаймом по несколько лет и перегружаемые только иззи проблем с железом(привет Белавоксу). И на Java можно ниписать кривые программы, что я регулярно наблюдаю.

grim ★★☆☆
() автор топика
Ответ на: комментарий от rtvd

>>>В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды.

Очень глупо писать безотносительные значения. > Кроме того в C++( и mono) есть денные на стэке. времени на резервирование тратится раз в 1000 меньше.

Представь себе, в java тоже так делается, если есть возможность.

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

Или это опять секретная информация ( просто брехня )?

Вы раздуваете своё враньё всё больше и больше, не боитесь лопнуть?

grim ★★☆☆
() автор топика
Ответ на: комментарий от rtvd

В принципе тему считаю исчерпанной до предоставления хотябы каких-либо фактов.

Сказки и понты в расчёт не принимаются.

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

> В принципе тему считаю исчерпанной до предоставления хотябы каких-либо фактов.

Сказки и понты в расчёт не принимаются.

Аналогично.

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

>Я вообще-то с детьми привык общаться по-доброму и нежно. :)
а вот педофилия уже преследуется по закону.

Хочешь, чтобы у тебя среди клиетов были еще и Credit Suisse?

Зачем оно мне?
В европе мало платят а налоги просто ужасные.

Им вот пришлось для каких-то задач купить машинку, что называется Azul 2000 series (up to 768 processing cores on 16 processor chips with 768 GB of memory).

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

Может предложишь им свои услуги, и перепишешь их Java софт на C++? Сэкономишь им кучу денег.

Во первых я на С++ активно не пишу уже лет 5.
Кроме того вы видимо ни разу не видели крупной корпорации раз такое пишете.

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

> Вы ещё не ответили на способы замера ваших наносекундных выделений памяти.

Очень просто. Есть класс. У него есть поле с типом, скажем, Object (ссылка на что-нибудь). Далее есть цикл, что делает с десяток итераций. В каждой итерации замеряется время начала, делается цикл в 1e9 операций, замеряется время конца, печатается разница между началом и концом. Операция во внутреннем цикле: this.obj = new Object();

Далее смотрится, какое получается время и как оно зависит от обстоятельств.

Цифры меняются в зависимости от того:

* volatile это переменная или нет

* public или private

* есть ли еще один поток, что почитывает эту переменную

* реализация JVM

* железо и то, как оно настроено

Если ссылка может убегать в другой поток, машинка слабая и JVM-отстой, можно получить и 20ns на операцию (создание Object и запись ссылки в поле класса или объекта). Если Java понимает, что в другой тред объект убегать не может - она делает thread local allocation. Если видит, что вообще нахрен не нужен объект - она, похоже, его и не создает.

Конечно, это не идеал. GHC бывает работает пошустрее. И FFI у него лучше. Но в плюсах ты даже этого без спец. аллокатора не добьешься. А с ним у тебя будет гемморой, так как сторонние библиотеки не будут с ним дружить. Впрочем, если ты используешь только свой код - пожалуйста. %)

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

так что, приведёте способы замера наносекундных выделений?
или как вы добились микросекундных откликов?
или того что native call на Java стал быстрым?

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

>>Им вот пришлось для каких-то задач купить машинку, что называется Azul 2000 series (up to 768 processing cores on 16 processor chips with 768 GB of memory).

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

Ага, это точно также объясняет, зачем народу нужен тобой упомянутый сервер за $400K для запуска этой твоей C++ программулины.

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

Kron телал такие замеры. Именно процесса выделения памяти/освобождения.
http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

C++ (stack)   0,495   g++ 4.3.4
Java (server)   2,33   1.6.0_16-b01
C++ (boost)   3,42   g++ 4.3.4
Java   4,99   1.6.0_16-b01

так-вот

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

> или того что native call на Java стал быстрым?

А я говорил, что он быстрый? Для относительно крупных вещей он не играет роли. А для маленьких ручные оптимизации с SSE и даром не нужны.

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

>Ага, это точно также объясняет, зачем народу нужен тобой упомянутый сервер за $400K для запуска этой твоей C++ программулины.
Это вы к чему?
мелкий банк тратит моллимона на сервер, чтобы исправить ошибкия писак.
Я с такими проектами регулрно работаю.
Кроме того я вам уже говорил, я на С++ давно не активно не пишу - не ранка для лекаря. А вот Java/.Net - полное раздолье. Переключился я на них уже лет 5 назад.

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