Java2SE 1.4.2

>>>Я зарегистрировался. Так зачам были нужны green threads?

Выполнено только первое условие. Второе нарушено - про 'зелёные нитки' речи не было. Третье тем более не выполнено - выступая в сторону от темы требуется не только заявить нечто, но внятно увязать сформулированное с ранее обсуждаемым.

Хотя я могу ответить точно в твоем стиле: зачем и когда нужны green threads ясно написано в доках к jvm. Но к теме "как ps отображает нативные треды в линуксовой jvm" ни вопрос ни ответ отношения не имеют.

> нужны green threads ясно написано в доках к jvm

С удовольствием даю ссылочку:

http://www.inp.nsk.su/~chernyak/webdocs/native_threads.html

Но вопрошаю:

Почему "green threads are slightly faster than native threads"?

И, кстати, есть ли в J2SDK 1.4.2 for Linux green threads? Это уже не офтопик :))))

Да speer тоже брызгал слюной и считал всех тех, кто не фанатик, ламерами криворукими, пока ему не привели фразу от самой фирмы Sun Microsystems о падучести Java на glibc < 2.2.4. Cпорить с фанатиком дело безнадежное, можно только просто поразвлечься, как на "Talks".

Я упорное не понимаю, откуда этот фонтан бредовых предположений , контр-примеров и цитат на посторонние темы...

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

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

С 1.4.2 я как раз сейчас и играюсь, зеленые треды вроде никуда не делись, остальное в процессе изучения.

speer в очередной раз облажался:

In Java 2 Release 1.3, the Hotspot virtual machine uses system threads to implement Java threads. Because Linux threads are implemented as a cloned process, each Java thread shows up in the process table if you run the ps command. This is normal behavior on Linux.

http://developer.java.sun.com/developer/technicalArticles/Programming/linux/

С английским лады? Переведи фразу:

"Because Linux threads are implemented as a cloned process"

Повторяю "Because Linux threads are implemented as a cloned process"

Еще раз повторяю "Because Linux threads are implemented as a cloned process"

О чем я тебе изначально говорил. На мой риторический вопрос про 1.4.2 можешь уже не отвечать.

>зеленые треды вроде никуда не делись

Да не позорьтесь вы так! Виндусятники смеяться будут.

speer, ау!

Войди в директорию $JAVA_HOME/jre/lib/i386 и покажи всему ЛОРу куда "никуда не делись" "зеленые" треды.

:)))

>>>Да speer тоже брызгал слюной и считал всех тех, кто не фанатик, ламерами криворукими, пока ему не привели фразу от самой фирмы Sun Microsystems о падучести Java на glibc < 2.2.4.

Цитаты, погремушка! И брызги слюны тоже предъяви... Заодно перечитай что _на_самом_деле_ в сановском рипорте написано и попытайся увязать это с темой того треда и нынешнего. Я думаю тебе это на недельку напряженного труда.

"Да speer, мало того, что косит под Луговского, еще и читать не умеет"


Я не speer и не Луговской, а вот тебе мразь придётся ещё ответить за пиздеж.

вырезка : available commercially at the end of the year

Что бля сука Так где продукт-то ? Уже купить можно ? Отсосал мразь ?

Speer отвечай конкретно, не отвлекайся:

1) где ты нашел в 1.4.2 green_threads?

2) Как не русский язык переводится фраза: "Because Linux threads are implemented as a cloned process"

speer у вас память девичья?

">Что сказали в Sun "Используйте Solaris и не имейте проблем."

Вас послали (а зачем клиента терять?) и вы утёрлись, потому что не было у вас линуха с нормальной явой и поддержкой всего этого добра вместе. Поигрались вы с ним нахалявку, а потом бросили...

Но причем тут "плохие треды", может дело не в них? Как разобрались-то в причинах?

speer (*) (2003-06-20 19:18:36.968758)"

"Что говорит Sun по этому поводу: (февраль 2002)

