LINUX.ORG.RU

Java taints kernel


0

0

Спецификация реального времени для Java (RTSJ) требует предоставления виртуальной машине неограниченного доступа к физической памяти компьютера. При этом некорректная работа Java-программы может привести к непредсказуемым последствиям.

Предлагается в подобных случаях (также как при загрузке закрытых драйверов от ATI и Nvidia) устанавливать флаг TAINT, чтобы предупредить пользователя что стабильность системы находится целиком и полностью на совести Java-программистов.

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

★★★

Проверено: Shaman007 ()

Новость-то не новость, а так... Ну хочет некто Ted флаг taint менять от пользователя, но кто ему даст? :-)

Там же дальше в переписке и решение написано - написать свой модуль и устанавливать флаг при его загрузке. и всего-то.

Кто б еще объяснил - зачем для тестирования системы RTSJ может потребоваться доступ к /dev/mem??? Ну отключил бы swap и радовался. Нет, блин, все норовят ядро пропатчить "под свои нужды". Тфу на таких.

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

Гнать такую яву. Она не предназначена для серьёзных задач, типа управления ядерными реакторами... ;-))) И здесь нечего. :)

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

> А как жаба может быть realtime? Она свой gc отключает, что ли?

Они просто время реакции подняли до двух суток.

Систему управления вращением галактики такое время реакции вполне устраивает :)

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

> А как жаба может быть realtime? Она свой gc отключает, что ли?

Всё верно. Через сколько там лет наконец-то ява годится для кофеварок. Сразу же появятся заявления, что в Java изначально была заложена real-time фича.

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

Правда, это не тот случай :)

>Q: Does Java RTS use a real-time garbage collector?

>This release of Java RTS will not include a real-time GC. We expect the first update to include real-time GC algorithms from Lund University.

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

Зачем столько необоснованных нападений на Java? Кто-нибудь из Вас, может быть, написал хотя бы одну программу на этом языке? Да собственно на любом. Ничего кроме Basic, наверное, в глаза не видели!

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

Чего тогда стоит Java если ей страшны такие нападения? .. Или писание на глазах любимой жабы возбуждает материнские инстинкты? :)

NiKel
()

>Спецификация реального времени для Java (RTSJ)

уже смешно

>требует предоставления виртуальной машине неограниченного доступа к физической памяти компьютера.

внимание, вопрос: и нафуя тут жаба? =)

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

>Ядро с жабой нужно собирать без ключа -Wall, я правильно понял?

Отчего же? Именно с -Wall и с -Tommy

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

>This release of Java RTS will not include a real-time GC. We expect the first update to include real-time GC algorithms from Lund University.

Бог мой, что ж она с памятью тогда творит? Или ей надо периодически давать передышку, чтоб она мусор собрала?

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

> Зачем столько необоснованных нападений на Java? Кто-нибудь из Вас, может быть, написал хотя бы одну программу на этом языке? Да собственно на любом. Ничего кроме Basic, наверное, в глаза не видели!

Я не против крупных проектов на java - там нужен язык для быдла, программа и так жрёт охренеть памяти, а тормоза gc на фоне тормозов самого приложения не так заметны. Но, блин, runtime...

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

Поздравляю анонмуз, java живет в успешно функционирующих американских марсаходах, и используют ее там потаму что программа может сама восстановиться поймав эксепшн, поймай bufferoverflow в С/C++ ... даже если поймаешь с помощью какого-нибудь костыля - останется еще гигантский список ... когда научишься все ловить то у тебя будет не с++ а java или с#

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

Господа, если вы нихрена не знаете о JVM, то лучше бы помалкивали.
В различных JVM содержится от 1 до 6-7 разных настраиваемых алгоритмов для сборки мусора реализованных как GC. Среди них есть несколько realtime GC, которые собирают мусор так же, как если это сделает написанный программистом деструктор, а бывает и _получше_. И что самое главное - в нужное время и без тормозов.
Да, по умолчанию большинство JVM настроено на работу с другими типами GC, там где не нужна реалтаймовость, можно потратить и 2 секунды в час на сборку мусора. При этом пока в куче есть место, память для новых объектов выделяется очень быстро.

