Garbage Collector

[Scara95]

Un GC si occupa di liberare la memoria allocata ma non più necessaria per renderla nuovamente disponibile.

Alcuni linguaggi sono progettati per usare un GC, sono stati pensati così e perciò materialmente non possono essere implementati senza.
Linguaggi come il C++ distruggono gli oggetti allocati all'uscita da uno scope. Java e C# invece, ad esempio, all'uscita dallo scope non fanno nulla se non "prendere atto che nulla punta più agli oggetti allocati". La memoria non viene quindi liberata, verrà liberata solo quando il GC lo riterrà necessario.
Altri esempi in cui senza un GC non sarebbe possibile un'implementazione (a meno di memoria infinita) sono i linguaggi funzionali.

In generale ogni linguaggio dove gli oggetti non hanno un lifetime prestabilito necessita di un GC (free è di fatto prestabilire la liberazione della memoria).

La presenza di un GC introduce il problema opposto: non conoscere il lifetime degli oggetti. Questo nella maggior parte dei casi non ti da alcun problema, ma in presenza di risorse speciali che devi assicurarti di rilasciare sempre è un problema. Un esempio: se utilizzi un file all'interno di una funzione in C++ sarai sicuro che all'uscita dalla funzione il file sarà liberato, in C# e Java no. E' a questo scopo che nascono keywords quale using in C# che viene tradotta con un try-finally che si assicura che venga sempre chiamata la funzione .Dispose() che libera le risorse di fatto invalidando l'oggetto, ma senza distruggerlo (ovvero, l'oggetto rimane allocato, vengono solo liberate le risorse speciali).

editSì, puoi sempre implementare un GC se non è disponibile con vari compromessi.

@MItaly si può dire che il reference counting sia la più facile forma di GC, infatti basta scrivere una funzione che utilizzi per l'assegnazione e una funzione per scartare i valori di ritorno non utilizzati.
Questo assumendo non siano presenti cicli, in questo caso quegli oggetti rimarrebbero fino all'uscita, dove la memoria sarebbe comunque liberata dal sistema.

[MItaly]

La presenza di un GC introduce il problema opposto: non conoscere il lifetime degli oggetti. Questo nella maggior parte dei casi non ti da alcun problema, ma in presenza di risorse speciali che devi assicurarti di rilasciare sempre è un problema. Un esempio: se utilizzi un file all'interno di una funzione in C++ sarai sicuro che all'uscita dalla funzione il file sarà liberato, in C# e Java no. E' a questo scopo che nascono keywords quale using in C# che viene tradotta con un try-finally che si assicura che venga sempre chiamata la funzione .Dispose() che libera le risorse di fatto invalidando l'oggetto, ma senza distruggerlo (ovvero, l'oggetto rimane allocato, vengono solo liberate le risorse speciali).

A tal proposito, questo è un articolo che mi ha aperto gli occhi sul GC: in linea di principio, il punto del GC non è deallocare gli oggetti una volta che non sono più raggiungibili, ma simulare un computer con memoria infinita, in cui non hai bisogno di curarti della deallocazione degli oggetti, per cui, avendo sufficiente memoria a disposizione, il runtime potrebbe tranquillamente rimandare la distruzione di tutti gli oggetti fino alla fine del programma. Questo significa che per qualunque risorsa che non sia la memoria, devi comunque metterti in piedi sistemi come Using/IDisposable, with/__enter__/__exit__, try...finally & co.

@MItaly si può dire che il reference counting sia la più facile forma di GC, infatti basta scrivere una funzione che utilizzi per l'assegnazione e una funzione per scartare i valori di ritorno non utilizzati.
Questo assumendo non siano presenti cicli, in questo caso quegli oggetti rimarrebbero fino all'uscita, dove la memoria sarebbe comunque liberata dal sistema.

Sì, leggendo l'articolo su Wikipedia ho visto che il reference counting viene considerato tra i metodi di garbage collection, per qualche motivo l'ho sempre considerata una cosa a parte.

[Scara95]

Beh, infatti a parte il Reference counting e altri algoritmi che si prefiggono di essere il più prevedibili possibile, in generale la memoria non verrà mai liberata a meno che non ve ne sia la necessità per mancanza di memoria libera o non sia stata raggiunta una soglia. Ad esempio il raddoppiamento della memoria allocata o simili...