Разработка концептуально новой ОС

Цитата Trurl, 09.09.03, 18:13:14

Цитата Vilmor, 09.09.03, 15:53:43

Не понимаю, в какую ещё песочницу можно загнать Асм и Си? От них ведь никуда не денешься. Например, вы можете представить себе Quake3, написанный полностью на Обероне или Яве, и при этом чтобы он мог нормально работать на вашей персоналке? А если Apache на популярном хостинге? Сколько сайтов он тогда сможет поддерживать?

А почему бы и нет?

Вот пример из моей работы:
Допустим, имеется декодер MPEG4, который на выходе выдаёт кадры в формате YUV12, а нам надо преобразовать это в RGB565.

Если писать это на ARM-asm’е, то на средненьком PocketPC это займёт 11 мсек для картинки 320х240. Это позволяет нам воспроизводить видеофайл со звуком почти без пропуска кадров.

Если делать то же самое, но на Яве, то только на одну это операцию уйдёт уже больше секунды.

Немногим лучше обстоят дела на персоналках, но в любом случае, вся мощь процессора уходит в свисток.

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

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

С другой стороны, нам совершенно не к чему это делать. Асм может работать и в той же VM, что и наша программа, в виде процедуры-примитива.

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

Цитата Trurl, 09.09.03, 18:13:14

А если у нас нет адресного пространства приложения? Да и приложений никаких нет.

Если нет приложений, то есть объекты, и у них те же проблемы – они не доверяют друг другу, потому что (случайно или намеренно) могут повредить другдругу. Адресное пространство – это средство изоляции компонентов ПО (приложений или объектов), чтобы они не мешали друг другу. Конечно, что если каждый объект будет работать в отдельном процессе, то затраты на время выполнения и память будут огромны. Поэтому позволяется группам объектов (которые могут доверять друг другу) работать в общем для них процессе. С точки зрения реализации, это могут быть DLL, а-ля COM Inproc Server.

Вопрос: могут ли объекты работать вообще без адресного пространства?
Ответ: это принципиально невозможно.

Цитата Trurl, 09.09.03, 18:13:14

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

Не совсем так. Сборщик нужен только тогда, когда у нас не известно, какие из объектов нам больше не нужны.

Тщательно написанное приложение не требует, чтобы за ним убирали мусор – оно знает, что и когда ему перестаёт быть необходимым.

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

Цитата Trurl, 09.09.03, 18:13:14

Насчет real-time согласен. Но если делать real-time от многого придётся отказаться.

Хотелось бы создавать именно real-time OS. Вэтом есть насущная необходимость, да и просто интересно делать ПО, работающее эффективно.

Цитата Trurl, 09.09.03, 18:13:14

Это было бы слишком уж хорошо. По крайней мере, хотелось бы, чтобы документы не пропадали. Заодно избавиться от File/Save.

Это очень смахивает Smalltalk
IMHO, стоит знать, что это такое – это будет хорошей пищей для размышлений

Цитата nvm, 09.09.03, 20:53:28

ИМХО, надежность важнее эффективности.

Полностью согласен.

Цитата nvm, 09.09.03, 20:53:28

Поэтому если нет БКВВ, то стоит пойти на то, что драйверы будут обращаться к портам косвенно - через вызовы функций ядра.

Да, драйвера, работающие в режиме ядра, должны стать единственным "шлюзом" для всех приложений и драйверов, работающих в режиме пользователя. Например, драйвер принтера уровня приложения использует драйвер LPT-порта уровня ядра. Графический драйвер использует драйвер видеокарты, который предоставляет минимальное API для доступа ко всем возможностям видеоакселератора.

Цитата nvm, 09.09.03, 20:53:28

Все равно массивной прокачки данных через порты не бывает.

Бывает. Например, в случае PIO-режима у ATA-контроллеров. Ещё хороший пример – программирование видеоакселераторов.

Цитата nvm, 09.09.03, 20:53:28

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

