Вышла новая версия JNode 0.2.6

anonymous (27.02.2008 11:48:05):

1. значит теора все таки будет вызывать переключение user/kernel mode?

2. потянет ли микроядро из 4 файлов вашу идею?

3. и главное чем вся эта баяда лучше linux live CD ?

anonymous (27.02.2008 11:48:05): но по сути жабка именно так и юзается щас -- для скриптования тяжелых либов. Только непонятно зачем ее пихать в ядро (выполнение жабы в том же user-kernel-mode что и ядро я считаю запихиванием в ядро). Может кто объяснит...?

"anonymous (27.02.2008 11:48:05)" означает что я отвечаю _тому_ анонимусу

> Fice, ссылочку пожалуста.... померю во сколько раз тормозит. Ссылку только из ваших рук или рук r, а то потом любители явы упрекать будут. Уточните, это обертка вокруг libtheora0 или прямо-таки код на яве?

"Прямо на яве"
http://www.flumotion.net/cortado/

Но я этим никогда не пользовался, поэтому ничего про производительность сказать не могу. Где-то ещё другие реализации встречались.

> Мелкое замечание насчет безопасности -- у меня ява каждую неделю (или чаще) падает и уносит за собой фаерфокс под виндой. Сохраняет hs_err_pid####.log (штук двадцать лежит уже в одном месте). А винда при этом почему-то не падает.... Суперская у VM безопасность, ага. Я как-то больше доверяю аппаратной защите процессов.

Скорее всего, проблема в самом плагине - в библиотеке, которая обеспечивает взаимодействие браузера с JVM.

> А на чем ява разжимает jpeg и mp3? Таки тоже на байткоде?

Если не ошибаюсь, то да, на байткоде. По крайней мере, встроенная поддержка jpeg должна быть на байткоде. Теоретически, для вычислительных задач, производительность сравнимая с native code достижима в Java bytecode за счет JIT-компилятора (где-то были примеры).

> А что мне еще нужен кодек WMV или H.264? Или какой еще законно приобретенный?

Найти на Java. Если нет, найти на C и переписать на Java.

> Так... допустим что нужная мне библиотека все же есть в исходниках... и какая-то муха укусила меня и я переписал либтеору на яве... Что я буду после этого иметь? Чем это лучше линуха на live CD?

В смысле? Причем тут live cd?

>"Прямо на яве" http://www.flumotion.net/cortado/

>Но я этим никогда не пользовался, поэтому ничего про производительность сказать не могу. Где-то ещё другие реализации встречались.

ок, сравнить есть что, хотя cortado содержит ТОЛЬКО декодер.

>> А на чем ява разжимает jpeg и mp3? Таки тоже на байткоде?

>Если не ошибаюсь, то да, на байткоде. По крайней мере, встроенная поддержка jpeg должна быть на байткоде. Теоретически, для вычислительных задач, производительность сравнимая с native code достижима в Java bytecode за счет JIT-компилятора (где-то были примеры).

Щас скачиваю исходинки явы, буду смотреть... но сдается мне что там С.

>> А что мне еще нужен кодек WMV или H.264? Или какой еще законно приобретенный?

>Найти на Java. Если нет, найти на C и переписать на Java.

Суровые вы ребята... че, реально микрософт заставить переписать WindowsMediaVideo кодек на яве?

>> Так... допустим что нужная мне библиотека все же есть в исходниках... и какая-то муха укусила меня и я переписал либтеору на яве... Что я буду после этого иметь? Чем это лучше линуха на live CD?

>В смысле? Причем тут live cd?

Топик -- jnode -- и его я назвал "это". Так вот чем jnode лучше линуха на live CD?

>Так вот чем jnode лучше линуха на live CD?

Вы жжоте, может будите сравнивать аналоги, а не палец с жопой?

> Суровые вы ребята... че, реально микрософт заставить переписать WindowsMediaVideo кодек на яве?

Ну под Linux их тоже не заставишь это выпустить.