One of the most likely root causes for the JVM exiting with segmentation faults is a problem with specific versions of the Linux glibc library and the JVM for Linux. It has been discovered that the combination of glibc v2.2.2 and the JVM for Linux is not stable and causes the JVM to crash. Upgrading the glibc to a newer version such as glibc 2.2.4 will ensure that the JVM does not exit with segmentation faults under a heavy load.

Значит проблема в лялихе ?

Sun-ch (*) (2003-06-21 13:19:38.958722)"

>Уже купить можно ?

Где, где? В Караганде.

http://www.microsoft.com/downloads/details.aspx?FamilyId=A4A339CE-5E2E-43C9-8...

Реально надо правде в глаза смотреть, хоть и красными глазами :))) Где сейчас JavaOS? Там же где RMX!

http://www.microsoft.com/windows/Embedded/community/experto/july2002/nframpto...

Microsoft: Did you evaluate other operating systems before choosing a Windows Embedded solution, and if so, why did you choose Windows Embedded?

Frampton: I have developed systems in DOS, Forth, Intel&#8217;s RMX, QNX and PSOS. None of these platforms provides the total combination of graphics, communications technologies, integration technologies, and most importantly real-time capabilities. Windows CE .NET is a unique platform for developing complete industrial automation solutions.

Урод, покажи мне продукт а не составную часть продукта.Всё же ты уёбок который много пиздит и за базар не отвечает. А на счёт красноглазого ты рыбий глаз круто заблуждаешься.

да уж... читаю я тут форумы на linux.org.ru, день так третий, и начинаю понимать, чем вы тут все занимаетесь...

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

выскажусь по тредам

native threads - это же карашо. Это реальное распараллеливание.

А что если - с одним камнем?

context switching overhead существует, но ведь он идёт на более низком а следовательно - более быстром и оптимизированном уровне - уровне OS (в случае зелёных тредов - контексты переключает java). Т.е. ниже лэер (ближе к земле ;-) - оно лучше.

Учитывая это а также и недетерминизм, вносимый: a)внешним для VM скедулером и б)IO (который в идеале не должен быть блокирован) - это и в случае одного проца может быть более эффективно (чем бежать всем тредам внутри одного процесса). Потом больше процессов - больше ухватим внимания со стороны скедулера ;-) (с последним - опять куча неизвестных, например - какой алгоритм использует. Имею в виду разные системы: ведь сан как и другие здравомыслящие вендоры хотят иметь один source-tree). Т.е. больше недетерминизма - оно лучше (при большой сложности/неоднородности/непредсказуемости системы).

IMHO поэтому в последние годы и IBM и Sun делают нативные треды by default. И еще по нижеследующей причине.

> И, кстати, есть ли в J2SDK 1.4.2 for Linux green threads?

я думаю их убрали из-за: http://www.blackdown.org/java-linux/java2-status/security/Blackdown-SA-2002-0...

конечно, не помешало бы иметь и green ones - как опцию - для чисто гуёвых аппликух, но java позиционируется под линухом пока больше для IO - интенсивных аппликух (web) и поэтому имеем то что имеем.

А в том что треды легче у винды - так это же надо _всё_ замерить, включая IO, нетворк. (Что виндовые более лёгкие треды с IO тоже независимо работают?). Спарки вон тоже рядом не стоят - если только по тактовой частоте сравнивать ;-)

Anode

P.S. то что раньше писАлось под спарки и аиксы на жаве, сейчас стабильно (уже более 2 лет) работает исключительно под линухом (и с ибм-машинами и сановскими).

> раздрай между Java и MS

насколько я помню - раздрай начался когда MS не вставил RMI (и др) в свою SDK3 под IE5.0-beta (VM build 3??? ~ 1.1.[4-6]). Sun тогда шибко верил в будущее своего RMI, корбы там всякой, которая была на подходе. Залупился сан (взревновал и побоялся скорости с которой билли пошёл жаву оприходовать), разругался, и J++ так и повис в воздухе (а ведь те имели большие виды).