Такие абстрактные сегменты называются секциями, каковые исользуются в COFF-файлах (PE, ELF и т.п.). В этом случае секция .text может быть размещена загрузчиком либо в сегменте с правами на выполнение, либо на страницах с таким правом. Секция .data – аналогично, но с правами чтения/записи, но не выполнения. Константы могут располагаться в одном сегменте, который используется всеми запущенными копиями одной программы, или же (если нет сегментов) проецироваться в адресные пространства этих копий. Таким образом можно экономить память, не делая одинаковых копий для секций с кодом программы и константами, а так же делать копии только отличающихся страниц в области данных программы (механизм WriteCopy). Есть ещё секции для TLS-данных... (Thread Local Storage)

Цитата Shaman, 09.09.03, 21:08:36

"GNU Hurd это альтернативная GNU разработка Unix ядра. Hurd организован как семейство сервисов, работающих на Mach микроядре. Сервисы представляют: файловую систему, сетевые протоколы, контроль доступа к файлам и другие особенности операционной системы, присутствующие в Unix ядре или в схожих ядрах (таких, как Linux)"

От себя: Хурд - ИМХО - самая удачная попытка объединить преимущества новейших подходов к дизайну операционных систем.

Так вот. А что если сделать (по крайней мере попытатся) что-то в этом же духе - подменить ядрышко у UNIX'а? (Или присоединиться к этому проекту?) Таким образом - наследуется почти весь существующий софт Unix'а.

Делать всё своё, "с нуля" – куда интереснее.

Цитата nvm, 09.09.03, 21:34:42

Да, посылается сообщение, но не простое, а RunMessage - с созданием новой нити в пространстве драйвера.
Приоритеты прерываний после этого не нужны, а достаточны приоритетов потоков.

Если на каждый сигнал irq будет создаваться свой тред (а так и получается), то система захлебнётся в необработанных событиях. Кроме того, в реальных приложениях бывает необходимо моментально начинать обработку поступивших сообщений. Поэтому Желательно реализовать оба подхода: ISR (Interrupt Serice Routine) и IST (Interrupt Service Thread). ISR работает в контексте любого треда – того, в момент выполнения которого произошло прерывание. ISR может выполнять обращение к нужному IST, например, через RunMessage.

Цитата nvm, 09.09.03, 21:34:42

Для приоритетов предлагаю ввести классы (следуя классике):
- реального времени,
- интерактивный,
- пакетный (фоновый).
Принцип: все потоки более низкого класса стоят, пока есть хотя бы один активный поток высшего класса.
Внутри класса приоритет задается количественной величиной.

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

Цитата nvm, 09.09.03, 21:34:42

До этого еще далеко... Да хоть BC_3.11..
Очевидно, что компилятор нужен готовый. А язык - вряд ли есть альтернативы C++.

Чтобы потом не пришлось переписывать, прийдётся заранее определиться с компилятором. Даже для Си сужествуют большие различия между GCC, BCC, LCC, WCC и MSVC. Лучше выбрать GCC, поскольку он широко распространён, неплохо оптимизирует и поддерживает множество платформ – от IA32 до Palm и ARM. Но поскольку он не генерирует 16bitй код x86, то потребуется ещё один компилер (а так же линкер), для бутлоадера на платформе PC. Так же будет необходим асм. Для каждой платформы – свой. Для x86 очень рекомендую NASM, для ARM – ARMASM.

Кстати, знаете, что Intel создала процессор Xscale специально для КПК? Так вот, у него архитектура ARM.

От C++ я бы оказался в пользу чистого Си. Для этого есть все основания. Насчёт Паскаля и др. языков очень сильно сомневаюсь...

Цитата nvm, 09.09.03, 21:59:39

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

Для этого совсем не обязательно повторять UNIX. Достаточно поддерживать семейство стандартов POSIX и Single UNIX specification.

Один из модулей ОС может поддерживать загрузку и выполнение приложений разных сред: Windows, Linux, JavaVM, а так же нашу собственную прикладную подсистему.

Цитата nvm, 09.09.03, 21:59:39

Только проектировать ОС нужно, не ориентируясь специально на Unix, а уже по готовности системы дописать shell для Linux-приложений.

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

