Віртуальна машина Java (JVM)

Підхід, заснований на віртуалізації, характерний не тільки для розробки операційних систем, але й для реалізації сучасних платформ і мов програмування. Причина в тім, що реализаторы цих мов і платформ прагнуть зробити їх стерпними з однієї реальної апаратної платформи на іншу. Такий підхід прийнятий, як широко відомо, при реалізації Java, але автори Java аж ніяк не першими запропонували дану ідею. Програми на Java компілюються в платформно-незалежний байт-код (bytecode) – команди віртуальної Java-машини, побудовані на основі постфиксного запису операндвв. Байт-код виконується віртуальною машиною Java (JVM).

JVM складається з:

1. завантажника класів (class loader), що виконує завантаження класів у віртуальну машину під час виконання програми; завантажник класів може бути стандартним або може бути перевизначений користувачем;

2. верификатора класів (class verifier), що виконує при завантаженні класу перевірку коректності його байта-коду, контроль типів й інші необхідні перевірки;

3. інтерпретатора (runtime interpreter), що виконує інтерпретацію (емуляцію) команд байта-коду – абстрактної машини Java;

4. Just-In-Time (JIT) – компілятора, що виконує при першому виклику кожного методу його компіляцію в об'єктний код цільової платформи (native – код), що дозволяє підвищити сумарну продуктивність виконання програм на Java.

Аналогічну архітектуру має віртуальна машина VES (Virtual Execution System) платформи Microsoft.NET, однак підхід.NET більше відкритий – підтримується багатомовне програмування, і байт-код (в. NET називаний CIL – Common Intermediate Language) відіграє роль універсальної проміжної мови, у який компілюється вихідний код на будь-якій мові, наприклад, на C# або Visual Basic. Архітектура віртуальної машини Java зображена на рис. 7.5.

Рис. 7.5. Архітектура віртуальної машини Java (JVM).

Цілі проектування й розробки ОС

Точки зору користувачів і розроблювачів ОС у даному відношенні трохи розрізняються.

Цілі з погляду користувача: ОС повинна бути зручної у використанні, простий для вивчення, надійної, безпечної й швидкої.

Цїли з погляду розроблювача ОС: ОС повинна бути нескладною для проектування, реалізації й супроводу, а також гнучкою, надійною, вільною від помилок й ефективною.

Механізми й політики

