Cтраница 2
Автоматические ( и явные) механизмы перераспределения, вызываемые для объектов из стека ( и локальной кучи) SRO, подразумевают необходимость вспомогательного механизма, который предотвращает появление доступных дескрипторов доступа объектов, которые уже были перераспределены. Для того чтобы гарантировать целостность системы, такие висячие ссылки должны быть предотвращены. [16]
Вероятно, ни у кого не вызывает сомнения, что висячие ссылки потенциально опаснее мусора. Накопление мусора ведет к истощению пригодной для работы памяти, но висячие ссылки могут вызвать совершенный хаос, поскольку используемая память подвергается случайным изменениям. Конечно, обе эти проблемы взаимосвязаны: висячие ссылки появляются, когда память освобождается слишком быстро, а мусор - когда она слишком долго не освобождается. Если нежелательно или слишком дорого использовать какой-нибудь механизм вроде счетчиков ссылок для устранения сразу обеих проблем, то, очевидно, следует предпочесть присутствие мусора, но избежать висячих ссылок. Лучше вовсе не использовать память повторно, чем использовать ее раньше времени. [17]
Метод явного возврата мог бы показаться вполне естественным методом утилизации при организации памяти в виде кучи, но, к сожалению, он не всегда применим. Причина этого заключена в двух старых проблемах: проблеме мусора и проблеме висячих ссылок. Первый раз мы обсуждали эти проблемы в гл. Если структура уничтожается ( и занятая ею память освобождается) до разрушения всех путей доступа к этой структуре, то оставшиеся пути доступа становятся висячими ссылками. С другой стороны, если последний путь доступа к структуре уничтожается, а сама структура не уничтожается и память не освобождается, то эта структура становится мусором. Мусором является такой элемент, который пригоден для повторного использования, но не содержится в списке свободного пространства и потому недоступен. [18]
Поскольку при явном возврате, как мы видели, возникает немало проблем, желательно иметь другие методы. В одном из них, называемом сбором мусора, допускается порождение мусора, но не висячих ссылок. Затем, если список свободного пространства исчерпается, вызывается механизм сбора мусора, который находит мусор. Вторая альтернатива, метод счетчиков ссылок, требует явного возврата, но обеспечивает способ проверки числа указателей на данный элемент с тем, чтобы предотвратить образование висячих ссылок. [19]
Безопасность доступа к данным в значительной степени определяет надежность программного обеспечения. Опасная практика заключается, например, в бесконтрольном использовании указателей ( что ведет к заблу-дившимвя и висячим ссылкам), в отсутствии контроля трактовки внутреннего представления при использований записей с вариантами, в нарушении механизма контроля типов с помощью трюков. [20]
Если же CDR возвратит элемент в список свободного пространства и на этот элемент существуют другие указатели, то все эти указатели станут висячими ссылками. Если мы не располагаем прямым способом, позволяющим определить наличие таких указателей, то операция CDR потенциально должна порождать мусор или висячие ссылки. [21]
Ада являются присваивание и сравнение. Ограничения, связанные с использованием указателей, специально включены в язык Ада с целью предотвратить бесконтрольное использование указателей, которое может привести к таким проблемам, как ошибочная ссылка не туда, куда нужно, или висячая ссылка. [22]
Висячие ссылки возшп:::: /:, если структура данных уничтожается прежде, чем будут разрушены все пути доступа к этой структуре. Важнейшим источником путей доступа к структурам данных являются ассоциации идентификаторов. Однако висячие ссылки могут образовываться также, если в других структурах существуют указатели на разрушенную структуру; поэтому проблема висячих ссылок не является проблемой только управления данными, а имеет более общее зна чение. [23]
Появление висячих ссылок вызывается тем, что утилизация памяти, занимаемой уничтоженной структурой, происходит слишком быстро, раньше, чем будут разрушены все пути доступа. Висячих ссылок можно избежать, если применить такую операцию уничтожения, которая разрушает путь доступа, но не возвращает занимаемую структурой память для повторного использования до тех пор, пока не будет разрушен последний путь доступа. Однако, поскольку трудно проследить все пути доступа к данной структуре, может возникнуть такая ситуация, когда все пути доступа разрушены, а сама структура не возвращена в свободную память. [24]
В ПЛ / I при действиях с указателями во время выполнения программы отсутствуют какие-либо дескрипторы и не производится проверка типа данных. Это повышает эффективность выполнения программы, но зато программист должен сам следить за правильностью использования указателей. В частности, при некорректном употреблении указателей могут легко возникнуть висячие ссылки и мусор, никаких системных средств для защиты от таких ситуаций не предусмотрено. [25]
Вероятно, ни у кого не вызывает сомнения, что висячие ссылки потенциально опаснее мусора. Накопление мусора ведет к истощению пригодной для работы памяти, но висячие ссылки могут вызвать совершенный хаос, поскольку используемая память подвергается случайным изменениям. Конечно, обе эти проблемы взаимосвязаны: висячие ссылки появляются, когда память освобождается слишком быстро, а мусор - когда она слишком долго не освобождается. Если нежелательно или слишком дорого использовать какой-нибудь механизм вроде счетчиков ссылок для устранения сразу обеих проблем, то, очевидно, следует предпочесть присутствие мусора, но избежать висячих ссылок. Лучше вовсе не использовать память повторно, чем использовать ее раньше времени. [26]
Аналогичные проблемы возникают в случае операций, исключающих элементы из структур данных. Мы подробно рассмотрим методы, с помощью которых можно избежать появления мусора и висячих ссылок, в гл. [27]
Здесь наблюдаются сравнительно малые отличия от случая фиксированного размера блоков. Явный возврат освобождаемой памяти в список свободного пространства является простейшим методом, но по-прежнему возникают проблемы мусора и висячих ссылок. [28]
При каждом входе в подпрограмму или блок создается запись активации, и ей выделяется память на вершине стека. При каждом выходе из подпрограммы или блока память, выделенная соответствующей записи активации, освобождается. Тщательная разработка языка позволяет при выходе из соответствующего блока или подпрограммы осуществлять немедленное освобождение памяти, не приводящее к появлению висячих ссылок. [29]
Вследствие сложности языка и необходимости получения эффективного выполняемого кода компиляция программ, написанных на ПЛ / I, трудна. Программы во время выполнения представляются в машинном коде и обрабатываются аппаратным интерпретатором, но для управления памятью и моделирования многих примитивов необходимо значительное программное обеспечение. Однако при управлении кучей используется только простой метод явного выделения и освобождения памяти; программист должен сам следить за тем, чтобы не возникало мусора и висячих ссылок. Поэтому управление кучей не приводит к значительному увеличению времени выполнения программы. [30]