> Топик -- jnode -- и его я назвал "это". Так вот чем jnode лучше линуха на live CD?

JNode - концепт операционной системы. Находится в разработке и ещё не готов для реального использования, но потенциально имеет разные преимущества над ОС, которые используются сейчас. Linux на live cd - то, с чем сейчас можно работать. Как их сравнивать?

>> Суровые вы ребята... че, реально микрософт заставить переписать WindowsMediaVideo кодек на яве?

>Ну под Linux их тоже не заставишь это выпустить.

... но можно заставить работать, чем MPlayer успешно занимается -- запускает виндовую dll. Что планирует в таком случае делать jnode?

и как, и wine тоже будем переписывать на яве ????? или запустим wine в едином режиме kernel-user-mode ?????

>> Топик -- jnode -- и его я назвал "это". Так вот чем jnode лучше линуха на live CD?

>JNode - концепт операционной системы. Находится в разработке и ещё не готов для реального использования, но потенциально имеет разные преимущества над ОС, которые используются сейчас. Linux на live cd - то, с чем сейчас можно работать. Как их сравнивать?

...ок, когда этот концепт будет наконец готов, какое от него будет преимущество над Linux на live cd?

>>Так вот чем jnode лучше линуха на live CD?

>Вы жжоте, может будите сравнивать аналоги, а не палец с жопой?

Объясните глупому анонимусу, с чем я должен сравнивать jnode? Мне по моей природной тупости казалось, что аналогом является другая ОС, например Линукс, а еще мне казалось, что уже в концепте должны вырисовываться какие-то преимущества...

Так уж просветите, будьте добры...

>>Так вот чем jnode лучше линуха на live CD?

>Вы жжоте, может будите сравнивать аналоги, а не палец с жопой?

вполне корректное сравнение. Берём ядро линуха, busybox, прикручиваем какой-то обкоцаный Xfb (TinyX или как там), ставим туда официальный JDK. То на то и выйдет, если считать образ целевой системы. И не факт что JNode будет эффективнее в байтах (по крайней мере, память оно жрать будет поболее).

хотя хватит и JRE.

>с чем я должен сравнивать jnode? Мне по моей природной тупости казалось, что аналогом является другая ОС,

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

А еще анонимусу полезно перестать троллить.

а с линух-ядром у нас хоть OpenGL "из каропки" работать будет :)) и чем сабж эффективнее?

>>с чем я должен сравнивать jnode? Мне по моей природной тупости казалось, что аналогом является другая ОС,

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

>А еще анонимусу полезно перестать троллить.

Нет, о мудрейший. Позволь мне и дальше задавать свои глупые вопросы, глядишь, и поуменю :-)

Колибри помещается на дискетку 1.44, за то ей очень многое можно простить. А jnode?

Впрочем, может мудрейший заодно просветит анонимуса зачем нужна колибри? Че от нее ждать такого-этакого в будущем?

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

А ведь так хочется услышать о прям таки многочисленных преимуществах концепта новой ОС... и ли как в ней виндовые проги пойдут? или хотя бы кодеки?

> Объясните глупому анонимусу, с чем я должен сравнивать jnode?

1) можно сравнивать JNode с Singularity, Inferno и т.п.
2) можно сравнивать ОС с приложениями в управляемом коде (в общем) с прочими ОС (сравнивать сами концепции построения ОС).

> Мне по моей природной тупости казалось, что аналогом является другая ОС, например Линукс, а еще мне казалось, что уже в концепте должны вырисовываться какие-то преимущества...

Про преимущества здесь уже было:
1) Возможности для улучшения производительности за счет отсутствия переключения режимов ядра / пользователя. Есть возможности для более эффективного межпроцессного взаимодействия. Какие-нибудь ещё преимущества за счет использования единого адресного пространства.
2) Лучшая переносимость.
3) Безопасность.

>> Мне по моей природной тупости казалось, что аналогом является другая ОС, например Линукс, а еще мне казалось, что уже в концепте должны вырисовываться какие-то преимущества...

>Про преимущества здесь уже было:

