> И вообще не могу понять вашей критически-демотивирующей тональности.
Всегда интересуюсь новыми идеями и с энтузиазмом их рассматриваю. Если нравятся, реализую. Но перед этим ищу слабые места, над которыми автор «не подумал». Теория и идея должна быть bullet-proof. Я вас не демотивирую, я хочу, что бы вы сначала просто текстом (у себя в блоге или тут) выложили идеи/дизайн вашем машины. А то начало было интересным, а потом вы нас начали кормить банальными решениями. Так боюсь до начинки не дойдем, станет не интересно.
Выкладывайте как будет работать ваша персистентная ВМ, предполагаемые сценарии, преимущества. Мы вместе подумаем, и вам дополнительная критика, и нам пища для ума.
> Для переменных, разделяемых потоками такой сборки нет по понятным причинам. Здесь у меня ничего нового.
Хм… Современные процессоры имеют несколько ядер. Вы предлагали разбивать софт на сервисы в другом топике. Значит оно уже будет работать в несколько потоков. Получается:
— сборки мусора нет — слишком сложно.
— вместо этого имеем «возможность достаточно комфортного кодирования». подсчет ссылок.
CPython находиться в такой же ситуации как и вы: не хотим сложного сборщика мусора, но хотим многопоточность. Решение было не эффективный GIL и отказ от многопоточности в пользу multiprocessing — отдельные однопоточные процессы, которые имеют свои копии данных в виртуальной памяти. Учитывая, что вы хотите крутить все в одном процессе, одной большой виртуальной памяти, такой трюк уже не сработает.
Вывод: решения нет. Значит нельзя эффективно и безопасно писать многопоточные сервисы. Альтернативы вы не предоставили, кроме как «возможность достаточно комфортного кодирования», которую я не вижу. Многопоточность + прямой подсчет ссылок не работает. Это опыт.
> поскольку пока мало что у спел рассказать
Пост, в котором раскрываются не интересные азы, не будет пользоваться успехом. Пост в духе «давайте подумаем», где раскрываются высокоуровневые требования уже более интересен. Тогда можно сравнить ваше виденье ВМ и то, что сейчас имеем в других проектах. Отсюда можно будет решить, что реализуется просто библиотеками (API), что уже есть в популярных ВМ, а что действительно внезапное откровение.
> Каждое обращение к внешней нефункциональной процедуре модуля будет оборачиваться синхронизацией
Это накладно. Но замечание было в другом. Представим P процессоров(4), которые крутят T потоков(16), которые в свою очередь исполняют почти бесконечное количество green threads. Учитывая, что у вас все приложения будут фактически сервисами, green threads впишутся идеально, так что ничего не будет подвисать. Но тогда не возможно будет реализовать прямое управление памятью и прямой подсчет ссылок для контроля жизнью объекта. Все сервисы будут работать в режиме создал объект, что либо сделал, выкинул. Не известно кем объект еще будет использоваться. Тут потребуется GC, да на столько умный, что бы не скидывать «не важные» объекты в своп, который по вашей идее, будет исполъзоваться принудительно для каждого приложения (принудительная персистентность). Либо у вас новаторская идея, которая позволяет работать во множестве потоков без сборщика мусора. Тогда хотелось бы ее услышать.
> Даже в текущем состоянии она умеет очень многое, чего должна уметь VM, отличаясь существенной простотой.
Простота и лаконичность — разные вещи. Софтина, реализующая новую интересную идею простым способом - это хорошо (к примеру pyramid среди питоновских веб фреймворков). Софтина, реализующая фичу X, которую уже многократно реализовали, это другое. Простота в вашем случае означает:
— менее эффективный код за счет прямого исполнения
— отсутствие машинных оптимизаций
— отсутствие уже стандартных вещей вроде разнопрофильной работы с памятью, интроспекция и т.д.
— пока отсутствие внятного дизайна, но возможно это лишь временное явление
— пока отсутствие декларации круга задач, под который создается новая ВМ
- и т.д.
Иными словами, в вашем случае «простой» означает «предельно простой proof-of-concept», урезанный под самое не могу, не для серьезного использования. Правильный подход для проверки идеи, но пока ни одной новой идеи мы не увидели.
> архитектура виртуальной машины должна быть регистровой, а не стековой
По моему стековый байткод можно прямо отобразить в регистровый и обратно. При трансляции в нативный код на лету, для стекового байткода можно уже на месте посмотреть количество доступных регистров и генерить код под них. В регистровой машине чуть сложней транслировать код под процессор с отличным набором регистров (хотя кого это волнует, когда современный JIT кеширует результаты). С другой стороны, регистровый байткод обычно меньше по размеру из-за отсутствия постоянных LOAD операций. От честного интерпретирования байткода (особенно складывания регистров на стек) придется позже отказаться, медленно.
> Поэтому, стоит отказаться от «жирных» абстракций, таких как классы, mark and sweep GC, и др.
Классы — это логика на уровне языка. На реальном железе это те же структуры как у вас, с таблицей виртуальных методов. Без уборщика мусора будет очень сложно работать с многопоточными приложениями. Тут будет очень сложно считать ссылки, каждое обращение придется оборачивать mutex'ом, дабы никто ненароком не удалил объект, пока мы с ним работаем. Или предлагается какой то новаторский подход в этом вопросе?
В целом: пока простейшая VM. Может стоило сначала описать принципиальные особенности вашей VM? Тогда можно взять готовую VM (к примеру Parrot) и сконцентрироваться на идее? Будет обидно потратить много сил на то, что по любому будет работать медленно если реализовано наивно (как у вас сейчас, что хорошо для прототипа), затем потратить еще больше сил на переписывание всего под JIT и тысячу железных трюков, так и не дойдя до собственно вашей идей (изюминкаtm). На том же RPython'е JIT и скорость работы вы получите даром.
> А если нужна программа, которая требует только новую версию WxWidgets, тогда другим становится очень, очень плохо.
В системе всегда можно установить несколько версий одной и той же библиотеки. Софт обычно требует конкретных версий библиотеки, к примеру libneon.27.1.3. Если установлена более новая версия и она совместима с предыдущими, то ставятся ссылки с имен старых версий на новую либу. Иначе в системе устанавливается две и более либы, каждая под свою серию совместимых версий.
Задача меинтейнера либы в репозитории решать когда либа совместима с предыдущими версиями, а когда нет, отсюда выбирается метод установки. Если либа нарушает работу других приложений, то меинтейнер получит уведомление, мол либы не совместимы. Тогда вместо ссылки, он позволит установить две и более версии либы.
Если сидим на левом дистрибутиве или используем левый софт, то всегда можно скачать конфликтную либу, собрать самому, положить в укромное место и перед запуском поставить свой LD_LIBRARY_PATH, где и укажем директорию с либой. За все время работы в Debian, Ubuntu, Arch и Gentoo мне ни разу не приходилось этого делать.
Вывод: сливать все либы в одно приложение, как это делает софт под маком или виндой — все таки не unix way. Никто не запрещает такого подхода, крупный софт именно так и поступает. Использовать общие библиотеки — это хорошо, быстрей загрузка, меньше потребление памяти. Обычно проблемы с либами надуманные, человек предполагает наличие проблемы исходя из логики «одна либа на всю систему», не осознавая, что на самом деле версий одной либы может быть несколько. Хотя тут иногда всплывает аллергия на «копии» одной либы, мол зачем столько и все такое.
Статическая программа по определению не требует либ. Это один большой образ со всем необходимым внутри. Прикладной софт никогда не требует особую версию ядра, народ редко делает на прямую системные вызовы. Другое дело, что другие либы могут требовать поддержки ядра (игра требует свежую mesa для OpenGL шейдеров, mesa требует свежее ядро). Тут нет речи о конкретной версии, тут вопрос наличия фичи. Игруху под DX11 тоже не получится запустить под WinМЕ, по той же самой причине.
Не знал. Теперь пост выглядит с излишним сарказмом, чего не было.
Автору в любом случае творческих успехов. Таланты — это приобретенные навыки и чуть-чуть настоящего интереса к предмету. Интерес и задаток к талантам, судя по фильму, есть. Осталось наработать опыт и создание фильмов - это правильный способ. Только начинать надо с 3 минутных роликов. Они и проще, и требования к ним жестче, и делаются быстрей.
На фильм нужно много талантов. Талант оператора, выбирать интересные ракурсы, сопутствующие передаваемым эмоциями. Монтаж, без излишних пауз. Помимо сюжета, именно монтаж влияет на то как интересен будет просмотр фильма. Талант режиссера/сценариста, не только написать сценарий, но и уложить его в 1.5 часа. Талант аниматора. Не важно как реалистично или наоборот отрисованы персонажи, пусть это будут даже «палочка-палочка-нолик». Аниматор ставит реалистичное движение, яркое, быстрое, можно и с «мультяшной» физикой. Начинающие грешат излишне медленной анимацией, все действия актеров заторможенные, большие паузы. Реалистичное поведение тела человека не трогаю, может это «так задумано»… Фоновая озвучка, несущая эмоции зрителя по сюжету, это вообще сложная наука. Собрать все эти таланты в одном супер-человеке крайне сложно.
Вывод: хороший фильм — это совместная работа целой команды талантливых людей.
У автора фильма хорошо получаются трехмерные модели.
Это благотворительность. Конечно можно все опошлить, мол пошло в карман президенту и другим лицам (о судьбе денег по моему ничего не известно), но по крайней мере есть шанс, что оно пошло на благое дело. Суть суммы — пожертвование, а фотография, как и картина Путина, лишь символизм.
Фотографии из сабжа ушли частникам как реальная покупка. А понты — штука дорогая.
Сложные приложения могут держать свои библиотеки при себе, так иногда происходит. Просто люди не всегда по хорошему относятся к программе, которая держит у себя, к примеру, zlib, если он уже установлен в системе. Никто в Linux не запрещает сделать свою директорию MyApplication.app, сложить в нее все и работать от туда, прямо как на маке.
Линковка динамическая, обратную совместимость люди обычно поддерживают, либо переименовывают библиотеку, так что возможно установить две версии. Тут не важно какой версии либа, главное что в ней есть необходимые функции с необходимой сигнатурой. Плюсом же подхода будет более эффективная работа с памятью (страницы с загруженной либой расшариваются между всеми), да и запуск/загрузка приложения будет быстрей.
> обязательно нужны библиотеки конкретных версий
Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Если вас просто смущает большой набор файлов в /usr/lib, то просто не смотрите туда. Там правда все под контролем =)
> Java, к примеру, не предоставляет распределённую модель вычислений.
Есть ведь RMI, да и куча других фреймворков для распределенных вычислений? На крайняк можно даже само приложение, которое ничего не знает о подобном, раскидать по машинам в кластере через Cluster VJM.
Поддержка распределенных вычислений — не часть виртуальной машины, суть которой эффективно предоставить доступ к локальной машине, да и то по сути к процессору и памяти. Все остальное, это библиотеки, включая даже такие железные вещи как RDMA или прямой доступ к USB девайсам.
> Т.е. какая бы ни была надстройка, всё равно снизу у нас процесс, который загружается с файлового образа, а затем уничтожается.
Хм… Ваша ОС будет скидывать память в своп и обратно. Просто мне это станет не подконтрольно. Когда при переключении между процессами, процессор забывает сбросить пару регистров, из-за чего (при большой удаче) можно подсмотреть за чужим процессом — это считается большой дырой в безопасности. А тут я так понимаю даже закодировать часть своей памяти нельзя будет?
Есть некоторый контейнер приложений. Я пишу свое приложение, в котором указываю что «не умирает», а все остальное по умолчанию — просто мусор. Мне не нужно думать о безопасности, быстродействии, потреблении ресурсов и т.п. Я точно знаю, какой код и какие данные — не умирают. А вот клик мыши, генерирующий какой нибудь MouseEvent — это раз отстреляло и исчезло. Для пользователя удобно, его приложение всегда рядом, всегда реагирует на его желания. Для программиста все удобно. Он декларирует свои объекты, которые интегрируются в жизнь системы. Объекты слушают события и реагируют, пользуясь данными, которые «всегда под рукой». Программист ничего не знает, когда его приложение запускается, когда выгружается и как сериализуются его объекты, то в memcached, то на SSD, то в какой либо своп, в зависимости от статистики использования, которую собирает контейнер. Все это - просто контейнер со своим API, в который мы deploy наше приложение. Ну и стандарты на API для разного рода абстракций и семантики, типа работа с графом отношений между людьми, релевантный поиск по документам на десктопе и в сети и т.п.
Чем то это напоминает всякие J2EE, бины и прочее. Опыта в «вечно живущих» сервисах у нас уже много на самом деле.
Вместо этого предлагается ОС, которая будет выполнять все функции обыкновенного user-space контейнера приложений, с дополнительной фичей — дамп всей памяти в своп. Тут сложно будет разобраться что релевантно, что не безопасно, что нужно держать поближе, т.к. требуется каждую минуту, а что собственно уже давно выкинули, но сборщик мусора пока придержал. Ну распределенные вычисления, которые как я уже сказал, никакого отношения к железу не имеют, а наоборот реализуются поверх обычных системных легковесных процессов + сеть. А ведь еще есть работа с железом, куча стандартов и все такое. Тут на крайний случай можно реализовать свой контейнер приложений, как модуль в ядро, как я уже говорил выше. Но тут уже так просто не fork'нешься. Все то, что дают как само собой разумеющееся в user space, придется реализовывать самому в ядре… ну или тянуть с собой user-space библиотеки (что жутко конечно).
На крайний случай можно подумать вы ищите «новые» (микро ядра, tiny ядра и безъядерные гипотетические ОС уже не первый десяток лет как рассмотрели со всех сторон) типы ОС. К примеру некое минимальное ядро, а в user-space у нас один большой контейнер приложений, в котором все живут. Ну и прекрасно. Берем Linux, выкидываем из него все, включая все окружение GNU (ну все конечно не выкинуть), пишем свой контейнер приложений. Сам контейнер лучше на Java/Mono. Пишем свой ClassLoader, который запретит пользовательским приложениям использовать что либо из стандартных библиотек, только ваш persistent API. Готово. Программист в рабстве, пользователь не видит разницы, у вас своя ОС.
По прежнему стался один вопрос: назовите пример приложения, которое бы получило преимущества в вашей ОС/ВМ, при этом не имела бы таких преимуществ в каком либо контейнере приложений.
Если преимущество: поддержка разных платформ, даже нативных приложений, то как я уже говорил — анализ памяти станет крайне сложным и наверное единственной поддержкой «персистентности» будет чистый дамп в своп. А тут тысячи нюансов, от безопасности и до производительности.
P.S. не хочу переубедить писать свое, всегда интересовался системным программированием и даже писал свою RTOS под современный Z80. Просто интересны ваши аргументы, кроме как «просто так хочу».
Что понимаем под перситентностью? Сервис, который никогда не умирает?
В простейшем случае можно dump'ить память с процессом на диск. Но это не безопасно и в целом будет вредит разработке. Я не хочу, что бы мои объекты (события, списки, сообщения, что угодно) жили вечно. Я не хочу, что бы их вне моего ведома сдампила ОС, а потом восстановила, оставив мне работу все это почистить. Я хочу создать кажущуюся персистентность, когда программа может в любой момент продолжить работу. Это все реализуется в user-space. Если прога не большая, то она может запросто выключаться, скидывая только необходимые объекты в сессию. Если это что-то большое, то обычно оставляем небольшого резидента, который держит часть данных/библиотек в памяти. Ест память, зато просыпаемся почти мгновенно. По задаче.
«Была» такая ОС для мобильников, Symbian, почитай ее плюшки в этом направлении)
Пользовательское приложение может крутится в некотором контейнере, который может сам сбрасывать состояние объектов на диск и обратно. Для приложения все прозрачно, оно «всегда» работает, оно реагирует на сообщения (вот окно, заполни его через этот абстрактный интерфейс; вот адресные данные человека, которого пользователь «перетащил» на твое окно/иконку; этот сервис просит фотографию из профиля и т.д.).
ОС занимается доступом к железу, предоставляет всякие абстракции на подобие VFS, реализует стандартные интерфейсы вроде POSIX (вернее системную их часть) и т.д. Это не задача ОС знать что там в user-space происходит. Нынешние ОС на вроде Linux'а предоставляют полный доступ до памяти, со всяким плюшками типа shared memory, copy on write, transactional memory и т.п. На крайняк можно сделать брешь в безопасности системы и написать свой модуль, который по хамски будет лезть в память user-space програм, хотя пользы от этого не вижу. Но я совершенно не вижу причин, зачем тут потребовалась своя ОС.
То же можно сказать о VM. Ее задача абстрагировать скомпилированный код от железа, на лету или через внешний кешь реализуя самого разного рода оптимизации, трансляции в нативный код и работа с памятью. Не вижу где здесь может потребоваться особая поддержка со стороны VM. Даже если написать что-то совсем не безопасное, к примеру любые объекты в системе (включая простейшие массивы) могут мигрировать с машины на машину полностью прозрачно, а также им гарантируется «вечная жизнь» пока их не удалят (да и там versioning и все такое), то совершенно не пойму где тут нужна поддержка VM (кроме отдельных нативных расширений для скорости)? Просто вместо массива всегда используем PersistentArray. Если совсем хотим загнобить программиста, то просто пишем надстройку/валидатор над компилятором, который будет ругаться на не использование Persistent* API. Что бы облегчить труд программиста, можно придумать или взять существующий язык (lua, python, что угодно) и за'map'ить все объекты в свои Persistent*.
Вывод: не ясно зачем тут своя ОС. Не ясно зачем тут своя VM.
Попробуй обосновать «ведь здесь нужна поддержка со стороны ОС», хотя бы примерами.
Не всегда приоритет writer'а над reader'ами это хорошо. Он их может просто задавить. Вообще, политика разграничивания доступа — это целое направление в науке с кучей разных решений под разные сценарии. Получается API должен быть предельно гибким, что усложняет задачу.
Прямо сейчас работаю над HugeSet, может хранить в индексном хранилище очень много строк (ДНК последовательности, что угодно). Да, предоставить доступ через функции - это хорошо. Это сервисная архитектура, которая уже с другой десяток лет успешно используется. А вот не дать проге на прямую работать с данными (в данном случае на прямую читать и лочить страницы файла, пусть даже и раскиданного Lustre по десятку машин), это очень большое ограничение.
Возможный вывод: тут не нужна своя ось. Тут нужно исключительно run-time реализуемой парой библиотек, которые бы предоставляли все необходимые абстракции прикладным программам (публикация сервисов в сети, прозрачная работа со свопом и т.п.). Зато можно всегда нырнуть поглубже к железу, когда песочница оказывается слишком малой.
Дальше глянем и вдруг понимаем, что run-time такой уже есть. К примеру Java. Просто нужна надстройка, которая бы хранила/пробуждала наши объекты во время их жизни. Все абстракции, приведенные в статье легко реализуются.
В таком ключе можно сконцентрироваться на идее и даже ее полностью реализовать. В отличии от наполеоновских планов на новую ОС. Только чует мое сердце, реализовано оно уже… Где то видел «вечные» объекты и даже JVM раскиданную по кластеру машин с возможностью прозрачной миграции объектов. Про сервисы и доступ данных, да рассылка сообщений — это уже индустриальный стандарт по моему.
Agile — это один из способов создать качественный продукт в сроки. Другое дело, что само желание работать качественно, должно прочно устояться в атмосфере компании. Иначе все сводиться к культу карго.
Есть какое-то нехорошее предчувствие, что любое осмысленное применение распознавания голоса уже кем то запатентовано… Обычно все это патентуется до того, как придут реальные технологии.
iPad создан для потребления контента, который в принципе целиком из сети. Сейчас много проектов, предлагающих этот контент. Это зовется инфраструктурой.
А в 2002 всего этого было мало, платно, криво и очень медленно. Заслуга Джобса в точно подобранном времени для «нового» устройства.
«Присутствие» требует качественного подхода. Изначально Bing плохо пах, потребовалось много времени, что бы он стал лучше. Hotmail один из самых популярных почтовых сервисов, прямо сейчас половина моих знакомых там. Другое дело, что раньше было ограниченное пространство и реверансы в сторону спаммеров в виде сразу подгружаемых картинок, отсутствие проверки аттачей и т.п.
Если «присутствие» на рынке обусловлено качественным продуктом, то он выстрелит. Другое дело, если под продукт можно писать только собственным закрытым SDK, доступным за сумасшедшие деньги, да и еще и платить отчисления за использование и сертифицирование. Наличие багов, превращающих девайс в кирпич, если сделать замысловатый жест. Наличие обязательной интеграции с Microsoft Exchange server, которая потребует поддержку какой либо старой фичи, через которую можно взломать девайс. Сопротивление менеджеров и рекламщиков. Короче, если все то, что называется «экосистемой» вокруг девайса — гуано, то даже если девайс действительно бриллиант — он все равно будет испачкан и никому не нужен.
Тут много «если», у это пресловутого «присутствия».
P.S. проблемы выше вымышленные, просто что бы показать влияние компании на продукт.
> но в соввокупности это было бы мертвое для рынка устройство
Это было бы что-то новое, как в свое время был iPad. Сейчас продукт от Apple это просто планшетник, к ним привыкли. Тут же удачно вплели работу с двумя мониторами и стилусом. Прямо сейчас многие, включая меня, работают именно ручкой по записной книжке.
Просто управленцы больших компаний не всегда могут выйти за рамки привычных решений. Им привычней навесить на устройство типичных функций планшетника (фокус вокруг почты, браузера, интернета, устанавливаемых/читай продаваемых приложений), убрать новое (графический редактор великолепен) и затем выкинуть девайс с победоносным «а, тот же iPad, ничего нового».
Заняв небольшую, но узконаправленную нишу, пусть даже убыточную, означает присутствие. Тебя любят дизайнеры, потом простые люди, потом оно внезапно «выстреливает» и твои девайсы хотят все за любые деньги. Привычная менеджерам логика «для масс и сразу» далеко не всегда работает.
Нет, движок представляет интерес для обучающихся. Коммерческие проекты вообще всегда лучше создавать на движках для «будущих» игр, т.к. сама разработка занимает время. И это все стоит не больших денег.
Другое дело, что исходники Doom 3 позволят портировать его многие платформы. Быть может через два года он будет в телефоне.
Всегда интересуюсь новыми идеями и с энтузиазмом их рассматриваю. Если нравятся, реализую. Но перед этим ищу слабые места, над которыми автор «не подумал». Теория и идея должна быть bullet-proof. Я вас не демотивирую, я хочу, что бы вы сначала просто текстом (у себя в блоге или тут) выложили идеи/дизайн вашем машины. А то начало было интересным, а потом вы нас начали кормить банальными решениями. Так боюсь до начинки не дойдем, станет не интересно.
Выкладывайте как будет работать ваша персистентная ВМ, предполагаемые сценарии, преимущества. Мы вместе подумаем, и вам дополнительная критика, и нам пища для ума.
Хм… Современные процессоры имеют несколько ядер. Вы предлагали разбивать софт на сервисы в другом топике. Значит оно уже будет работать в несколько потоков. Получается:
— сборки мусора нет — слишком сложно.
— вместо этого имеем «возможность достаточно комфортного кодирования». подсчет ссылок.
CPython находиться в такой же ситуации как и вы: не хотим сложного сборщика мусора, но хотим многопоточность. Решение было не эффективный GIL и отказ от многопоточности в пользу multiprocessing — отдельные однопоточные процессы, которые имеют свои копии данных в виртуальной памяти. Учитывая, что вы хотите крутить все в одном процессе, одной большой виртуальной памяти, такой трюк уже не сработает.
Вывод: решения нет. Значит нельзя эффективно и безопасно писать многопоточные сервисы. Альтернативы вы не предоставили, кроме как «возможность достаточно комфортного кодирования», которую я не вижу. Многопоточность + прямой подсчет ссылок не работает. Это опыт.
Пост, в котором раскрываются не интересные азы, не будет пользоваться успехом. Пост в духе «давайте подумаем», где раскрываются высокоуровневые требования уже более интересен. Тогда можно сравнить ваше виденье ВМ и то, что сейчас имеем в других проектах. Отсюда можно будет решить, что реализуется просто библиотеками (API), что уже есть в популярных ВМ, а что действительно внезапное откровение.
> Каждое обращение к внешней нефункциональной процедуре модуля будет оборачиваться синхронизацией
Это накладно. Но замечание было в другом. Представим P процессоров(4), которые крутят T потоков(16), которые в свою очередь исполняют почти бесконечное количество green threads. Учитывая, что у вас все приложения будут фактически сервисами, green threads впишутся идеально, так что ничего не будет подвисать. Но тогда не возможно будет реализовать прямое управление памятью и прямой подсчет ссылок для контроля жизнью объекта. Все сервисы будут работать в режиме создал объект, что либо сделал, выкинул. Не известно кем объект еще будет использоваться. Тут потребуется GC, да на столько умный, что бы не скидывать «не важные» объекты в своп, который по вашей идее, будет исполъзоваться принудительно для каждого приложения (принудительная персистентность). Либо у вас новаторская идея, которая позволяет работать во множестве потоков без сборщика мусора. Тогда хотелось бы ее услышать.
> Даже в текущем состоянии она умеет очень многое, чего должна уметь VM, отличаясь существенной простотой.
Простота и лаконичность — разные вещи. Софтина, реализующая новую интересную идею простым способом - это хорошо (к примеру pyramid среди питоновских веб фреймворков). Софтина, реализующая фичу X, которую уже многократно реализовали, это другое. Простота в вашем случае означает:
— менее эффективный код за счет прямого исполнения
— отсутствие машинных оптимизаций
— отсутствие уже стандартных вещей вроде разнопрофильной работы с памятью, интроспекция и т.д.
— пока отсутствие внятного дизайна, но возможно это лишь временное явление
— пока отсутствие декларации круга задач, под который создается новая ВМ
- и т.д.
Иными словами, в вашем случае «простой» означает «предельно простой proof-of-concept», урезанный под самое не могу, не для серьезного использования. Правильный подход для проверки идеи, но пока ни одной новой идеи мы не увидели.
По моему стековый байткод можно прямо отобразить в регистровый и обратно. При трансляции в нативный код на лету, для стекового байткода можно уже на месте посмотреть количество доступных регистров и генерить код под них. В регистровой машине чуть сложней транслировать код под процессор с отличным набором регистров (хотя кого это волнует, когда современный JIT кеширует результаты). С другой стороны, регистровый байткод обычно меньше по размеру из-за отсутствия постоянных LOAD операций. От честного интерпретирования байткода (особенно складывания регистров на стек) придется позже отказаться, медленно.
> Поэтому, стоит отказаться от «жирных» абстракций, таких как классы, mark and sweep GC, и др.
Классы — это логика на уровне языка. На реальном железе это те же структуры как у вас, с таблицей виртуальных методов. Без уборщика мусора будет очень сложно работать с многопоточными приложениями. Тут будет очень сложно считать ссылки, каждое обращение придется оборачивать mutex'ом, дабы никто ненароком не удалил объект, пока мы с ним работаем. Или предлагается какой то новаторский подход в этом вопросе?
В целом: пока простейшая VM. Может стоило сначала описать принципиальные особенности вашей VM? Тогда можно взять готовую VM (к примеру Parrot) и сконцентрироваться на идее? Будет обидно потратить много сил на то, что по любому будет работать медленно если реализовано наивно (как у вас сейчас, что хорошо для прототипа), затем потратить еще больше сил на переписывание всего под JIT и тысячу железных трюков, так и не дойдя до собственно вашей идей (изюминкаtm). На том же RPython'е JIT и скорость работы вы получите даром.
В системе всегда можно установить несколько версий одной и той же библиотеки. Софт обычно требует конкретных версий библиотеки, к примеру libneon.27.1.3. Если установлена более новая версия и она совместима с предыдущими, то ставятся ссылки с имен старых версий на новую либу. Иначе в системе устанавливается две и более либы, каждая под свою серию совместимых версий.
Задача меинтейнера либы в репозитории решать когда либа совместима с предыдущими версиями, а когда нет, отсюда выбирается метод установки. Если либа нарушает работу других приложений, то меинтейнер получит уведомление, мол либы не совместимы. Тогда вместо ссылки, он позволит установить две и более версии либы.
Если сидим на левом дистрибутиве или используем левый софт, то всегда можно скачать конфликтную либу, собрать самому, положить в укромное место и перед запуском поставить свой LD_LIBRARY_PATH, где и укажем директорию с либой. За все время работы в Debian, Ubuntu, Arch и Gentoo мне ни разу не приходилось этого делать.
Вывод: сливать все либы в одно приложение, как это делает софт под маком или виндой — все таки не unix way. Никто не запрещает такого подхода, крупный софт именно так и поступает. Использовать общие библиотеки — это хорошо, быстрей загрузка, меньше потребление памяти. Обычно проблемы с либами надуманные, человек предполагает наличие проблемы исходя из логики «одна либа на всю систему», не осознавая, что на самом деле версий одной либы может быть несколько. Хотя тут иногда всплывает аллергия на «копии» одной либы, мол зачем столько и все такое.
Статическая программа по определению не требует либ. Это один большой образ со всем необходимым внутри. Прикладной софт никогда не требует особую версию ядра, народ редко делает на прямую системные вызовы. Другое дело, что другие либы могут требовать поддержки ядра (игра требует свежую mesa для OpenGL шейдеров, mesa требует свежее ядро). Тут нет речи о конкретной версии, тут вопрос наличия фичи. Игруху под DX11 тоже не получится запустить под WinМЕ, по той же самой причине.
Автору в любом случае творческих успехов. Таланты — это приобретенные навыки и чуть-чуть настоящего интереса к предмету. Интерес и задаток к талантам, судя по фильму, есть. Осталось наработать опыт и создание фильмов - это правильный способ. Только начинать надо с 3 минутных роликов. Они и проще, и требования к ним жестче, и делаются быстрей.
Вывод: хороший фильм — это совместная работа целой команды талантливых людей.
У автора фильма хорошо получаются трехмерные модели.
P.S. извиняюсь, если обидел.
Фотографии из сабжа ушли частникам как реальная покупка. А понты — штука дорогая.
Линковка динамическая, обратную совместимость люди обычно поддерживают, либо переименовывают библиотеку, так что возможно установить две версии. Тут не важно какой версии либа, главное что в ней есть необходимые функции с необходимой сигнатурой. Плюсом же подхода будет более эффективная работа с памятью (страницы с загруженной либой расшариваются между всеми), да и запуск/загрузка приложения будет быстрей.
> обязательно нужны библиотеки конкретных версий
Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Если вас просто смущает большой набор файлов в /usr/lib, то просто не смотрите туда. Там правда все под контролем =)
Есть ведь RMI, да и куча других фреймворков для распределенных вычислений? На крайняк можно даже само приложение, которое ничего не знает о подобном, раскидать по машинам в кластере через Cluster VJM.
Поддержка распределенных вычислений — не часть виртуальной машины, суть которой эффективно предоставить доступ к локальной машине, да и то по сути к процессору и памяти. Все остальное, это библиотеки, включая даже такие железные вещи как RDMA или прямой доступ к USB девайсам.
> Т.е. какая бы ни была надстройка, всё равно снизу у нас процесс, который загружается с файлового образа, а затем уничтожается.
Хм… Ваша ОС будет скидывать память в своп и обратно. Просто мне это станет не подконтрольно. Когда при переключении между процессами, процессор забывает сбросить пару регистров, из-за чего (при большой удаче) можно подсмотреть за чужим процессом — это считается большой дырой в безопасности. А тут я так понимаю даже закодировать часть своей памяти нельзя будет?
Есть некоторый контейнер приложений. Я пишу свое приложение, в котором указываю что «не умирает», а все остальное по умолчанию — просто мусор. Мне не нужно думать о безопасности, быстродействии, потреблении ресурсов и т.п. Я точно знаю, какой код и какие данные — не умирают. А вот клик мыши, генерирующий какой нибудь MouseEvent — это раз отстреляло и исчезло. Для пользователя удобно, его приложение всегда рядом, всегда реагирует на его желания. Для программиста все удобно. Он декларирует свои объекты, которые интегрируются в жизнь системы. Объекты слушают события и реагируют, пользуясь данными, которые «всегда под рукой». Программист ничего не знает, когда его приложение запускается, когда выгружается и как сериализуются его объекты, то в memcached, то на SSD, то в какой либо своп, в зависимости от статистики использования, которую собирает контейнер. Все это - просто контейнер со своим API, в который мы deploy наше приложение. Ну и стандарты на API для разного рода абстракций и семантики, типа работа с графом отношений между людьми, релевантный поиск по документам на десктопе и в сети и т.п.
Чем то это напоминает всякие J2EE, бины и прочее. Опыта в «вечно живущих» сервисах у нас уже много на самом деле.
Вместо этого предлагается ОС, которая будет выполнять все функции обыкновенного user-space контейнера приложений, с дополнительной фичей — дамп всей памяти в своп. Тут сложно будет разобраться что релевантно, что не безопасно, что нужно держать поближе, т.к. требуется каждую минуту, а что собственно уже давно выкинули, но сборщик мусора пока придержал. Ну распределенные вычисления, которые как я уже сказал, никакого отношения к железу не имеют, а наоборот реализуются поверх обычных системных легковесных процессов + сеть. А ведь еще есть работа с железом, куча стандартов и все такое. Тут на крайний случай можно реализовать свой контейнер приложений, как модуль в ядро, как я уже говорил выше. Но тут уже так просто не fork'нешься. Все то, что дают как само собой разумеющееся в user space, придется реализовывать самому в ядре… ну или тянуть с собой user-space библиотеки (что жутко конечно).
На крайний случай можно подумать вы ищите «новые» (микро ядра, tiny ядра и безъядерные гипотетические ОС уже не первый десяток лет как рассмотрели со всех сторон) типы ОС. К примеру некое минимальное ядро, а в user-space у нас один большой контейнер приложений, в котором все живут. Ну и прекрасно. Берем Linux, выкидываем из него все, включая все окружение GNU (ну все конечно не выкинуть), пишем свой контейнер приложений. Сам контейнер лучше на Java/Mono. Пишем свой ClassLoader, который запретит пользовательским приложениям использовать что либо из стандартных библиотек, только ваш persistent API. Готово. Программист в рабстве, пользователь не видит разницы, у вас своя ОС.
По прежнему стался один вопрос: назовите пример приложения, которое бы получило преимущества в вашей ОС/ВМ, при этом не имела бы таких преимуществ в каком либо контейнере приложений.
Если преимущество: поддержка разных платформ, даже нативных приложений, то как я уже говорил — анализ памяти станет крайне сложным и наверное единственной поддержкой «персистентности» будет чистый дамп в своп. А тут тысячи нюансов, от безопасности и до производительности.
P.S. не хочу переубедить писать свое, всегда интересовался системным программированием и даже писал свою RTOS под современный Z80. Просто интересны ваши аргументы, кроме как «просто так хочу».
В простейшем случае можно dump'ить память с процессом на диск. Но это не безопасно и в целом будет вредит разработке. Я не хочу, что бы мои объекты (события, списки, сообщения, что угодно) жили вечно. Я не хочу, что бы их вне моего ведома сдампила ОС, а потом восстановила, оставив мне работу все это почистить. Я хочу создать кажущуюся персистентность, когда программа может в любой момент продолжить работу. Это все реализуется в user-space. Если прога не большая, то она может запросто выключаться, скидывая только необходимые объекты в сессию. Если это что-то большое, то обычно оставляем небольшого резидента, который держит часть данных/библиотек в памяти. Ест память, зато просыпаемся почти мгновенно. По задаче.
«Была» такая ОС для мобильников, Symbian, почитай ее плюшки в этом направлении)
Пользовательское приложение может крутится в некотором контейнере, который может сам сбрасывать состояние объектов на диск и обратно. Для приложения все прозрачно, оно «всегда» работает, оно реагирует на сообщения (вот окно, заполни его через этот абстрактный интерфейс; вот адресные данные человека, которого пользователь «перетащил» на твое окно/иконку; этот сервис просит фотографию из профиля и т.д.).
ОС занимается доступом к железу, предоставляет всякие абстракции на подобие VFS, реализует стандартные интерфейсы вроде POSIX (вернее системную их часть) и т.д. Это не задача ОС знать что там в user-space происходит. Нынешние ОС на вроде Linux'а предоставляют полный доступ до памяти, со всяким плюшками типа shared memory, copy on write, transactional memory и т.п. На крайняк можно сделать брешь в безопасности системы и написать свой модуль, который по хамски будет лезть в память user-space програм, хотя пользы от этого не вижу. Но я совершенно не вижу причин, зачем тут потребовалась своя ОС.
То же можно сказать о VM. Ее задача абстрагировать скомпилированный код от железа, на лету или через внешний кешь реализуя самого разного рода оптимизации, трансляции в нативный код и работа с памятью. Не вижу где здесь может потребоваться особая поддержка со стороны VM. Даже если написать что-то совсем не безопасное, к примеру любые объекты в системе (включая простейшие массивы) могут мигрировать с машины на машину полностью прозрачно, а также им гарантируется «вечная жизнь» пока их не удалят (да и там versioning и все такое), то совершенно не пойму где тут нужна поддержка VM (кроме отдельных нативных расширений для скорости)? Просто вместо массива всегда используем PersistentArray. Если совсем хотим загнобить программиста, то просто пишем надстройку/валидатор над компилятором, который будет ругаться на не использование Persistent* API. Что бы облегчить труд программиста, можно придумать или взять существующий язык (lua, python, что угодно) и за'map'ить все объекты в свои Persistent*.
Вывод: не ясно зачем тут своя ОС. Не ясно зачем тут своя VM.
Попробуй обосновать «ведь здесь нужна поддержка со стороны ОС», хотя бы примерами.
P.S. извиняюсь за длинную простыню)
Прямо сейчас работаю над HugeSet, может хранить в индексном хранилище очень много строк (ДНК последовательности, что угодно). Да, предоставить доступ через функции - это хорошо. Это сервисная архитектура, которая уже с другой десяток лет успешно используется. А вот не дать проге на прямую работать с данными (в данном случае на прямую читать и лочить страницы файла, пусть даже и раскиданного Lustre по десятку машин), это очень большое ограничение.
Возможный вывод: тут не нужна своя ось. Тут нужно исключительно run-time реализуемой парой библиотек, которые бы предоставляли все необходимые абстракции прикладным программам (публикация сервисов в сети, прозрачная работа со свопом и т.п.). Зато можно всегда нырнуть поглубже к железу, когда песочница оказывается слишком малой.
Дальше глянем и вдруг понимаем, что run-time такой уже есть. К примеру Java. Просто нужна надстройка, которая бы хранила/пробуждала наши объекты во время их жизни. Все абстракции, приведенные в статье легко реализуются.
В таком ключе можно сконцентрироваться на идее и даже ее полностью реализовать. В отличии от наполеоновских планов на новую ОС. Только чует мое сердце, реализовано оно уже… Где то видел «вечные» объекты и даже JVM раскиданную по кластеру машин с возможностью прозрачной миграции объектов. Про сервисы и доступ данных, да рассылка сообщений — это уже индустриальный стандарт по моему.
А в 2002 всего этого было мало, платно, криво и очень медленно. Заслуга Джобса в точно подобранном времени для «нового» устройства.
Если «присутствие» на рынке обусловлено качественным продуктом, то он выстрелит. Другое дело, если под продукт можно писать только собственным закрытым SDK, доступным за сумасшедшие деньги, да и еще и платить отчисления за использование и сертифицирование. Наличие багов, превращающих девайс в кирпич, если сделать замысловатый жест. Наличие обязательной интеграции с Microsoft Exchange server, которая потребует поддержку какой либо старой фичи, через которую можно взломать девайс. Сопротивление менеджеров и рекламщиков. Короче, если все то, что называется «экосистемой» вокруг девайса — гуано, то даже если девайс действительно бриллиант — он все равно будет испачкан и никому не нужен.
Тут много «если», у это пресловутого «присутствия».
P.S. проблемы выше вымышленные, просто что бы показать влияние компании на продукт.
Это было бы что-то новое, как в свое время был iPad. Сейчас продукт от Apple это просто планшетник, к ним привыкли. Тут же удачно вплели работу с двумя мониторами и стилусом. Прямо сейчас многие, включая меня, работают именно ручкой по записной книжке.
Просто управленцы больших компаний не всегда могут выйти за рамки привычных решений. Им привычней навесить на устройство типичных функций планшетника (фокус вокруг почты, браузера, интернета, устанавливаемых/читай продаваемых приложений), убрать новое (графический редактор великолепен) и затем выкинуть девайс с победоносным «а, тот же iPad, ничего нового».
Заняв небольшую, но узконаправленную нишу, пусть даже убыточную, означает присутствие. Тебя любят дизайнеры, потом простые люди, потом оно внезапно «выстреливает» и твои девайсы хотят все за любые деньги. Привычная менеджерам логика «для масс и сразу» далеко не всегда работает.
Другое дело, что исходники Doom 3 позволят портировать его многие платформы. Быть может через два года он будет в телефоне.