Отключение сборщика мусора D - PullRequest
24 голосов
/ 23 января 2009

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

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

Ответы [ 4 ]

41 голосов
/ 23 января 2009

Чтобы отключить ГХ в 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 / Танго:

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, поскольку они могут вызвать утечку памяти:

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

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

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

8 голосов
/ 23 января 2009

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

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

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

1 голос
/ 03 января 2018

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

40. Лучше C

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

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

40,1 Последствия

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

  • Сборка мусора
  • Поток-локальное хранилище
  • TypeInfo и ModuleInfo
  • Классы
  • Встроенная резьба (например, core.thread)
  • Динамические массивы (но не срезы) и ассоциативные массивы
  • Исключения
  • переключатель со строками
  • конечный выключатель
  • синхронизировано и core.sync
  • Статические модульные конструкторы или деконструкторы
  • Структурные деконструкторы
  • unittest (тестирование может быть как обычно с флагом -betterC)

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

1 голос
/ 23 января 2009

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

...