и когда там появятся драйвера на Яве под nVidia с OpenGL? :P

> и ли как в ней виндовые проги пойдут? или хотя бы кодеки?

В этом то и состоит барьер, препятствующий переходу на принципиально новые ОС.

Благодаря тому, что в JNode используется JVM и поддерживаются стандартные Java API, база приложений под эту ОС уже достаточно велика.

Когда JNode достигнет определенного уровня развития, её вполне можно будет использовать для запуска, например, сервера Tomcat.

> как в ней виндовые проги пойдут? или хотя бы кодеки?

> и когда там появятся драйвера на Яве под nVidia с OpenGL? :P

А если бы все рассуждали так же, Linux никогда не достиг бы нынешнего уровня развития и популярности.

>1) можно сравнивать JNode с Singularity, Inferno и т.п.

minix3 тоже не готов до конца, поэтому я буду сравнивать jnode с миникс3, если линукс в этом треде не кошерен, хорошо?

>Про преимущества здесь уже было: >1) Возможности для улучшения производительности за счет отсутствия переключения режимов ядра / пользователя. Есть возможности для более эффективного межпроцессного взаимодействия. Какие-нибудь ещё преимущества за счет использования единого адресного пространства. >2) Лучшая переносимость. >3) Безопасность.

1) насчет потерь при переключении контекста -- я не только готов терпеть те потери, что дает линукс, но и увеличить до 5-10% (это миникс3), но за это получить возможность запускать драйвера сервисами -- что и называется микроядром (а не запихивание туда жабы)

Если интересно то и по плоской модели памяти пройдусь.

2) переносимость может быть переносимостью системы, переносимостью ява приложений и переносимостью бинарных приложений. А) переносимость JRE хуже чем переносимость ядра линукс или ядра миникс3

Б) переносимость ява приложений в любую систему с JRE одинакова

В) переносимость бинарных апликух типа wine & wmv кодек в jnode вообще никакая, а в миникс -- вполне реально, ибо он POSIX compliant.

3) тот большой-большой С код который почему-то громко называется JVM не может защищать процессы лучше чем микроядро мникса3 (under 4000 lines of executable code) + аппаратная защиа проца

>> и когда там появятся драйвера на Яве под nVidia с OpenGL? :P

>А если бы все рассуждали так же, Linux никогда не достиг бы нынешнего уровня развития и популярности.

Ты прав в том, что новое надо развивать. Но если нового много (jnode, minix3, MenuetOS/Colibri, Inferno, ... ) то развивать надо наиболее перспекивное -- а для этого надо обсуждать и то, как там будут сделаны драйвера nVidia с OpenGL.

Кстати, в миникс я думаю их не такая проблема перенести как в яву.

>> как в ней виндовые проги пойдут? или хотя бы кодеки?

>> и когда там появятся драйвера на Яве под nVidia с OpenGL? :P

>А если бы все рассуждали так же, Linux никогда не достиг бы нынешнего уровня развития и популярности.

Заметь, что я не спрашивал "когда", я спрашивал "как". И это важно.

Может у кого есть идеи, но насколько я понял, _без_отказа_от_преимуществ_новой_ОС_в ней_кодек_wmv_не запусить_ -- и мне уже не важно когда.

Эта ОС для запуска виндовых приложений или даже флешового плагина должна стать обычным или даже плохим линуксом -- тогда зачем она вообще?

> minix3 тоже не готов до конца, поэтому я буду сравнивать jnode с миникс3, если линукс в этом треде не кошерен, хорошо?

Я предлагал для сравнения Singularity и Inferno потому, что это тоже системы с управляемым кодом. Minix3 - нет.

> тот большой-большой С код который почему-то громко называется JVM не может защищать процессы лучше чем микроядро мникса3

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

>>> и когда там появятся драйвера на Яве под nVidia с OpenGL? :P
>>А если бы все рассуждали так же, Linux никогда не достиг бы нынешнего уровня развития и популярности.
>Заметь, что я не спрашивал "когда", я спрашивал "как". И это важно.