Короче, мораль такова: не знаешь - не пи**и.

anonymous
()

хаха, так вот что погубило ТОММИ!!!!!!!!!

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

> java живет в успешно функционирующих американских марсаходах, и используют ее там потаму что программа может сама восстановиться поймав эксепшн, поймай bufferoverflow в С/C++ ...

Не флейма ради, а для информации. Насколько я помню, в c.l.l в свое время Erann Gat (для справки, он работал в то время в JPL) писал, что на борту марсоходов был "компот" из нескольких языков, в т.ч. и C++.

--

SVK

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

>Ну, в Delphi я могу exceptions обрабатывать, и что? :)

Когда поймешь о чем дядя сказал - приходи.

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

ну так добавь к ней JCP(Standatdization), GC , кросплатформенность исполняемого кода , и сишный синтаксис - получишь java

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

кто спорит то ? конечно то что призвано пасти и обновлять версии java-прог наверное написано на чем-нибудь с более прозрачным(без VM и других зависимостей) behaviour.

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

Nu esli kto ne znaet Real Time Java uzhe neskol'ko let kak suschestvuet... Naschet GC - imenno. Pamyat' delitsya na 2 tipa - s GC i bez nego (s destructor). Real-Time chast' krutitsya v permanent pamyati, a vsyakaya fignya tipa GUI s GC. Bolee togo thread'y tozhe peredelali (est' svoj sobstvennyj Real-Time thread class). Naschet nasmeshek, nu pozhivem uvidim - esli kto ne znaet est' takaya malen'kaya kontora Boing, kotoraya vypuskaet bespilatnye samolety kak raz pod upravleniem RTSJ...

Regards,

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

Осиль сначала локализацию своей слаки, а потом делай какие-либо заявления (например Патрег - бох). Тебя читать неприятно - полное неуважение к окружающим.

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

>java живет в успешно функционирующих американских марсаходах, и используют ее там потаму что программа может

Весь софт в марсоходах написан на C и работает под VxWorks на RAD6000 процессоре. Дальнейший бред начиная с "потаму что" может вызвать только жалость.

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

>А как жаба может быть realtime? Она свой gc отключает, что ли?

Там пул аллокатор. Гц-а нет.

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

>Зачем столько необоснованных нападений на Java?

Ну почему необоснованных? Жаба была бы отличной штукой если бы софт на ней написанный не жрал столько ресурсов (цпу, озу) - причем впустую. Да и то ничего - не хочешь не используй. Однако раздражают воинствующие фанатики, которые хотя и есть в группе почитателей любого языка, однако среди жабофилов их особенно много (видимо связано с простотой самого языка - что несомненно плюс языку) и их замечания типа - а у меня ничего не тормозит и память не жрет и т.п.

anonymous
()

Когда ж люди научатся отличать спеки от reference implementation?...

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

>В различных JVM содержится от 1 до 6-7 разных настраиваемых алгоритмов для сборки мусора реализованных как GC.

Тогда расскажите как в sun jvm заюзать realtime gc (а лучше не один, а "несколько"). Правда интересно.

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

Деструктор к сборке мусора перпендикулярен. Таких волшебных (а иначе как он определит "нужное время"?) гц не существует к сожалению. Есть вероятность что хороший гц можно зделать, однако он должен работать в тесной кооперации с системой управления VM операционной системы.

>Да, по умолчанию большинство JVM настроено на работу с другими типами GC,

Ну конечно - кому нужна сборка мусора "в нужное время и без тормозов"!

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

На хипе ~1.5G IBM-овцы получили до 50 секунд остановки мира при дефрагментации хипа. Хотя для некоторых это быстро.

>При этом пока в куче есть место, память для новых объектов выделяется очень быстро.

Безспорно. Однако владение большим хипом имеет большую цену в виде memory fault, TLB miss.

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

> Ну почему необоснованных? Жаба была бы отличной штукой если бы софт > на ней написанный не жрал столько ресурсов (цпу, озу) - причем
> впустую. Да и то ничего - не хочешь не используй. Однако раздражают > воинствующие фанатики, которые хотя и есть в группе почитателей
> любого языка, однако среди жабофилов их особенно много (видимо
> связано с простотой самого языка - что несомненно плюс языку) и их
> замечания типа - а у меня ничего не тормозит и память не жрет и т.п.

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

Меня, например, раздражают воинствующие фанатики из другого лагеря, которые зачастую не написав на яве и строчки(а бывает не зная и других языков) обвиняют её во всех своих бедах.

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

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

>Можно то же самое сказать почти про любой язык, на котором пишутся более-менее серьёзные вещи.

Конечно нет. Есть конечно хорошие программы и плохие программы, однако overhead в жаба - это ее генетический признак.

>а, Java-программы обычно требовательнее к ресурсам системы, но это вполе логично,

Логично это или нет - пользователю фиолетово. Так же фиолетова ему и "кроссплатформенность".

>т.к. для выполнения нужна прослойка между программой и ОС - виртуальная машина, работающая с байт-кодом.

Плюс jit и гц.

>но его можно легко преодолеть скомпилировав байт-код в бинарники с помощью соответствующих утилит.

А я полагал что веду беседу с взрослым человеком. Закругляюсь.

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

> Тогда расскажите как в sun jvm заюзать realtime gc (а лучше не
> один, а "несколько"). Правда интересно.

http://www.petefreitag.com/articles/gctuning/
Тут общие рекомендации по тюнингу JVM, также обсуждаются и мусорщики.

> Ну конечно - кому нужна сборка мусора "в нужное время и без тормозов"!

Как ни странно, не всегда нужна. Есть приложения, которые до 90% времени могут проводить в спячке - зачем такому приложению парочка лишних висящих тредов-коллекторов?

> На хипе ~1.5G IBM-овцы получили до 50 секунд остановки мира при
> дефрагментации хипа. Хотя для некоторых это быстро.

Странное приложение какое-то, видать создаёт много мелкого дерьма(плохо написано?) при своей работе, что нужно столько собирать.
И опять же - это как я понял на обычно train коллекторе, который тупо проходит по хипу при необходимости. Кроме этого, я уверен IBM использовала свою JVM в тестах, которая ну никак не является стандартом.
У меня, увы доступа к такому хипу не было, чтобы проверить, но на хипе в 512Мб могу сказать задержки при сборке мусора составляли не более 5 секунд на машине 2.8Ггц с обычным коллектором.
После тюнинга JVM это время сократилось до 1 секунды.
При использовании параллельного коллектора, использование хипа вообще редко достигало 80%, а сборок мусора хоть и стало больше, но реактивность системы при этом улучшилась.

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

> Конечно нет. Есть конечно хорошие программы и плохие программы, > однако overhead в жаба - это ее генетический признак.

и я объяснил почему.

> Логично это или нет - пользователю фиолетово. Так же фиолетова ему > и "кроссплатформенность".

Я пользователь, я хочу пользоваться привычными\любимыми\удобными программами не зависимо от ОС, которая сейчас загружена.

> Плюс jit и гц. Это всё относится к "прослойке"

> А я полагал что веду беседу с взрослым человеком. Закругляюсь.

Загругляйтесь я тоже буду, но только сначала снизойдите до уровня моего дестского лепета и объясните мне, уважаемый апологет удобства пользователей, не будет ли для пользователя средней тупости удобнее и понятнее "нажать на файлик с расширением *.ехе ", нежели скачивать JRE(если нужно) и ещё что-то(может быть) донастраивать.

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

> У меня, увы доступа к такому хипу не было, чтобы проверить, но на хипе в 512Мб могу сказать задержки при сборке мусора составляли не более 5 секунд на машине 2.8Ггц с обычным коллектором.

Иногда случается так, что часть хипа валяеся в свопе. Тогда и случается самая крупная жопа с page fault

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

> Я пользователь, я хочу пользоваться привычными\любимыми\удобными программами не зависимо от ОС, которая сейчас загружена.

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

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

>To bish nikakih real-time ne nado, esli collector ukladyvaetsya v 10ms...

Я плакал... WebLogic - и это реальное время?

> V Lyubom sluchae real-time eto ne skorost', a predskazuemost'...

Насчет предсказуемости: извини за резкость, но это любимая отмазка людей, которые недавно узнали определение "реального времени". Время реакции не менее важно. Тормознутые системы реального времени просто не нужны.

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

> Бугога, рассмешил. Назови хоть одну любимую прогу на жабе, которая не имеет частей, зависимых от ОС?

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

Не привязана к ОС из того, чем я пользуюсь Eclipse, а также Tomcat.
Заметь, обе вещь Open source - не это ли мы здесь приветствуем?

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

> Бугога, рассмешил. Назови хоть одну любимую прогу на жабе, которая не имеет частей, зависимых от ОС? OpenOffice, StarOffice?

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

> OpenOffice, StarOffice?

В OpenOffice кода на жабе - единицы процентов. Думай дальше. И зависимых от ОС частей в нём куча.

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

>Тут общие рекомендации по тюнингу JVM, также обсуждаются и мусорщики.

Да насрать на это. Кое кто утверждал <quote> Среди них есть несколько realtime GC </quote> Просьба была показать, как использовать rt gc в суновской jvm.

>Странное приложение какое-то, видать создаёт много мелкого дерьма(плохо написано?) при своей работе, что нужно столько собирать.

Мля! Много мелких объектов ни не проблема для гц. Проблема в другом. Два раза мля! Программа, создающая много объектов не есть плохая программа! Это в детском саду уже знают!

>И опять же - это как я понял на обычно train коллекторе, который тупо проходит по хипу при необходимости.

Тупо - не один precise коллектор по хипу не проходит. Это делает только консервативные гц. Да и то не тупо и не по всему хипу.

>У меня

А у нас в квартире кошка, родила вчера котят ...

P.S.

Особенно понравился перл про увеличение реактивности системы.

Аффтар пеши есче!

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

>Загругляйтесь я тоже буду, но только сначала снизойдите до уровня моего дестского лепета и объясните мне, уважаемый апологет удобства пользователей, не будет ли для пользователя средней тупости удобнее и понятнее "нажать на файлик с расширением *.ехе ", нежели скачивать JRE(если нужно) и ещё что-то(может быть) донастраивать.

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

Однако это еще не все. Недавно были выпущены спеки т.н. "JVMTM Tool Interface" (http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html) так вот там есть секция "Bytecode Instrumentation" где есть такие слова:

Dynamic Instrumentation: A class which is already loaded (and possibly even running) is modified. This optional feature is provided by the RedefineClasses function. Classes can be modified multiple times and can be returned to their original state. The mechanism allows instrumentation which changes during the course of execution.

Грязный хак узаконен! Как говорится без комментариев!

Надеюсь мой пойнт понятен. Теперь точно закругляюсь.

Успехов.

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

>Бог мой, что ж она с памятью тогда творит? Или ей надо периодически давать передышку, чтоб она мусор собрала?

Самолет должен летать без передышки, тем более беспилотный самолет. http://www.linux.org.ru/jump-message.jsp?msgid=977226#978831

>Короче перевожу для неграмотных: Боинг уже эксплуатирует рил-тайп аппликухи под Жаву

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

>Логично это или нет - пользователю фиолетово. Так же фиолетова ему и "кроссплатформенность".

Не фиолетова. Вот Omea невозможно запустить и пользоваться под Linux, только если под wine. Тем самым разработчики принуждают пользователя купить проприетарную платфому для своей программы. А если бы Omea написали на Java ее смогли бы купить пользователи Linux

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