При розробці ОС, як і будь-якої іншої складної програмної системи, розрізняють концепції механізму й політики. Механізм визначає, яким образом реалізувати деяку функціональність (наприклад, віртуальну пам'ять). Політика визначає, що саме потрібно реалізувати, тобто набір вимог, цілей, умов для реалізації функціональності. Наприклад, політика безпеки в ОС визначає правила, по яких програмі або користувачеві надаються деякі повноваження (наприклад, можливість відкриття деякого файлу). Відділення механізму від політики - дуже важливий принцип для розробки ОС. Він допускає максимум гнучкості, якщо "політичні" рішення можуть бути змінені згодом.

Реалізація операційних систем

Традиційно, починаючи з 1950-х рр., ОС розроблялися на низькорівневих мовах - асемблерах. Система UNIX була першої ОС, розробленої майже повністю мовою високого рівня - Си. Згодом мова Си стала однією з найбільш популярних мов системного програмування. Завдяки новаторському підходу авторів UNIX, зложилася тенденція розробки ОС на мовах високого рівня.

Переваги використання мов високого рівня очевидний: код мовою високого рівня

1. може бути розроблений швидше

2. більше компактний

3. легше для розуміння й налагодження.

Крім того, операційна система може бути набагато легше перенесенана інші апаратні платформи, якщо вона розроблена мовою високого рівня.

Гіпотетичний недолік у мов високого рівня, у порівнянні з асемблерами, тільки один - можлива неефективність реалізації високорівневих конструкцій мови, у порівнянні з "ручним" програмуванням на асемблері. Однак дана проблема може бути вирішена шляхом розробки ефективного оптимізируючого компілятора з мови високого рівня й не повинна перешкоджати його використанню.

Генерація операційної системи

ОС проектуються з метою використання на комп'ютері будь-якого класу. У поставку ОС входить дуже великий набір типових модулів для різних класів комп'ютерів (наприклад, настільних і портативних). Тому для кожного комп'ютера система повинна бути сконфігурована при її інсталяції – установці ОС на конкретний комп'ютер.

Програма генерації ОС одержує інформацію про специфічну конфігурацію комп'ютерної системи.

Після генерації й інсталяції ОС система готова до роботи.

Лекція 8. Управління процесами. Планування и диспетчеризація процесів

План

· поняття процесу;

· cтан процесу;

· блок керування процесом;

· диспетчеризація процесів;

· операції над процесами.

Процес (process) це програма користувача при її виконанні. При своїй роботі операційна системи виконує безліч класів програм: пакетні завдання; користувальницькі програми в режимі поділу часу; системні програми й процеси. Є кілька схожих термінів, що характеризують користувальницькі програми: процес (process), завдання (job), завдання (task) Однак не будемо тут перебільшувати розходження між ними: для кращого розуміння специфіки процесів і керування ними в ОС, ми можемо вважати наведені терміни синонімами, як й уважається в багатьох підручниках по ОС.

Важлива особливість процесу: це одиниця обчислень, що повинна виконуватися послідовно, тобто кожен процес має свій послідовний потік керування (control flow) – послідовність виконуваних процесом команд. Багато більших завдань успішно вирішуються шляхом паралельного виконання процесів, але про це мова йтиме небагато пізніше.

Процес при його створенні й керуванні їм операційною системою включає наступну основну інформацію:

· Лічильник команд (program counter - PC) – адреса поточної виконуваної команди процесу; звичайно зберігається в спеціальному системному регістрі апаратур;

· Стек (stack) – резидентна область основної пам'яті, виділювана операційною системою при створенні процесу, у якій зберігаються локальні дані процедур процесу, їхні параметри (аргументи) і сполучна інформація між ними, необхідна для організації обчислень. При запуску чергової процедури в стеку приділяється запис активації (activation record), названа також стековым фреймом (stack frame) і областю локальних даних (local data area) для зберігання локальних даних поточного покоління (запуску) процедури. По закінченні її виконання запис активації видаляється зі стека;

Секція даних (data section) – статична (постійно виділена, незмінного розміру) область основної пам'яті, виділювана операційною системою процесу, у якій зберігаються його глобальні змінні, масиви, структури, об'єкти.

Виконуваний код (команди) процесу спочатку зберігається у вторинній пам'яті (на диску) і завантажується в основну пам'ять повністю або частково при звертанні до нього.

Стан процесу

При виконанні процес може змінювати свій стан у такий спосіб:

Новий (new): Процес створюється операційною системою, але ще не почав виконуватися.

Що виконується (running): Виконуються команди процесу на процесорі або процесорах комп'ютерної системи під керуванням ОС.

Що очікує (waiting): Процес очікує настання деякої події, наприклад, завершення вводу-виводу. У стані очікування процес не займає процесор.

Готовий до виконання (ready): Процес очікує одержання ресурсів процесора для його виконання. У стан готовності до виконання процес попадає звичайно або при його створенні, або після завершення вводу-виводу (зі стану очікування).

Завершений (terminated): Виконання процесу завершене.

Діаграма станів процесу представлена на рис. 8.1.

Рис. 8.1. Діаграма станів процесу.

Як видно зі схеми, новий процес, створений у системі, проходить стадію допущений (admitted) – включається операційною системою в чергу всіх процесів у системі, після чого ОС переводить його в стан готовності до виконання. Відзначимо відразу, що черга готових до виконання процесів – одна з найбільше часто використовуваних системних структур для керування процесами. Зі стану готовності в стан виконання процес переводиться планувальником ОС у результаті диспетчеризації – виділення кванта процесорного часу. При виконанні процес може бути перерваний (по таймері, у результаті помилки й т.п.), а після обробки переривання операційною системою переходить знову в стан готовності до виконання. Якщо в процесі виконується синхронний ввід-вивід, або процес повинен очікувати настання деякої події (наприклад, певного моменту часу), процес переходить у стан очікування. При завершенні вводу-виводу або при настанні очікуваної події процес не одержує відразу ж квант процесорного часу, а переходить у стан готовності до виконання. Процес переходить у завершений стан при завершенні роботи програми процесу - наприклад, у результаті системного виклику exit(c), де c - код завершення. Якщо c = 0, процес уважається благополучно завершеним.

Блок керування процесом

Блок керування процесом (Process Control Block – PCB) – системна структура даних, використовувана ОС для керування процесом, що містить наступну інформацію, асоційовану з кожним процесом:

· Стан процесу

· Поточне значення лічильника команд (використовується при продовженні виконання процесу);

· Значення регістрів процесора (також використаються при поновленні процесу);

· Інформація для диспетчеризації процесора (покажчик на стек процесу, номер процесу);

· Інформація для керування пам'яттю (границі області пам'яті процесу);

· Статистична інформація (загальний час виконання процесу, що залишилося із заявленого час виконання, сумарне час вводу-виводу й т.д.)

· Інформація про стан вводу-виводу (список відкритих файлів).

Структура блоку керування процесом зображена на рис. 8.2.