Путем переписывания его с нуля на Java. Так же и кодеки. Другой вопрос, как заставить производителей это сделать?

>> Может, в будущем, когда (если) managed-языки станут реальным мэйнстримом - но не сейчас.

> А что сейчас реальный майнстрим?

Если судить по моему ноутбуку - компилируемы в родной код Си и Си++.

> Путем переписывания его с нуля на Java. Так же и кодеки. Другой вопрос, как заставить производителей это сделать?

А зачем заставлять их это делать? Где и в чем выгода? Заменить аппаратный MMU на его (практически) эмуляцию? Это смешно.

Так в чем преимущество managed OS?

Вспомнил ещё про некоторые преимущества:

Упрощается установка ПО:
1) Не нужно пересобирать программу для оптимизации под конкретный процессор. Оптимизировать будет JIT.
2) Для компиляции чего-нибудь из исходников не нужны заголовочные файлы: достаточно только бинарных библиотек.
3) Динамическая компоновка: при отсутствии какой-то библиотки программа может работать, пока не попытается загрузить класс, использующий эту библиотеку. При этом произойдет нефатальная ошибка (работа приложения может быть продолжена). Гораздо легче создавать модульные приложения.

Fice, взгляни разок на JRE, хорошо? Этот огромный С код громко называют VM:

jdk1.6.0_10/jre/lib/i386: 5,938,274 bytes in 40 files

drwxr-xr-x 2 mle3 mle3 4096 Feb 27 15:46 client drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 headless drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 jli -r--r--r-- 1 mle3 mle3 689 Feb 19 12:37 jvm.cfg -rwxr-xr-x 1 mle3 mle3 71163 Feb 19 12:58 libJdbcOdbc.so -rwxr-xr-x 1 mle3 mle3 12462 Feb 19 12:58 libattach.so -rwxr-xr-x 1 mle3 mle3 588744 Feb 19 12:58 libawt.so -rwxr-xr-x 1 mle3 mle3 403679 Feb 19 12:58 libcmm.so -rwxr-xr-x 1 mle3 mle3 180433 Feb 19 12:58 libdcpr.so -rwxr-xr-x 1 mle3 mle3 273546 Feb 19 13:01 libdeploy.so -rwxr-xr-x 1 mle3 mle3 18694 Feb 19 12:58 libdt_socket.so -rwxr-xr-x 1 mle3 mle3 648027 Feb 19 12:58 libfontmanager.so -rwxr-xr-x 1 mle3 mle3 222057 Feb 19 12:58 libhprof.so -rwxr-xr-x 1 mle3 mle3 46135 Feb 19 12:58 libinstrument.so -rwxr-xr-x 1 mle3 mle3 19910 Feb 19 12:58 libioser12.so -rwxr-xr-x 1 mle3 mle3 39833 Feb 19 12:58 libj2gss.so -rwxr-xr-x 1 mle3 mle3 11760 Feb 19 12:58 libj2pcsc.so -rwxr-xr-x 1 mle3 mle3 66464 Feb 19 12:58 libj2pkcs11.so -rwxr-xr-x 1 mle3 mle3 6434 Feb 19 12:58 libjaas_unix.so -rwxr-xr-x 1 mle3 mle3 189159 Feb 19 12:58 libjava.so -rwxr-xr-x 1 mle3 mle3 25431 Feb 19 12:58 libjava_crw_demo.so -rwxr-xr-x 1 mle3 mle3 80875 Feb 19 13:01 libjavaplugin_jni.so -rwxr-xr-x 1 mle3 mle3 268961 Feb 19 13:01 libjavaplugin_nscp.so -rwxr-xr-x 1 mle3 mle3 271056 Feb 19 13:01 libjavaplugin_nscp_gcc29.so -rwxr-xr-x 1 mle3 mle3 5405 Feb 19 12:58 libjawt.so -rwxr-xr-x 1 mle3 mle3 278377 Feb 19 12:58 libjdwp.so -rwxr-xr-x 1 mle3 mle3 211066 Feb 19 12:58 libjpeg.so -rwxr-xr-x 1 mle3 mle3 8190 Feb 19 12:58 libjsig.so -rwxr-xr-x 1 mle3 mle3 235601 Feb 19 12:58 libjsound.so -rwxr-xr-x 1 mle3 mle3 80797 Feb 19 12:58 libjsoundalsa.so -rwxr-xr-x 1 mle3 mle3 33900 Feb 19 12:58 libmanagement.so -rwxr-xr-x 1 mle3 mle3 831403 Feb 19 12:58 libmlib_image.so -rw-r--r-- 1 mle3 mle3 5331 Feb 19 12:58 libnative_chmod.so -rw-r--r-- 1 mle3 mle3 5315 Feb 19 12:58 libnative_chmod_g.so -rwxr-xr-x 1 mle3 mle3 95830 Feb 19 12:58 libnet.so -rwxr-xr-x 1 mle3 mle3 37081 Feb 19 12:58 libnio.so -rwxr-xr-x 1 mle3 mle3 68254 Feb 19 13:01 libnpjp2.so -rwxr-xr-x 1 mle3 mle3 12931 Feb 19 12:58 libnpt.so -rwxr-xr-x 1 mle3 mle3 4902 Feb 19 12:58 librmi.so -rwxr-xr-x 1 mle3 mle3 37919 Feb 19 12:58 libsaproc.so -rwxr-xr-x 1 mle3 mle3 266365 Feb 19 12:58 libsplashscreen.so -rwxr-xr-x 1 mle3 mle3 141709 Feb 19 12:58 libunpack.so -rwxr-xr-x 1 mle3 mle3 56701 Feb 19 12:58 libverify.so -rwxr-xr-x 1 mle3 mle3 76374 Feb 19 12:58 libzip.so drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 motif21 drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 native_threads drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 server drwxr-xr-x 2 mle3 mle3 4096 Feb 19 14:44 xawt

