LINUX.ORG.RU

Microsoft будет на конференции JavaOne


0

0

Следуя данному на LinuxWorld open source обязательству, Microsoft обращает свой взор на Java, планируя формальное присутствие на JavaOne в следующем месяце.

Microsoft появится на ежегодной Java-пирушке от Sun Microsystems в San Francisco впервые с того времени как компании в прошлом году "устаканили" разногласия и согласились работать над взаимодействием между продуктами и технологиями.

Microsoft до этого появлялась на JavaOne только однажды, в 1996, когда Microsoft лицензировала Sun-овскую Java в таком виде, что Sun назвала "very low key".

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



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

Почему тогда в Лиспе GC не более 5 процентов жрёт, а в Жабе постоянно вылезает до 50%?

Ни хрена ты просто в Лиспе не понимаешь, быдлёнок гнойный. Сдохни на хрен, вонючий выродок.

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

> Ни хрена ты просто в Лиспе не понимаешь, быдлёнок гнойный. Сдохни на хрен, вонючий выродок.

Что, опять Луговского на выходные из психушки выпустили? Ох, не доведёт это до добра, покусает он кого-нибудь, придётся потом уколы от бешенства делать...

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

Читаю я и охреневаю - это ж надо, до 50%, ужоснах %)
А теперь по делу: всем тем, у кого java отжирает по 50% времени работы нужно срочно прочитать о настройке GC. Ибо есть настройки по умолчанию, которые далеко не всегда оптимальны для ВАШЕЙ программы. Есть не менее 5 разных сборщиков мусора, работающих в разных комбинациях, их применение полностью документированно. Есть средства диагностики, которе точно покажут, какая часть heap'a и какого типа сборки GC являются узким местом. Например ваша программа активно распределяет память под короткоживущие объекты. По умолчанию размера eden может не хватать, из-за чего будет происходить слишком частый вызов minor сборщикa.
Пример из личного опыта: под нагрузкой приложение тормозило, причем работа GC занимала до 50% всего времени. Путем выбора правильной комбинации для minor и major сборщиков и веоичины footprint удалось свести потери на GC с 50 до 0,2%.
На сайте sun есть пара замечательных статей, которые дают достаточно информации по этому поводу. например "Turbo-charging Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers", "Tuning Garbage Collection with the 5.0 Java Virtual Machine"
Google вам в руки. Sapienti sat.

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

это все слова. вроде бреда фанатиков D3. сколько я не перепробовал софта на жабе - он жутко тормозит. а мужики то не знают (с)

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

> сколько я не перепробовал софта на жабе - он жутко тормозит.
это сайт у тебя тоже тормозит ?

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

1) Нормальный GC динамически подстраивается под нагрузку. Во многих ситуациях характер нагрузки заранее предсказать нельзя.

2) До 50% в среднем - это при оптимальной настройке убогонького жабского GC, по умолчанию на многих задачах оказывается под 95%

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

>>1) Нормальный GC динамически подстраивается под нагрузку. Во многих
>>ситуациях характер нагрузки заранее предсказать нельзя.
Да, нельзя. Но всегда есть рабочий режим. Вот обслуживает моя система 1000 человек в пике согласно требованиям заказчика с требуемым временем отклика. Для меня это верхняя граница(+запас по прочности). Я дал такую нагрузку, получил GC 85%. Оттюнил, получил 0,5%. Все, при меньшей загрузке затраты на GC будут меньше, латентность системы в пределах требований. Этого достаточно, нагрузка при 10000 пользователей меня не интересует. А если нужно 10000, то это другая система, возможно даже с другой архитектурой.
>>2) До 50% в среднем - это при оптимальной настройке убогонького жабского GC, по умолчанию на многих задачах оказывается под 95%
Слишком смело сказано. GC в одной только реализации SUN около пяти, в том числе и адаптирующиеся динамически под загрузку. У BEA есть свои реализации GC(там адаптивный GC вообще по умолчанию запускается)+у IBM свои.
Что касается 50% в среднем, то мой личный опыт, на моих серверных задачах, говорит мне, что это не так. Вы можете оставаться при своем мнении, но вот собственным логам GC я верю больше :)

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

Да, а где, по вашему мнению, не убогий GC ?
Lisp, python, haskell, .NET ? Какая-гибудь академическая разработка ?
Тут встает 2 коварных вопроса
1) написана ли на этом языке с неубогим GC пара-тройка серьезных систем, которые оную неубогость могут подтвердить?
2) если они (языки с неубогими GC) такие продвинутые, отчего та-же SUN не имплементирует что-то подобное? или вы заведомо считаете тамошних программистов тупыми ограниченными кодерами ?

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

Я говорю про свои задачи - огромное количество короткоживущих очень маленьких объектиков. Ни в одной JVM нет хорошо затачиваемого под такой тип нагрузки GC. И про 50% я насвистел, кстати - меньше 60 не получается в принципе.

Сравни с GC, используемым в OCaml-е - он туп, как пробка, но при этом на порядки быстрее любого GC в любой JVM. Главное - там очень быстрая операция выделения памяти, никакая JVM из врождённых ограничений никогда так не сможет.

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

В OCaml-е - не убогий.

Серьёзных систем - полно, но это не подтверждение. Приемлимое подтверждение - бенчмарки.

