Проблемы, возникающие при исполнении программ

Рассмотрим круг проблем, которые, так или иначе, возникают при исполнении программ.

Вложенные обращения к подпрограммам (Рис. 44). Несколько лет назад проводились исследования, которые анализировали распределение времени исполнения программы на разных компонентах программного кода, и выяснилось, что в системах, рассчитанных не только (и не столько) для выполнения математических вычислений (например, в системах обработки текстовой информации), порядка 70% времени тратится на обработку входов и выходов из подпрограмм. Это объясняется тем, что при обращении к подпрограмме необходимо зафиксировать адрес возврата, сформировать параметры, передаваемые вызываемой подпрограмме, как-то сохранить регистровый контекст (т.е. сохранить содержимое тех регистров, которые использовались в программе на данном текущем уровне).

Рис. 44. Вложенные обращения к подпрограммам.

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

Перемещаемость программы по ОЗУ (Рис. 45). Рассмотрим процесс получения исполняемого кода программы. После того, как исходный текст программы попадает на вход компилятору, образуется объектный модуль. А уже из пользовательских модулей и библиотечных формируется исполняемый код, т.е. тот модуль, который можно загрузить в оперативную память и начать его исполнять, причем момент создания исполняемого модуля и момент запуска его на исполнение разнесены во времени. Исторически первые исполняемые модули настраивались на те адреса оперативной памяти, в рамках которых он должен был исполняться. Это означает, что если память в данный момент занята другой программой, то эту программу поставить на счет не удастся (пока память не освободится). И, соответственно, возникает проблема перемещаемости программы по ОЗУ: ресурс свободной памяти в ОЗУ может быть достаточно большим, чтобы в ней разместилась вновь запускаемая программа, но в силу привязки каждой программы к конкретным адресам ОЗУ эту программу запустить не удается.

Рис. 45. Перемещаемость программы по ОЗУ.

Фрагментация памяти. Положим, что предыдущая проблема, связанная с перемещаемостью кода, решена в нашей системе: любой исполняемый модуль может быть загружен в произвольное место ОЗУ для дальнейшего выполнения. Но в этом случае возникает иная проблема.

Пускай наша система работает в мультипрограммном режиме. И в начале работы были запущены на исполнение Программа 1, Программа 2 и т.д., вплоть до некоторого номера K. Со временем некоторые задачи завершаются, а, соответственно, место, занимаемое ими в ОЗУ, высвобождается. Операционная система способна оценивать свободное пространство оперативной памяти и из буфера программ, готовых к исполнению, выбрать ту программу, которая может поместиться в свободный фрагмент памяти. Но зачастую размер загружаемой программы несколько меньше того фрагмента, который был свободен. И постепенно проявляется т.н. проблема фрагментации оперативной памяти (Рис. 46). В некоторый момент может оказаться, что в ОЗУ находится несколько процессов, между которыми имеются фрагменты свободной памяти, каждый из которых не достаточен для того, чтобы загрузить какую-либо готовую к исполнению программу. Но количество подобных фрагментов может быть настолько большим, что суммарно свободное пространство ОЗУ позволил бы разместить в нем хотя бы один готовый к исполнению процесс. Таким образом, система начинает деградировать: имея ресурс свободной памяти, мы не можем его использовать, а это означает, что система используется в усеченном качестве.

Рис. 46. Фрагментация памяти.

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