Fice, взгляни разок на JRE, хорошо? Этот огромный С код громко называют VM:

jdk1.6.0_10/jre/lib/i386: 5,938,274 bytes in 40 files

drwxr-xr-x  2 mle3 mle3   4096 Feb 27 15:46 client
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 headless
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 jli
-r--r--r--  1 mle3 mle3    689 Feb 19 12:37 jvm.cfg
-rwxr-xr-x  1 mle3 mle3  71163 Feb 19 12:58 libJdbcOdbc.so
-rwxr-xr-x  1 mle3 mle3  12462 Feb 19 12:58 libattach.so
-rwxr-xr-x  1 mle3 mle3 588744 Feb 19 12:58 libawt.so
-rwxr-xr-x  1 mle3 mle3 403679 Feb 19 12:58 libcmm.so
-rwxr-xr-x  1 mle3 mle3 180433 Feb 19 12:58 libdcpr.so
-rwxr-xr-x  1 mle3 mle3 273546 Feb 19 13:01 libdeploy.so
-rwxr-xr-x  1 mle3 mle3  18694 Feb 19 12:58 libdt_socket.so
-rwxr-xr-x  1 mle3 mle3 648027 Feb 19 12:58 libfontmanager.so
-rwxr-xr-x  1 mle3 mle3 222057 Feb 19 12:58 libhprof.so
-rwxr-xr-x  1 mle3 mle3  46135 Feb 19 12:58 libinstrument.so
-rwxr-xr-x  1 mle3 mle3  19910 Feb 19 12:58 libioser12.so
-rwxr-xr-x  1 mle3 mle3  39833 Feb 19 12:58 libj2gss.so
-rwxr-xr-x  1 mle3 mle3  11760 Feb 19 12:58 libj2pcsc.so
-rwxr-xr-x  1 mle3 mle3  66464 Feb 19 12:58 libj2pkcs11.so
-rwxr-xr-x  1 mle3 mle3   6434 Feb 19 12:58 libjaas_unix.so
-rwxr-xr-x  1 mle3 mle3 189159 Feb 19 12:58 libjava.so
-rwxr-xr-x  1 mle3 mle3  25431 Feb 19 12:58 libjava_crw_demo.so
-rwxr-xr-x  1 mle3 mle3  80875 Feb 19 13:01 libjavaplugin_jni.so
-rwxr-xr-x  1 mle3 mle3 268961 Feb 19 13:01 libjavaplugin_nscp.so
-rwxr-xr-x  1 mle3 mle3 271056 Feb 19 13:01 libjavaplugin_nscp_gcc29.so
-rwxr-xr-x  1 mle3 mle3   5405 Feb 19 12:58 libjawt.so
-rwxr-xr-x  1 mle3 mle3 278377 Feb 19 12:58 libjdwp.so
-rwxr-xr-x  1 mle3 mle3 211066 Feb 19 12:58 libjpeg.so
-rwxr-xr-x  1 mle3 mle3   8190 Feb 19 12:58 libjsig.so
-rwxr-xr-x  1 mle3 mle3 235601 Feb 19 12:58 libjsound.so
-rwxr-xr-x  1 mle3 mle3  80797 Feb 19 12:58 libjsoundalsa.so
-rwxr-xr-x  1 mle3 mle3  33900 Feb 19 12:58 libmanagement.so
-rwxr-xr-x  1 mle3 mle3 831403 Feb 19 12:58 libmlib_image.so
-rw-r--r--  1 mle3 mle3   5331 Feb 19 12:58 libnative_chmod.so
-rw-r--r--  1 mle3 mle3   5315 Feb 19 12:58 libnative_chmod_g.so
-rwxr-xr-x  1 mle3 mle3  95830 Feb 19 12:58 libnet.so
-rwxr-xr-x  1 mle3 mle3  37081 Feb 19 12:58 libnio.so
-rwxr-xr-x  1 mle3 mle3  68254 Feb 19 13:01 libnpjp2.so
-rwxr-xr-x  1 mle3 mle3  12931 Feb 19 12:58 libnpt.so
-rwxr-xr-x  1 mle3 mle3   4902 Feb 19 12:58 librmi.so
-rwxr-xr-x  1 mle3 mle3  37919 Feb 19 12:58 libsaproc.so
-rwxr-xr-x  1 mle3 mle3 266365 Feb 19 12:58 libsplashscreen.so
-rwxr-xr-x  1 mle3 mle3 141709 Feb 19 12:58 libunpack.so
-rwxr-xr-x  1 mle3 mle3  56701 Feb 19 12:58 libverify.so
-rwxr-xr-x  1 mle3 mle3  76374 Feb 19 12:58 libzip.so
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 motif21
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 native_threads
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 server
drwxr-xr-x  2 mle3 mle3   4096 Feb 19 14:44 xawt

