Quanto è diversa la raccolta dei rifiuti nelle lingue pure?

In un linguaggio puro come Haskell, tutti i dati sono immutabili e nessuna struttura di dati esistente può essere modificata in alcun modo. Inoltre, molti algoritmi su dati immutabili e schemi di programmazione funzionale generano grandi quantità di immondizia per natura ( mapad esempio catene di creazione di elenchi intermedi).

Quali strategie e tecniche impiegano i netturbini di fronte alla purezza che non avrebbero altrimenti? Cosa funziona molto bene nel GC di un linguaggio impuro che non funziona in un contesto puro? Quali altri nuovi problemi creano i linguaggi puri per i GC?

L'attuale implementazione di ghc utilizza una strategia che funziona solo perché il linguaggio è puro funzionale e i dati sono immutabili: poiché nessuna variabile può mai essere modificata per fare riferimento a qualcosa di più nuovo, gli oggetti contengono solo riferimenti a oggetti più vecchi, quindi esegue un garbage collector generazionale ; poiché un oggetto a cui fa riferimento una generazione superiore non può essere eliminato fino a quando quella generazione non è GCd, promuove avidamente oggetti a generazioni superiori; e poiché nulla cambierà i riferimenti mentre il GC li sta spazzando, può funzionare in parallelo.

Ecco un documento con maggiori dettagli .

In un linguaggio puro come Haskell, tutti i dati sono immutabili e nessuna struttura di dati esistente può essere modificata in alcun modo

In realtà questo non è generalmente vero. I linguaggi puri usano una valutazione non rigorosa (pigra), quindi la valutazione di tutte le sottoespressioni è differita. Le espressioni non valutate sono generalmente heap allocate come "thunk". Quando richiesto, l'espressione viene valutata e il thunk viene mutato nel valore risultante.

Quali strategie e tecniche impiegano i netturbini di fronte alla purezza che non avrebbero altrimenti?

L'unica cosa che mi viene in mente sono i buchi neri . Non ricordo di aver visto nient'altro di nuovo sul lato GC nei documenti di ricerca di Haskell.

Cosa funziona molto bene nel GC di un linguaggio impuro che non funziona in un contesto puro?

La barriera di scrittura GC. I linguaggi impuri tendono a scrivere molti più punti nell'heap, quindi tendono ad avere le loro barriere di scrittura più fortemente ottimizzate.

Altri algoritmi GC come mark-region sono molto più praticabili nel contesto di linguaggi impuri perché possono avere tassi di allocazione molto più bassi rispetto ai linguaggi puri.

Quali altri nuovi problemi creano i linguaggi puri per i GC?

I linguaggi puri sono molto rari, quindi ci sono molti meno dati su come i programmi puri usano la memoria e, quindi, si inizia in una posizione peggiore quando si tenta di scrivere un GC per un linguaggio puro.