Выключение сборщика мусора D

Я программист на С++, который рассматривает возможность использования D для личного проекта, с которым я хочу поиграть. Мне было интересно, есть ли способ полностью отключить сборщик мусора и каковы риски этого.

Я знаю, что могу управлять своей собственной памятью, переопределяя новые и удалять, чтобы использовать malloc и бесплатно, но если бы я сделал это, я бы предпочел, чтобы сборщик мусора вообще не запускался.

Ответ 1

Чтобы отключить GC в D2:

import core.memory;

void main(string[] args) {
    GC.disable;
    // Do stuff.
}

Если используется D1/Фобос:

import std.gc;

void main(char[][] args) {
    std.gc.disable;
    // Do stuff.
}

В D1/Tango:

import tango.core.Memory;

void main(char[][] args) {
    GC.disable;
    // Do stuff.
}

GC может быть повторно подключен аналогично вызовом GC.enable(D2 или D1/Tango) или std.gc.enable(D1/Phobos). Это можно сделать в любой момент программы. Внутри используется счетчик, и для фактического повторного включения GC вы должны вызывать enable() один раз для каждого вызова disable().

Вот некоторые вещи, которые не связаны с отключением GC, потому что они вызовут утечки памяти:

Не используйте оператор массива append (~ =) или используйте свойство .length для увеличения массива, который уже был выделен. Они полагаются на GC, чтобы освободить старый массив, если он должен быть перераспределен, поскольку в нем может быть сглаживание в другом месте программы.
Не используйте встроенные ассоциативные массивы. Единственный способ освободить их - GC.
Большинство Phobos и, я считаю, Tango, были спроектированы с предположением о том, что сбор мусора присутствует. Функции в этих библиотеках могут сильно испортить память при использовании без GC.
Не используйте закрытие D2 с отключенным GC. (Не то, чтобы вы все равно играли.)

Тем не менее, в то время как D предназначен для использования с отключенным GC в нескольких критических фрагментах кода (типа критических элементов, где существуют ограничения в режиме реального времени, и вы, вероятно, не должны использовать какую-либо форму malloc, явно не разработанную для вычисления в реальном масштабе времени в любом случае), он был в значительной степени разработан с предположением о том, что GC будет присутствовать. В вашем случае вы все равно можете использовать GC для всех вещей инициализации и т.д. И только отключите его, когда попадете в ту часть своей игры, которая на самом деле должна быть в режиме реального времени.

В качестве побочного примечания, GC и ручное управление памятью могут сосуществовать в D, и на практике, при оптимизации кода, ручное удаление некоторых крупных объектов с тривиальным временем жизни может привести к значительным ускорениям. Это можно сделать аналогично С++, используя инструкцию delete и безопасно делать, даже если GC включен. Когда у вас нет ограничений в режиме реального времени, это дает вам большую часть преимуществ GC с большей эффективностью ручного управления памятью.

Ответ 2

Если вы хотите использовать malloc и бесплатно использовать std.c.stdlib. GC никогда не коснется их. std.gc содержит все необходимое для управления памятью, включая disable().

GC - это не плохо. Большинство, если не почти все библиотеки в D будут иметь место в коде, где память явно не удалена, поэтому он не сделает вас героем, чтобы он всегда был выключен, но нормально, если у вас есть критические требования к производительности.

GC делает все намного более производительным, например, массивом резки и созданием новых объектов в параметрах без того, чтобы вызывающий сервер сохранял ссылку в любом месте. Хороший код намного меньше, а код GC становится намного меньше.

Ответ 3

GC можно удалить и заменить простой оберткой вокруг malloc/free.

Ответ 4

Я читал о языке D, и я нашел это в спецификации, которая кажется новой в D:

40. Лучше C

-betterC - это флаг командной строки для dmd, который ограничивает поддержку компилятора определенными функциями времени исполнения. Примечательно, что D-программы или библиотеки, скомпилированные с помощью bestC, не связаны с Druntime. Использование функций времени компиляции никоим образом не ограничено. https://dlang.org/spec/betterc.html

Одно из последствий использования этого флага командной строки - отключить ретрансляцию функций GC и языка.

40.1 Последствия

Поскольку не доступно Druntime, многие функции D не будут работать. Например:

Коллекция мусора

Потоковое локальное хранилище

TypeInfo и ModuleInfo

Классы

Встроенная потоковая передача (например, core.thread)

Динамические массивы (но не срезы) и ассоциативные массивы

Исключения

переключатель со строками

конечный коммутатор

synchronized и core.sync

Конструкторы или деконструкторы статического модуля

Структурные деконструкторы

unittest (тестирование может быть как обычно с флагом -betterC)

см. также https://dlang.org/blog/2017/08/23/d-as-a-better-c/