> А зачем заставлять их это делать? Где и в чем выгода? Заменить аппаратный MMU на его (практически) эмуляцию? Это смешно.

Аппаратный MMU был создан под нужды нынешних ОС. Можно ведь и Java bytecode аппаратно поддерживать.

> Так в чем преимущество managed OS?

Уже много было тут перечислено. Дальше сами ищите статьи по теме.

> Вспомнил ещё про некоторые преимущества:

Кроме пункта 1, остальное не является исключительным преимуществом JIT и managed-кода. И даже 1 может, во-первых, не дать ощутимого выигрыша, и во-вторых, для этого не нужен байт-код (более того, байт-код для этого неудобен).

Кстати -- Sun предпочитает jpeg обрабатывать на С а не на жабе... даже у него на это мозгов хватает

Доказателсьство:

-rwxr-xr-x 1 mle3 mle3 211066 Feb 19 12:58 libjpeg.so

Загляни вовнутрь libjpeg.so -- увидишь что-то вроде

...

Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_abortRead

...

>> Так в чем преимущество managed OS?

> Уже много было тут перечислено.

Ничего существенного, недостижимого другими способами, упомянуто не было.

> Дальше сами ищите статьи по теме.

Уже лет 10-12 периодически встречаю эти статьи - и ничего убедительного не встретил.