Anode

>и начинаю понимать, чем вы тут все занимаетесь...

Пипками тут народ мерятся. Talks ruleZZZZZ!

Во, блин, чертей повылазило! И орут как ошпаренные - видать жарко там... Ладно, отвечу, раз один из них наконецто оп-под-писался :)))

1. Green threads.

Сорри, прогнал - нет их больше в хотспотной jvm от сан. Нигде нет - ни в лин, ни в вин, ни в сол - все юзают нативные и в других jvm кажется тоже нет. Ура прогрессу! Последний раз игрался с зеленью года два назад, и выяснив, что нативные вполне годны к юзанью, больше не обращал на них внимания - вот и не заметил как они исчезли совсем... Выбор и тьюнинг jvm под аппликейшн делают после его разработки и это другая (не моя) работа.

2. VolanoMark & report

Любопытные бенчмарки, наблюдения и рассуждения, особенно для иллюстрации ситуации network troughput vs. max load. Мне как девелоперу это только для информации, но интересно. Ещё интереснее будет, когда они 1.4.2 промеряют на своей задаче.

Абсолютно лучшие результаты в VolanoMark показала BEA jvm для Win - видать, специально заточенная под конкретную систему и только на ней имеющая отличные результаты - на остальных у неё провал. Так обычно и бывает - достичь выдающейся результатов каких-то показательей удается только чем-то пожертвовав.

И общий вывод в Report'e от June 2, 2003 прямо в тему (см. Conclusions): "BEA JRockit 3.1 is no longer available, so the best Java platform today is Blackdown 1.3.1 on Linux." О как! :)

Это сейчас, с сегодняшними "ущербными", как утверждают некоторые, тридами - а ожидается, что nptl "promises to solve the problems of highly-threaded Java applications on Linux once and for all". Очень хорошо - но и текущая ситуация НЕПРИЕМЛЕМОЙ не является. И где же там проблемы с тридами в Линукс?!!!

3. Цитаты с другой ветки.

Эти цитаты никак не подтверждают утверждения что "speer тоже брызгал слюной и считал всех тех, кто не фанатик, ламерами криворукими,"

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

