Disattivazione del D Garbage Collector

Question

Sono un programmatore C ++ che sta pensando di usare D per un progetto personale con cui voglio giocare. Mi chiedevo se c'è un modo per disabilitare completamente il garbage collector e quali sono i rischi di farlo.

So di poter gestire la mia memoria ignorando new ed delete per usare malloc e free, ma se lo facessi preferirei che il garbage collector non funzionasse affatto.

Answer 1

Per disattivare il GC in D2:

import core.memory;

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

Se si utilizza D1 / Phobos:

import std.gc;

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

In D1 / Tango:

import tango.core.Memory;

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

Il GC può essere riattivato in modo simile chiamando GC.enable (D2 o D1 / Tango) o std.gc.enable (D1 / Phobos). Questi possono essere eseguiti in qualsiasi momento in un programma. Internamente, viene utilizzato un contatore e per riattivare effettivamente GC, è necessario chiamare enable () una volta per ogni volta che viene chiamato disable ().

Ecco alcune cose da non fare con GC disabilitato, perché causeranno perdite di memoria:

1. Non utilizzare l'operatore append array (~ =), né utilizzare la proprietà .length per ingrandire un array che è già stato allocato. Questi si basano su GC per liberare il vecchio array se deve essere riallocato, poiché potrebbe esserci un alias da qualche altra parte nel programma.
2. Non utilizzare array associativi incorporati. L'unico modo per liberarli è GC.
3. La maggior parte di Phobos e, credo, Tango, sono stati progettati partendo dal presupposto che sia presente la raccolta dei rifiuti. Le funzioni in queste librerie possono perdere orribilmente memoria se usate senza GC.
4. Non utilizzare chiusure D2 con GC disabilitato. (Non che lo faresti comunque, per un gioco.)

Detto questo, mentre D è progettato per essere utilizzabile con il GC disabilitato in alcuni pezzi di codice critici (il tipo di pezzi critici in cui esistono vincoli in tempo reale e probabilmente non dovresti usare alcuna forma di malloc non progettata esplicitamente per il calcolo in tempo reale comunque), è stato progettato in gran parte supponendo che GC sarebbe presente. Nel tuo caso, puoi comunque usare GC per tutte le cose di inizializzazione, ecc. E disabilitarlo solo quando colpisci la parte del tuo gioco che in realtà deve essere in tempo reale.

Come nota a margine, GC e la gestione manuale della memoria possono coesistere in D, e in pratica, durante l'ottimizzazione del codice, l'eliminazione manuale di alcuni oggetti di grandi dimensioni con banali tempi di vita può comportare accelerazioni significative. Questo può essere fatto in modo simile al C ++, usando un'istruzione delete, ed è sicuro da fare anche se il GC è abilitato. Quando non si hanno vincoli in tempo reale, questo offre la maggior parte dei vantaggi di GC con la maggior parte delle prestazioni della gestione manuale della memoria.

Answer 2

Se vuoi usare malloc e usare gratuitamente std.c.stdlib . GC non li toccherà mai. std.gc ha tutto ciò di cui hai bisogno per la gestione della memoria, incluso disabilitare ().

GC non è una brutta cosa però. La maggior parte se non quasi tutte le librerie in D avranno qualche parte nel codice in cui la memoria non viene esplicitamente cancellata, quindi non ti renderà un eroe per averlo sempre spento, ma ok se hai qualche requisito critico in termini di prestazioni.

GC rende tutto molto più produttivo come la suddivisione in array e la creazione di nuovi oggetti nei parametri senza che il chiamante memorizzi un riferimento ovunque. Il buon codice è molto meno e con il codice GC diventa molto più piccolo.

Answer 3

Il GC può essere rimosso e sostituito con un semplice wrapper attorno a malloc / free.

Answer 4

Stavo leggendo il linguaggio D e l'ho trovato nelle specifiche che sembrano nuove in D:

  

40. Meglio C

     

-betterC è un flag della riga di comando per dmd, che limita il supporto del compilatore di alcune funzionalità di runtime. In particolare, i programmi o le librerie D compilati con betterC non sono collegati a Druntime. L'uso delle funzionalità di compilazione non è limitato in alcun modo.    https://dlang.org/spec/betterc.html

Una delle conseguenze dell'utilizzo di questo flag della riga di comando è la disabilitazione di GC e funzionalità del linguaggio che vi inoltrano.

  

40.1 Conseguenze

     

Poiché non è disponibile Druntime, molte funzioni D non funzioneranno. Ad esempio:

     

  
• Garbage Collection
  
• Archivio locale thread
  
• TypeInfo e ModuleInfo
  
• Corsi
  
• Threading incorporato (ad esempio core.thread)
  
• Matrici dinamiche (ma non sezioni) e matrici associative
  
• Eccezioni
  
• passa con le stringhe
  
• switch finale
  
• sincronizzato e core.sync
  
• Costruttori o decostruttori di moduli statici
  
• Decostruttori strutturali
  
• unittest (il test può essere come al solito con il flag -betterC)
  

vedi anche https: // dlang. org / blog / 2017/08/23 / d-as-a-better-c /