Все ли программы должны иметь стек и кучу?
В настоящее время большинство, если не все, программ имеют «стек» для объектов, размер которых известен во время компиляции, и «кучу» для динамически выделяемых объектов.
Где это реализуется на практике? На уровне процессора, ОС или программы? Должна ли каждая программа поставляться с каким-то кодом для управления стеком и кучей?
Может ли появиться новый язык программирования, который будет использовать совершенно другую парадигму памяти и при этом работать на современных ОС?
1 ответ
То, о чем вы думаете, в основном охватывается платформой ABI (двоичный интерфейс приложения), которая включает в себя такие детали, как соглашения о вызовах.
Существует множество языков программирования, которые не используют системный стек или используют его только для целей взаимодействия. Гораздо чаще в интерпретируемых языках используется другой стек. Однако некоторые компилируемые языки реализуют свои собственные стеки. Обычно вы хотите реализовать свой собственный стек, если вам нужны простые замыкания, расширенные функции потока управления или зеленые потоки, как в Go.
Многие языки программирования со сборкой мусора создают свои собственные кучи. Существует небольшая проблема с невозможностью использования общих ресурсов, но обычно это не проблема, поскольку альтернативные API, такие как обычно, достаточно хороши для получения больших блоков памяти. Якобы для ASLR (рандомизация расположения адресного пространства)mmapЭто лучше чемsbrk.
Более конкретно, существует программное обеспечение с ограниченными ресурсами, которое не использует кучу или стек, а просто распределяет всю память статически. Обычно вы выделяете память в сегменты, из которых все равно динамически распределяете. Сейчас подобные вещи встречаются реже.
С точки зрения формальных методов куча и стек соответствуют «Хранилищу» и «Продолжению» машины CESK (Продолжение хранилища среды управления). Также есть история о контекстах и стеках с одной дыркой, но я менее ясен в этом вопросе.