Garbage Collector

[frankj]

Salve, non so se sia la sezione giusta perché in realtà è una domanda molto generica, se ho sbagliato mi scuso in anticipo.

Mi chiedevo quali sono i linguaggi di programmazione che necessitano del GC, cioè o una lista di lunguaggi oppure se esiste una vera e propria clessificazione

Da quello che ho capito io è:
1)indispensabile in Java (poichè nn ci sono puntatatori espliciti)
2)non presente nei lunguaggi di basso livello
3)in C e C++ è implementabile ( a mano) o ci si affida rispettivamente al free() o ai distruttori ( salvo eventuali memory leaks)

Grazie in anticipo

[MItaly]

Onestamente non ho capito la domanda... stai chiedendo la lista di tutti i linguaggi in cui sia presente o implementabile un GC? A che servirebbe?

Nota comunque che non avere puntatori espliciti non implica automaticamente l'uso di un GC - potrei avere un linguaggio in cui ho puntatori "impliciti" alla Java (ossia, puntatori non modificabili) e comunque dover gestire manualmente la memoria, oppure un linguaggio in cui tutto è gestito tramite reference counting (Visual Basic "classico" ad esempio funzionava così, Python funziona con reference counting + GC per uccidere i cicli), o un linguaggio in cui gli oggetti hanno lifetime legato solo allo scope locale, per cui il lifetime degli oggetti è completamente determinato e non si rende necessario gestire le deallocazioni in altri modi.

A livello implementativo per poter avere un GC è fondamentale che il runtime possa tracciare i puntatori accessibili (in maniera diretta o indiretta) dalle variabili visibili al programma, per il resto non direi che ci sono particolari altri vincoli sul tipo di linguaggio (anche se in genere la GC è fornita da linguaggi di più alto livello).

[frankj]

Intanto garzie per la risposta

Onestamente non ho capito la domanda

forse mi sono spiegato male, quindi ti giro la domanda (completa) che è stata posta a me...e alla quale ho trovato difficoltà a rispondere forse perchè non conosco poi così bene l'argomento:

"definizione di garbage collection con un semplice esempio, ed elenco dei linguaggi di programmazione che necessitano di garbage collection"

...ora io leggendo tale domenda.....penso sia stupido fare un elenco (tipo lista della spesa) di tutti i linguaggi......ma piuttosto sarei orientato a una divisione per genere o cmq ad una classificazione più generale, ma nn avendo libri a disposizione e nn avendo trovato poi molto in rete mi chiedevo se qlc potesse darmi qlc dritta in merito.

A livello implementativo per poter avere un GC è fondamentale che il runtime possa tracciare i puntatori accessibili (in maniera diretta o indiretta) dalle variabili visibili al programma, per il resto non direi che ci sono particolari altri vincoli sul tipo di linguaggio (anche se in genere la GC è fornita da linguaggi di più alto livello).

in base a quanto mi dici quà...quindi potenzialmente qls linguaggio che può accedere a tutto l'albero dei riferimenti può implementare (di default o attraverso un app scritta dall'utente) un GC ???????.....o ho capito male

[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.

[M.A.W. 1968]

Il più colossale problema dei GC, anche nelle loro forme più embrionali (vedi reference counting), è la totale asincronicità e impredicibilità. Questo ne esclude totalmente a priori l'uso nei sistemi in tempo reale, a maggior ragione per i linguaggi interpretati del mainstream.

Naturalmente non si deve cadere nella fallacia di falsa generalizzazione che, ad esempio, tutti i linguaggi "ad oggetti" OOPL richiedano necessariamente un garbage collector. C++ potrebbe essere considerato la più nota eccezione alla regola, ma è noto che tale linguaggio è tutt'altro che un perfetto esempio di OOPL: invece Ada, specificatamente nelle sue due più recenti incarnazioni Ada 95 e 2005, rappresenta un esempio paradigmatico in tale senso. Pur essendo un OOPL molto vicino alla perfezione secondo i sette criteri di Meyer, Ada non ha un GC perché tale motore semplicemente confliggerebbe con i requisiti dei sistemi realtime nei quali è presente un runtime Ada segregato, ma offre la possibilità di linkare specifici meccanismi di finalizzazione (che è esattamente l'opposto concettuale della persistenza) definiti dall'utente per particolari tagged types. Per contro, Eiffel usa internamente un sofisticato GC, i cui pochi dettagli implementativi resi disponibili da ISE rendono piuttosto chiaro che si tratta di un sistema unico nel suo genere rispetto ai criteri "standard" ben noti nella comunità del software engineering, come quelli di Boehm.

[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...