В той ветке какой-то анонимын (или анонимы) утверждали, что при попытке задеплоить какое-то их java-app на линух они обломались, потому что, проблема в вишь-ли в тридах или стеках, а Сан их послал использовать Солярис (а чего собственно от Сан'а то ожидать?!). Потому вроде выяснилось, что приложение они пытались портировать на линух с виндов (причем тут Солярис тогда, с которого всё началось)...

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

4. Problem with specific versions of the Linux glibc library and the JVM for Linux.

Это-то каким образом уличает Linux, speer'a и прочих "фанатиков" (опять аноним насмотрелся в своё отражение на экране) в "некачественности" чего-либо к ним относящегося?! Данное утверждение приводится Sun'ом в сопроводительной доке к jre - ну и чего в нем необычного-фатального? Масса программ требуют специфический версий от посторонних либ, с которыми им приходится работать и эти требования отражаются в их документации. Чего по этому поводу так колотится?

Вот схожий случай, но с другой системой (цитата из release_notes.html к JBuilder 8): "JBuilder hangs, crashes, or spontaneously reboots on Windows XP when using an ATI Radeon video driver" - заипись, правда? Это вам не вылет jvm из-за достижения системного лимита на число тредов, это бряк на ровном месте с крахом _всего_ к делу не относящегося и которого никак by-design быть не должно. Какие выводы прикажите делать?

5. По теме.

Ну так прав я или не прав, утверждая, что НЕТ никакого множества JVM когда работает java-программа с тридами под линухом, а показываемые ps'ом & Co процессы суть не отдельные полновесные форкнутые процессы, но процессы-триды с ОБЩИМ адресным пространством? И что данное обстоятельство (отдельные PIDы тридам), хоть и является posix-несовместимой _особенностью_ текущей реализации в этой системе, но никак не может считаться источником каких-либо фатальных проблем? Али есть системы _без_ особенностей?

2 speer

За публичное признание ошибки про green треды - вам респект.

Насчет тредов, реализованных c использованием процессов. Здесь анонимус-гаденыш прав, несмотря на его бескультурие и переходы на личности. Будьте превыше этого провокатора, и на самом деле почитайте книгу от соавторов GCC. Объективный и взвешенный анализ минусов Linux там содержится не только на страницах 92-93, но и на странице 112.

Незлобный анонимус.

PS. Когда же появятся модераторы?

2 speer

За публичное признание ошибки про green треды - вам респект.

Насчет тредов, реализованных c использованием процессов. Здесь анонимус-гаденыш прав, несмотря на его бескультурие и переходы на личности. Будьте превыше этого провокатора, и на самом деле почитайте книгу от соавторов GCC. Объективный и взвешенный анализ минусов Linux там содержится не только на страницах 92-93, но и на странице 112.

Незлобный анонимус.

PS. Когда же появятся модераторы?

Чё-то та сука пиздящая про дотНЕТ(НЕТ, и ненадо) изчезла, наверно уже в заглот взяла.

>>>Насчет тредов, реализованных c использованием процессов. Здесь анонимус-xxxx прав,

В чем прав? В том что у них есть недостатки? Да, есть. У любой конкретной реализации они всегда есть - идеального нет ничего, кроме дао. Но речь идет не об общих, а о конкретных вещах:

1. Анонимы утверждали, что из-за линуховых тридов у jvm для этой системы есть фатальные проблемы. Так вот, очень хочеться увидеть КАКИЕ и КОГДА - иначе это гон (aka FUD). Ведь по их собственным ссылкам выходит, что до тех пор пока системные лимиты не превышены (сознательным превышением лимитов можно завалить любую систему и любое приложение) - всё работает вполне также, как и на сравниваемых системах.

2. Анонимы (не в первый раз уже) утверждали, что под линухом многотридное java-аpp заводит множество виртуальных машин, чем создается колоссальных оверхед по всему и особенно по потреблению памяти. Данное утверждение является ошибкой вследствии грубой некомпетентности его распространителей. (Тоже самое и по тем же самым основаниям часто утверждается про другие тридные приложения под линухом - например про Mozilla)

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

>>>и на самом деле почитайте книгу от соавторов GCC

Это про "Программирование на Linux. Профессиональный подход"? Так читано ещё в оригинале... Только вот "минусов Linux" на этих страничках как-то не удаётся наковырять - только ОСОБЕННОСТИ. Может я чего не понимаю - тогда прошу любезно объяснить чего-нить... Вон Sun переделал свои триды поближе к линуховым - кто-то постил в предыдущей ветке.

>Может я чего не понимаю - тогда прошу любезно объяснить чего-нить

Позвольте мне немного изложить мнения уважаемых авторов, которых нельзя заподозрить в пристрастности.

1. Все-таки создаются через клонирование процесса, что "затратнее" чем в Windows. Волановские Java-тесты это наглядно показывают. За треды микрософт ухватился - держитесь.

2. Pthreads не соответствут POSIX.

3. Windows NT каналы поддерживают двунапрвленный обмен данными.

Как бы вам сказать, жигуленок тоже имеет "только особенности", но я предпочел бы BMW. :))

Незлобный анонимус.

>>>Все-таки создаются через клонирование процесса, что "затратнее" чем в Windows.

Что значит "создаются" и что значит "клонирование" по технической сути, а не по названию? Вновь создаются только структуры данных в ядре, обслуживающие новую нитку (поток) - это затратнее, но это однократная операция. Реальное клонирование родительского процесса в Linux по механизму copy-on-demand происходит как-раз при создание истинных процессов - для потоков этого не требуется, так как все работают в одном адресном пространстве - на то они и потоки.