Цитата nvm, 09.09.03, 22:28:54

Не безъядерная, а микроядерная. Уж ядро-то совсем не похоже на приложение.
А приложения, хоть и однаковы по структуре и режиму процессора, но далеко не "равны": каждому сопоставлен ключ, а ключи образуют жесткую иерахрию.

Да, я тоже за микроядро, вокруг которого будут объекты-модули (статически линкованные в один бинарник с ядром, и динамически загружаемые).

Цитата nvm, 09.09.03, 22:28:54

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

Совершенно верно. За пользовательскую подсистему (которая м.б. не нужна для нек. применений) отвечает просто ещё один модуль (объект). Само ядро ничего не делает.

Цитата Shaman, 09.09.03, 22:49:10

Совсем не для этого
Там никто не пытается переделать ядро системы.
Что такое подмена ядра?
Есть (например) Mach ядро (микроядро). Переписывается именно оно + (!) существующие драйвера для базовах устройств. ИМХО - драйвер - это такой же софт. При переносе драйвера с одной платформы на другую всегда имеется крос-платформенная часть, которую никто не трогает. При упомянутом мною подходе можно будет двигаться итеративно - создать перечень устройств, которые должны быть на 100\% поддержаны первой версией ОС. Отталкиваясь от Mach ядра создать усечённую версию UNIX. Переделывать по капле те его составляющие, которые мешают спокойно спать, не забывая менять при этом базовый набор драйверов (и описывать, как это дОлжно делать, для последывателей).

Это всё моё ИМХО, на самом деле ОСей я никогда не писал и не знаю как это делается на самом деле ;D

Я знаю, я одно время в принимал участие в одном таком проекте. Драйверы всё равно прийдётся переписывать. Можно взять, конечно, за основу, сырцы драйверов от Linux.  Для начала нам многого и не надо – примитивный драйвер клавиатуры, ещё более примитивный – для экрана, и работа с дисками через Int13 (временная мера, реализуется через V86 mode).

Цитата nvm, 09.09.03, 23:27:08

Иллюстрация, как могут работать изложенные идеи.

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

По моим представлениям, не совсем так.
Объекты организованы в иерархию. В основании – системный монитор, ему подчинены объекты класса user, у которых м.б. свои объекты класса process, у них, в сою очередь – thread, console. Консоль может быть ассоциирована с одним из терминалов, на котором залогинен пользователь. Значит, пользователь нигде не залогинен, но его процессы могут существовать. В этом случае, не сущенно, чем идентифицируется пользователь. Главное – с ним сопоставлен объект. В этой иерархии на дочерние объекты действуют ограничения, заданные в родитаелях. Например, у пользователя ограничено кол-во процессов, время жизни процесса, объём потребляемой памяти.

Imho, было бы полезно разделить понятия процесса и приложения.
Приложение – это система объектов, работающих совместно для достижения одной цели.
Процесс – это среда, в которой работают объекты.
С точки зрения ОС, мы меем дело с процессами. С точки зрения конечного пользователя – с приложениями.

Цитата nvm, 09.09.03, 23:27:08

Всем пользовательским интерфейсом в системе управляет специальное приложение–драйвер (GUI), и пользователь напрямую общается только с ним.
Это приложение «во всем слушается» пользователя, но изначально не имеет никаких прав. Для регистрации пользователь сообщает ему логин, который пересылается менеджеру, который презентует в GUI соответствующие ключи.
Пример работы GUI.
Обычное приложение в среднем имеет права доступа на запись только в одну папку на диске. Пусть это будет Интернет-браузер. Предположим он получил от пользователя команду сохранить документ. Прав на запись в нужную папку он не имеет. Но в любом случае он должен обратиться к GUI с заданием вывести диалог FileSave. В качестве результата будет получено не имя файла, а handle, уже открытый на запись!
Такая технология позволяет избежать наличия у приложений лишних прав. Тот же Интернет-браузер может теперь смело запускать любые вирусы (хоть exe, хоть макро). Худшее, что те смогут сделать – стереть кэш скачанных файлов.

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