2) Sun по барабану на такие типы нагрузки. Кодеры у них может и не тупые, а вот дизайнеры - такие, как Гослинг - упёртые бараны. Хотя - нет, кодеры тоже тупые. Посмотри на сырцы HotSpot. Если не стравишь - героем будешь!

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

в линксе? нет =) пробовал limeware, azureus, читалку книг - это недавно. до этого давно пробовал уже не помню что за софтины. у меня тогда стойкое отвращение к жабе выработалось - большое, тормозное. вот недавно решил проверить как дела - воз и там же

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

Вот видишь - ты тоже говоришь о своих задачах :). Потому нельзя быть таким категоричным - задач много. Работает старое правило 80\20
Что касается твоей задачи.
Cтранно, что такая большая разница получается. Маленькие, это сколько ?
Дело в том, что для минорных сборок принципиально алгоритм ведь не сложный, там не нужно дерево объектов обходить даже - простое тупое копирование идет из области А в область Б - чего уж проще-то ?

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

Да, действительно самый больщой вклад будет вносить операция распределение памяти.
Но можно выкрутится другим способом - увеличить размер minor поколения, тогда сборки будут реже за счет расхода памяти.
Что касается серьезных систем, то окамл я все таки с J2EE равнять не буду. Интересный язык, но я думаю, что для большинства коммерческих проектов он непригоден в силу малой распространенности, а следовательно, большей стоимости программистов и сопровождения. Хорошая академическая разработка для хороших академических проектов :)

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

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

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

Копирование должно быть не тупое, а компактифицирующее.

Маленькие - 8-16 байт. И их очень много, живут очень недолго, буквально, выделенное 4-5 выделений назад уже становится ненужным (ну, все уже догадались - это graph reduction).

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

Собственно, про пул объектов уже сказали чуть выше. Посмотри в сторону Javolution - они там как раз эту идею и продвигают.
Хотя, вообще говоря, я не уверен, что для расчетных задач java самое то.
Продуктивнее будет наверное на фортране написать, а если производителльность распределения памяти волнует, то и от языков с GC возможно стоит отказаться.

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

>>Да не надо сравнивать количество библиотек и обученных обезьянок.
Надо, еще как надо. Для меня программирование это работа, за которую заказчик платит деньги. И моя задача, реализовть систему самым эффективным способом. Я не могу искать программистов с экзотичскими для отрасли скиллами и повязать на них проект - заказчик то хочет минимизировать TCO в том числе, и риски.
>>Надо задаться вопросом, почему барашки из Sun не смогли сделать так же?
Я уже говорил, что реализаций J2SE больше одной штуки. Вы пробовали другие ? Что вам, на SUN свет клином сошелся?
Возьмем реализацию от IBM. Вы тоже заведомо считаете их разработчиков "барашками"? К сведению - эта корпорация уже 7 лет занимает первое в мире место по количеству получаемых патентов в год. Их R&D один из самых мощных в мире.
Вот, дернул первую же ссылку в гугле по словам "ibm java gc"
Вам нужен компанифицирующий GC - пожалуйста
"Fine-tuning Java garbage collection performance" (http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/)

IBM implementation uses a garbage collection algorithm called mark-sweep-compact (MSC), which is named after three distinct phases.

Mark: All the objects that are "reachable," or alive, are marked. This phase starts off by locating "roots," such as objects on thread stacks, Java Native Interface (JNI) local and global references, and so on, and following each reference recursively until all references are marked.

Sweep: All the objects that were allocated but are not marked anymore are swept away, and the space used by them is reclaimed.

Compact: Holes or fragments in the heap are removed by moving the live objects together in the heap.

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

>>это сайт у тебя тоже тормозит ?
> в линксе? нет =)
а тоже java, значит не стоит так категорично
> limeware, azureus, читалку книг
ИМХО, для такого класса программ java (да вобщем и все VM языки) не очень подходит, хотя есть надежды на gcj.

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

Какая на фиг рассчётная задача? Это компилятор!

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

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

Про качество IBM JRE знаю. Увы - привязан к Sun, тут уж, блин, требование заказчика.

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

>И их очень много, живут очень недолго, буквально, выделенное 4-5 выделений назад уже становится ненужным

Если они живут очень недолго (4-5 выделений), то их не может быть очень много одновременно. Имхо, пул как раз для таких ситуаций.

Не буду настаивать, но всё-таки посмотрите, может поможет: http://javolution.org/api/javolution/realtime/package-summary.html#OVERVIEW

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

Да нельзя предсказать, какой из них останется жить. Тысяча сдохнет через 5 выделений, а 1-2 останутся навечно.

P.S. Дотюнил таки до 5% GC, но только ценой увеличения требований к памяти в 20 раз. Даже не смешно. :(

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

Да, и я не могу их вручную возвращать в пул. Для тех объектов, которые имеют предсказуемое время жизни, я и так пулы использую, но самый мерзкий и многочисленный объект - узел графа, непредсказуем абсолютно. Тут разве что только пул с собственным GC писать...

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

Скажите, а вот это решение http://javolution.org/api/javolution/realtime/package-summary.html#FAQ-2 Вам не подходит?

>Тут разве что только пул с собственным GC писать...

Не удивительно. Мне кажется, в случае C++ многократный вызов new/delete съедал бы таже слишком много времени. Любая задача, требующая эффективного управления памятью, может потребовать написания собственного менеджера.

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