> Fice, взгляни разок на JRE, хорошо? Этот огромный С код громко называют VM:

Все это библиотеки, обеспечивающие взаимодействие JRE с конкретной ОС. В JNode все это заменяется управляемым кодом.

Размер чистой JVM здесь уже обсуждался, см. выше.

> Кроме пункта 1, остальное не является исключительным преимуществом JIT и managed-кода.

Но с байт-кодом все это проще и "за бесплатно".

> И даже 1 может, во-первых, не дать ощутимого выигрыша, и во-вторых, для этого не нужен байт-код (более того, байт-код для этого неудобен).

Почему?

>> Fice, взгляни разок на JRE, хорошо? Этот огромный С код громко называют VM:

>Все это библиотеки, обеспечивающие взаимодействие JRE с конкретной ОС. В JNode все это заменяется управляемым кодом.

Неправильно, ибо

1) например libjpeg.so занимается конкретным алгоритмом паковки-распаковки jpeg, и этим не занимается ни одна ОС

2) jnode юзает GNU classpath (сюрприз? да?), и не факт что там это будет управляемым кодом, скорее в гну тоже не дураки и не будет писать кодировку-декодировку джипега на яве, а возьмут либку и обернут ее

>> Кроме пункта 1, остальное не является исключительным преимуществом JIT и managed-кода.

> Но с байт-кодом все это проще и "за бесплатно".

"Бесплатно" ничего не бывает, а Ява-машина - это ни разу не "просто".

>> И даже 1 может, во-первых, не дать ощутимого выигрыша, и во-вторых, для этого не нужен байт-код (более того, байт-код для этого неудобен).

> Почему?

Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

> 1) например libjpeg.so занимается конкретным алгоритмом паковки-распаковки jpeg, и этим не занимается ни одна ОС

Я понимаю. Но это все-равно ОС-и-архитектуро-зависимая часть JRE.

> 2) jnode юзает GNU classpath (сюрприз? да?), и не факт что там это будет управляемым кодом, скорее в гну тоже не дураки и не будет писать кодировку-декодировку джипега на яве, а возьмут либку и обернут ее

Тогда разработчикам JNode придется переписать это в управляемом коде. Не может JNode использовать нативную библиотеку.

> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

И какой информации не хватает в байт-коде?
Байт-код - архитектуро-независимое представление. Оптимизации на уровне байт-кода выполняет компилятор Java. Оптимизации на уровне машинного кода выполняет JIT.

> 2) Для компиляции чего-нибудь из исходников не нужны заголовочные файлы: достаточно только бинарных библиотек.

не проблема пропатчить gcc чтобы все функции в ПРЯМО бинарной библиотеке назывались public static my_class.my_func(char*,int,const my_class&)

Но обычно автору программы кроме бинарной либки нужен еще и мануал :-) а вместе с ним не проблема и хедер достать :-)

Еще улыбнуло про то, как программа может продолжать работать без одной из библиотек :-) php может грузить кучу библиотек, это в конфиге пишется, и если нескольких библиотек не будет -- не помрет

>> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

>И какой информации не хватает в байт-коде?

http://www.ics.uci.edu/%7Efranz/Site/publications.html, поищи статьи по slim binaries.

> Байт-код - архитектуро-независимое представление

Правда? Машинный код (пусть и абстрактного, но довольно низкоуровневого) процессора - это архитектурно-независимое представление? Больше вопросов нет.

>> 1) например libjpeg.so занимается конкретным алгоритмом паковки-распаковки jpeg, и этим не занимается ни одна ОС

>Я понимаю. Но это все-равно ОС-и-архитектуро-зависимая часть JRE.

то что ты называешь "архитектуро-зависимая часть JRE" это libjpeg, libzip, libaac, ... и еще куча огромная куча кода (см. про 5 метров), который, глюкнув в kernel-user-mode, нафиг снесет беззащитное так называемое микроядро.