Преимущество данного решения достаточно существенные - упрошение планировщика, об чём в комментариях Sun и рассказано...

>>>Pthreads не соответствут POSIX

За это штрафуют или уголовно преследуют? Соответствовать конечно лучше чем несоответствовать, но несоответствие несоответствию рознь - ну так в какой части и насколько это существенно для эффективности и как это мешает при написании программ, в том числе кросплатформенных? Если не рассматривать детали - то это утверждение оказывается пустой банальностью или fud'ом, в зависимости от целей произносящего.

Тут только что обсуждали, что GNUшный make как-бы тоже несоотвествует "unix-стандартам", однако по-мнению людей знающих, именно он обеспечивает наибольшую портабельность... (см. в конце ветки http://www.linux.org.ru/jump-message.jsp?msgid=335535 )

>>>3. Windows NT каналы поддерживают двунапрвленный обмен данными.

В win каналы вообще запроектировы существенно иначе чем в unix - это же другая система с иной архитектурой. Но принципиальных функциональных различий с точки зрения _вариантов_ организации межпроцессного взаимодейтсвия нет. В юнихах надо использовать несколько отностиельно простых абстракций - в вин можно одну, но сильно развесистую, при необходимости совмещения прибегают к враперам и либам, скрывающих детали...

PS. Может по теме есть что кому сказать? Мне вот всё хочется узнать когда и почему нельзя использовать java на Linux, что бы не напороться на уже известные грабли - в целях поднятия квалификации...

>это затратнее, но это однократная операция.

С затратностью мы с вами разобрались. Теперь порассуждаем об однократности. У нас на работе промышленные Java-системы в которых создается более 500 потоков на одном компе. Причем потоки как создаются, так и уничтожаются. Небольшой Java-сервер под Tomcat - идеальное решение, не спорю. Банковская система - спорно.

(Хотя для внешнего Web сервера я бы использовал Linux или *BSD Apache2 + mod_perl.)

согласно Volano report для масштабируемости линух сервера (сотни клиентов) надо ставить Blackdown 1.3.1 c "-green" (не забыть Tomcat подкрутить: maxProcessors и файл-дескрипторы разумеется - ограничивают всё равно). Но тогда - второй(+) проц. - не используется эффективно (если не чем их занять ;-)

Вот интересненькая статья
http://developer.java.sun.com/developer/technicalArticles/Programming/turbo/ убеждает в крайней полезности 1.4.1 - под более чем одним процем (паралельный GC: один камень не тормозит другие), но в той VM уже не будет scalability (я думаю что причина в дескрипторах - и там тоже) а там мне и не нужны эти 4G+ - всё равно надо на следующую машину переползать - из-за лимита по клиентам (запрос на апаче рассчитываю грубо 1+ сек).

Бежит у меня ещё 1.2.2 и 1.3 (недавно ещё 1.1 от IBM стояла - шустрые они) а по причине PJA сейчас не могу перейти на 1.4 (есть там проблема с headless).

Такой вопрос (для будущего): чем тратить на второй камень (с учётом вышеизложенного) - не лучше ли бюджет перераспределить на лучшие шины и более сильный главный камень - в случаях java да и linux в общем (на тест+счет пока руки не дошли).

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

Anode

>Java-системы в которых создается более 500 потоков на одном компе

на какой оси если не секрет?

>Причем потоки как создаются, так и уничтожаются

плохой дизайн - они должны пулится и реюзится.

>Небольшой Java-сервер под Tomcat - идеальное решение, не спорю. Банковская система - спорно >для внешнего Web сервера я бы использовал Linux

WebLogic за 10-ки килобаксов на проц. под линухом? Чем томкат, apche+jserv (если не jsp) не устраивают? JBoss наконец? Конкретно и по пунктам если можно (может я чего пропустил).

Anode

>надо ставить Blackdown 1.3.1 c "-green"

Да green threads создаются самой средой исполнения. Они шустрее. Но к сожалению, Sun не стала развивать g_t в сторону многопроцессорности, а полностью перешла на native_threads с J2SDK1.3.

>Ну вот видите, действительноплохой дизайн - они должны пулится и реюзится

Когда потоков мало, то да, я с вами полностью согласен. Но это здоровенные проводки и в большом числе.

В анонсах пишут, что в RH9 (и в ASP9) используется другая библиотечка для потоков. Еще пишут, что потому ява работает быстрее.

Кто-нибудь может поделится своим опытом?

Просто я использую ALT2.2 и ASP7.3. И мне интересно, насколько ява себя чувствует ущербнее на них, чем на том же ASP9? Если конечно такое дело имеет место быть...

наверное идёт речь о pthread либе (которая является частью glibc). В 2.4 ядре можно: 1) увеличить кол-во одновременно открытых файл-дескрипторов и 2)увеличить максимум для тредов изменением захардкоженного лимита в glibc/linuxthreads/internals.h Не знаю что редхатовцы там сделали, но вполне возможно и лимит на количество тредов заодно подняли и имеют в виду использование green (если ссылка не далеко - плиз).

