Quanto è diversa la garbage collection in pure lingue?

25

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 rifiuti per natura (catene di map che creano elenchi intermedi, ad esempio).

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

    
posta Jack 06.09.2015 - 10:26
fonte

2 risposte

13

L'attuale implementazione di ghc utilizza una strategia che funziona solo perché il linguaggio è puro funzionale e il dato è immutabile: poiché nessuna variabile può mai essere modificata per riferirsi a qualcosa di più recente, gli oggetti mantengono solo riferimenti a oggetti più vecchi, quindi esegue un immondizia generazionale; poiché un oggetto a cui si fa riferimento da una generazione più alta non può essere cancellato fino a che la generazione non è GCd, promuove ardentemente gli oggetti alle generazioni più elevate; e dato che nulla cambierà i riferimenti mentre il GC li sta eseguendo, può essere eseguito in parallelo.

Ecco un articolo con maggiori dettagli .

    
risposta data 06.09.2015 - 19:48
fonte
1

In a pure language like Haskell, all data is immutable and no existing data structures can be changed in any way

In realtà non è generalmente vero. Le lingue pure usano una valutazione non severa (pigra), quindi la valutazione di potenzialmente tutte le sottoespressioni viene differita. Le espressioni non valutate sono generalmente heap assegnate come "thunk". Quando richiesto, l'espressione viene valutata e il thunk è mutato nel valore risultante.

What strategies and techniques do garbage collectors employ in the face of purity that they wouldn't otherwise?

L'unica cosa che posso pensare è buchi neri . Non ricordo di aver visto niente di nuovo sul lato GC nei documenti di ricerca di Haskell.

What works very well in an impure language's GC that doesn't in a pure context?

La barriera di scrittura GC. I linguaggi impuri tendono a scrivere molto più puntatori nell'heap in modo che tendano ad avere le barriere di scrittura più strongmente ottimizzate.

Altri algoritmi GC come mark-region sono molto più fattibili nel contesto delle lingue impure perché possono avere tassi di allocazione molto più bassi rispetto alle lingue pure.

What other new problems do pure languages create for GCs?

I linguaggi puri sono molto rari, quindi ci sono molti meno dati su come i programmi puri usano la memoria e, pertanto, stai iniziando una posizione peggiore quando provi a scrivere un GC per un linguaggio puro.

    
risposta data 27.01.2016 - 01:46
fonte