Если же всё мешать в кучу, то получится как у Micro$oft – передача сообщений между процессами осуществляется через окошки. Поэтому до сих пор, при сборке ядра WinCE для бездисплейных устройств требуется около мегабайта для GWE – модуля для GUI. Нонсенс?

Мы таким образом ухудшаем реюзабельность кода.

Поэтому пусть за управление окнами отвечает оконный менеджер, за реализацию окон – оконная система, за диалоги SaveAs и пр. – стандартная пользовательская бибилиотека классов.

Пускай диалог SaveAs возвращает какой угодно путь к файлу (если он настолько глупый, что может принимать всё подряд), но пользовательская подсистема всё равно сама решает, какой файл можно открыть, а какой – нет. Делать она это может как угодно – через chroot, chmod, или любой другой механизм, который можно придумать самим. Например, эта подсистема может предоставлять пользователю ключ, под которым он может работать.

Цитата rcz, 10.09.03, 12:20:26

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

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

Цитата rcz, 10.09.03, 12:20:26

ФС(файловая система) - хранилище всех ресурсов. Некий менеджер объектов-ресурсов.

Ещё можно считать её объектом с интерфейсом а-ля URL Moniker, у которого м. запросить первый объект, записанный первым в строке адреса, потом попросить этот объект парсить строку адреса дальше, чтобы получить след. объект. Например, м.б. такие цепочки:

/usr/bin/perl
/usr/lib/libpng.a
/inet/proto/http://localghost:81/index.php?cmd=show&uid=567678#top
/services/httpd
/dev/prn
/classes/Inet::URL
/classes/XML:: Parser
/classes/Audio::MP3::Id3tag
/config/httpd/deny-list/*
/config/httpd/docroot

Цитата rcz, 10.09.03, 12:20:26

Архитектура уже проясняется и довольно отчетливо. Только собрать бы все в кучу(точнее по разделам  boot/ mem/  fs/ shedule/ modules/ IPC/ user/). Так удобней было бы править.

С нетерпением жду спецификации.

Сообщение отредактировано: vilmor - 10.09.03, 09:08

Цитата

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

С реализацией она тоже соотносится. (Это что-то вроже подсистем во всех осях. Выделяют в теории, но в ядре все вместе.). И многое происнится при реализации .

RING0-2 (терминалогия x86)

Ядро
Создание объектной среды. //инициализация
Управление памятью. (Создание объектов в памяти.)
Управление объектами.
Управление задачами(Очередь сообщений,их доставка; переключение)
Управление ФС. (по пути определяет модуль)

(отдельные модули)
Ядерный объекты(Драйвра в/в,ФС). Системные вызовы.

Все остальное на RING 3
юзерские объекты. Их загрузка и исполнение.

Нужна декомпозиция. И каждую подсистему пересмотреть.


пример объекта
class UO:res1,res2,...{
// обязательные
  start();
  clean();
// свои интерфейсы
}
Для ФС
class FS:FS_manager{
// обязательные
  start();
  clean();
//перегрузка интерфейсов
  open(), read(), write()...
// свои интерфейсы
}
Эх. Нужен свой компиллер.

Цитата rcz, 10.09.03, 13:31:33

С реализацией она тоже соотносится. (Это что-то вроже подсистем во всех осях. Выделяют в теории, но в ядре все вместе.). И многое происнится при реализации .

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

Нужно о многом ещё поговорить по поводу карты адресного пространства процесса: будет ли туда проецироваться адресное пространства ядра, и смогут ли выполняться syscallы без переключения в адресное пространство ядра, можно ли допустить страничные сбои в режиме ядра. Для этого нужно ввести понятие IRQL, аналогично тому, что дано в WinNT.

От терминологии, взятой из архитектуры x86, прийдётся отказаться совсем.

Цитата rcz, 10.09.03, 13:31:33

RING0-2 (терминалогия x86)

Ядро
Создание объектной среды. //инициализация
Управление памятью. (Создание объектов в памяти.)
Управление объектами.
Управление задачами(Очередь сообщений,их доставка; переключение)
Управление ФС. (по пути определяет модуль)

(отдельные модули)
Ядерный объекты(Драйвра в/в,ФС). Системные вызовы.

Все остальное на RING 3
юзерские объекты. Их загрузка и исполнение.

Согласен

Цитата rcz, 10.09.03, 13:31:33

Нужна декомпозиция. И каждую подсистему пересмотреть.

пример объекта
class UO:res1,res2,...{
// обязательные
  start();
  clean();
// свои интерфейсы
}
Для ФС
class FS:FS_manager{
// обязательные
  start();
  clean();
//перегрузка интерфейсов
  open(), read(), write()...
// свои интерфейсы
}

Наследование классов неудобно использовать в Си, но можно.
start() и clean() могут не потребоваться для некоторых классов, но зато может понадобиться завести счётчик ссылок и семафор для синхронизации.

Цитата rcz, 10.09.03, 13:31:33

Эх. Нужен свой компиллер.

UNIX тоже сначала был написан на асме, и далеко не сразу его переписали на Си.
Чтобы использовать свой язык или компилер, надо сначала быть уверенным, что этот язык в своём развитии достиг зрелости, а компилер хорошо оптимизирует и пригоден для многих аппаратных платформ.

Цитата Vilmor, 10.09.03, 12:52:36

Если делать то же самое, но на Яве, то только на одну это операцию уйдёт уже больше секунды.

Это проблема конкретной реализации Явы.

Цитата

И вообще такая дискриминация по отношению к См и асму ничем не продиктована.

Продиктована тем, что

Цитата

Если нет приложений, то есть объекты, и у них те же проблемы   они не доверяют друг другу, потому что (случайно или намеренно) могут повредить другдругу.

А если код объектов создан на более высокоуровневом языке, то они не могут повредить друг другу.

Цитата

Вопрос: могут ли объекты работать вообще без адресного пространства?
Ответ: это принципиально невозможно.

Но они могут работать в одном адресном пространстве.

Цитата

Хотелось бы создавать именно real-time OS.

Значит, виртуальной памяти тоже не будет?

Цитата

Нужно о многом ещё поговорить по поводу карты адресного пространства процесса: будет ли туда проецироваться адресное пространства ядра, и смогут ли выполняться syscallы без переключения в адресное пространство ядра, можно ли допустить страничные сбои в режиме ядра. Для этого нужно ввести понятие IRQL, аналогично тому, что дано в WinNT.

Syscall  - переключаться придется. Но Системных вызовов не должно быть много - в основном только отправка сообщений системе. Все вызовы получаться в виде сообщений к разным объектам. (Правда здесь пострадает производительность. Сообщения в системе - RPC.)

Никогда не нравились IRQL в NT. И страничные ошибки в ядре должны быть предусмотрены. (Не нужны лишние BSOD,).  Тему свопа надо очень подробно рассмотреть.

Если сегментов нет - стандартная FLAT модель памяти. (Но если с сегментами - создать дескрипторы юзерских сегментов. Чтоб у них память была с 0.N и в Ядро с 0..N).

Память ядра (виртуальная)... Так удобно сделать при инициализации.(Прямое отображение физического на виртуальное пр-во).
0x00000000 - нет
0x00001000 - для BIOS, DMA и т.п
0x00400000 - ядро
0x00500000 - каталог страниц и таблицы страниц
0x01000000 - ХИП
0x6fffffffffff - стек ядра  // пустые страницы, для оршанизации PF при ошибке стека.
0x70000000 - видеопамять и т.п.
0x80000000 - USER. (Если б был сегменты - можно сделать, чтоб они сюда указывали).
Получается как у всех осей. Но можно в сделать, чтобы кождая задача имела свой каталог страниц( хотя не знаю, поддерживается ли это не x86 процессорами). Без сегментов у всех процессов одно виртуальное адресное пространство.

Загрузка.
Микроядерность. Главное загрузиться в память. Инициализировать подсистему В/В и объектов. Должен быть какой-то map, что от куда потом грузить. Загрузить эти объекты(они сами знают что потом делать. почти Plug'n'Play). Загрузить первую задачу. Далее задачи что-то пытаются использовать. При запросе ресурса ФС это подгружает.

Компиллятор лучше gcc. (g++ для объектов, но как их совместить?.). Наследование и прочее ООП придется в начале делать руками. (А множественное и виртуальные методы ?). Всю систему объектов надо придумать(новая технология типа COM).

Всегда приходится чем-то жертвовать. Главной жертвой системы получается производительность(хотя сейчас все железо ускорилось и даже DX теперь весь на COM). Но главный плюс объектности - гибкость. Нужно еще подумать и о надежности такой  системы.

З.Ы.
О платформе - думаю пора переходить на 64 разряда.

Цитата

Хотелось бы создавать именно real-time OS.
..
Значит, виртуальной памяти тоже не будет?

Разве виртуальная память противоречит Real-Time?

А интерпретация команд не может быть быстрой. Только если 1 байтом можно описать функцию, делающую много чего.

Виртуальная машина обязательно должна быть(И бинарники должны быть). Но не само ядро в виртуальной машине.

Сообщение отредактировано: rcz - 10.09.03, 11:20

Цитата Trurl, 10.09.03, 14:30:42

Это проблема конкретной реализации Явы.

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

Даже идеальная реализация на Яве по скорости будет сильно уступать раализации на асме, а для меня важнее ОС, пригодная на практике, чем просто красивая игрушка.

Так что пусть каждый будет в своей песочнице.

Цитата Trurl, 10.09.03, 14:30:42

[Дискриминация] Продиктована тем, что

Цитата Vilmor, 10.09.03, 12:54:09

Если нет приложений, то есть объекты, и у них те же проблемы – они не доверяют друг другу

А если код объектов создан на более высокоуровневом языке, то они не могут повредить друг другу.

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

Возьмём, к примеру Smalltalk. BitBlt на нём был бы жутко медленным. Но в этом замечательном объектно-ориентированном языке реализована концепция методов-примитивов. Например, один примитив может выполнять копирование памяти, другой - поворот битмапа на определённый угол. Сейчас существуют очень быстрые JIT-реализации Smalltalk, но никому же не приходит в голову подстраивать под них ОС! (вообще-то, таких страждущих много, но до конкретного дела у них так и не дошло)

Полагаю, в Java дела обстоят примерно так же.

Цитата Trurl, 10.09.03, 14:30:42

Цитата Vilmor, 10.09.03, 12:54:09

Вопрос: могут ли объекты работать вообще без адресного пространства?
Ответ: это принципиально невозможно.

Но они могут работать в одном адресном пространстве.

Да

Цитата Trurl, 10.09.03, 14:30:42

Цитата Vilmor, 10.09.03, 12:54:09

Хотелось бы создавать именно real-time OS

Значит, виртуальной памяти тоже не будет?

Будет, как отдельная фича, которая будет обязательной для ПК и серверов.

Ещё я сильно подозреваю, что неплохо бы и ФС сделать опциональной...

---

Надо подводить итог этому спору.
Каждый по-своему прав, и если народ решит делать что-то вроде JavaOS, то пожалуйста. Это тоже по-своему интересная задача, но не для меня. В таком проекте я принимать участие не буду.

Ядро в виртуальной машине - это уже больше эмулятор. (Хотя под определение "опрационная система" попадает). Необходимости в бинарной переносимости ядра нет. Еще большее ухудшение производительности не к чему.

Защитить объекты можно и без нее. Сборка мусора - главное самим мусор в ядре не создавать:).

Я против такого ядра, но VM понадобится для других целей (уж очень популярная нынче эта технология).

Цитата rcz, 10.09.03, 15:15:50

Разве виртуальная память противоречит Real-Time?

Угу. Как обеспечить время отклика, если в любой момент может потребоваться обращение к диску? Можно сделать её опциональной как предлагает Vilmor.