Вообще - все неизвестные (размер мессаги, буфера, какое ядро, кол-во камней, имплементация сервера, имплементация сервлет-мотора, тип jvm, green или native итд) сильно взаимосвязаны и любая - может быть критической. Пример: в 2.2 kernel предел - кол-во pthread (1024) в процессе (например для green) и для количества файлов - 1000. И перформанс тест можно подогнать с любой стороны. К примеру - Volano используют loopback и какие-то мессаги (какие? как долго держут итд). А если Апач - всё поменяется и надо делать отдельный тест (причём для Apache 2 всё опять поменяется). Добавим Томкат или Jserv под апач - количество необходимых файл-дескрипторов удвоится (физически под 2.2 ядром не смогем иметь > ~400 клиентов).

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

Anode

2Anode: спасибо за ответ; к сожалению, ссылок под рукой нет, но эту новость в том или ином виде я встречал в нескольких местах, в том числе и на http://java.sun.com среди чатов Java Live

линуксы стоят у меня на десктопе вместе с win2000; поэтому мне было просто интересно, как эта новая библиотека может отразиться на гуевых приложениях типа Eclipse, NetBeans и т.д.

давид

Повторю свой вопрос который меня очень интересует и буду благодарен за любой совет: допустим имеем фиксированный бюджет на железо под линух сервак. Стоит ли ставить 2ой процессор (jvm1.4 + нативные треды - см постинг выше) или лучше увеличить главный за те же деньги и пустить грины на нём под jvm1.3?

Для простоты возьмём любой сильно загруженный многотредовый сервер не на жаве (при условии, конечно, что высвобожденные деньги будут использованы на мамку например) - есть такой опыт у кого?

2давид

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

Кто сталкивался с приколом в последние дни при выкачивании sdk изменился размер файла. У меня было выкачано 70 процентов. Что это за херня от Sun-узла. Или они считают что 40 метров качается за час, у меня был треьий день закачки.

>>>Да green threads создаются самой средой исполнения. Они шустрее.

Не всегда, понятное дело. В них ещё есть нечто от кооперативной многозадачности в стиле ранних win/mac - переключения происходят не жестко по тикам, а там где текущий трид МОЖНО приостановить и переключиться на другой, то есть всё очень неравномерно и впрямую зависит от исполнямого кода. Значит можно накодить так, что тридиться данное конкретное приложение будет очень плохо - зависит от стиля-квалификации программиста (и от jvm!)...

>>>Но к сожалению, Sun не стала развивать g_t в сторону многопроцессорности, а полностью перешла на native_threads с J2SDK1.3.

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