>> 2) jnode юзает GNU classpath (сюрприз? да?), и не факт что там это будет управляемым кодом, скорее в гну тоже не дураки и не будет писать кодировку-декодировку джипега на яве, а возьмут либку и обернут ее

>Тогда разработчикам JNode придется переписать это в управляемом коде. Не может JNode использовать нативную библиотеку.

и тогда их JRE на реальных задачах будет в 10 раз тормознее сановской! сантенхники не дураки, и пишут libjpeg.so на С не просто так!!!

> Еще улыбнуло про то, как программа может продолжать работать без одной из библиотек :-) php может грузить кучу библиотек, это в конфиге пишется, и если нескольких библиотек не будет -- не помрет

Ну объяснил же я уже, что можно и на C, но в Java вся линковка исключительно динамическая и происходит во время выполнения. Кроме того, классы не загружаются до тех пор, пока они не нужны. И это применимо ко всем программам, а не только к там, где автор специально об этом позаботился.

>> Байт-код - слишком низкоуровневое представление программы, в котором нет многой важной информации для оптимизации.

>И какой информации не хватает в байт-коде?

tailgunner, я чувствую что ты прав, но мне самому интересно. Может напряжешься и на пальцах объяснишь?

> то что ты называешь "архитектуро-зависимая часть JRE" это libjpeg, libzip, libaac, ... и еще куча огромная куча кода (см. про 5 метров), который, глюкнув в kernel-user-mode, нафиг снесет беззащитное так называемое микроядро.

См 2)
Не будет в managed OS библиотек в native code.

> и тогда их JRE на реальных задачах будет в 10 раз тормознее сановской! сантенхники не дураки, и пишут libjpeg.so на С не просто так!!!

Теоретически, производительность реализации на C достижима в байт-коде для таких задач. Уже обсуждали выше.

>> и тогда их JRE на реальных задачах будет в 10 раз тормознее сановской! сантенхники не дураки, и пишут libjpeg.so на С не просто так!!!

>Теоретически, производительность реализации на C достижима в байт-коде для таких задач. Уже обсуждали выше.

Тогда объясни почему идиоты-сантехники пишут libjpeg.so на С, а не на быстрой безопасной яве?

Только не надо говорить что это у них интерфейс к линуксовой либке! Это JRE из сановского инсталлера, которое работает и в том случае, если у меня система (дебиан) не содержит никакой своей libjpeg

Во аннимус расскажи, почему http://xmlgraphics.apache.org/batik/ работает с svg (содержащим скрипты) быстрее мозиллы и оперы, ведь последние на C++, а батик на какой то яве?

> на пальцах объяснишь?

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

Кроме того, я соврал - всю (или почти всю) это информацию _можно_ извлечь из байт-кода :) 10 лет работы - и компилятор байткода в натив уже близок к компилятору Си :D

http://www.ics.uci.edu/~franz/Site/pubs-pdf/C09.pdf

http://www.springerlink.com/index/H978GU2623X672L7.pdf

> Тогда объясни почему идиоты-сантехники пишут libjpeg.so на С, а не на быстрой безопасной яве?

Потому что сейчас так быстрее.

>Во аннимус расскажи, почему http://xmlgraphics.apache.org/batik/ работает с svg (содержащим скрипты) быстрее мозиллы и оперы, ведь последние на C++, а батик на какой то яве?

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

А еще основной тормоз мозиллы вовсе не С. А XUL. Вон опера тоже на С++ написана а грузится на моб. девайсах в 10 раз быстрее.

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

> Тогда объясни почему идиоты-сантехники пишут libjpeg.so на С, а не на быстрой безопасной яве?

>Потому что сейчас так быстрее.

А всего-то лет через пять уже будет на яве быстрее, и вообще, скоро ма Марсе будут яблони цвести! Так?

>че правда?

чотко поцаны грят внатуре такая шняга.

>где тесты?

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

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

Экое скудное увас воображение, не можете представить себе, что это правда? А зря, написать тормознутое приложение можно и на asm.