Perché linguaggi come C e C ++ non hanno Garbage Collection, mentre Java lo fa? [chiuso]

Bene, so che ci sono cose come malloc / free per C e new / using-a-destructor per la gestione della memoria in C ++, ma mi chiedevo perché non ci sono "nuovi aggiornamenti" in queste lingue che consentono all'utente di hai la possibilità di gestire manualmente la memoria o che il sistema la esegua automaticamente (garbage collection)?

Un po 'una domanda nuova, ma è stato in CS solo per circa un anno.

La garbage collection richiede strutture di dati per tracciare le allocazioni e / o il conteggio dei riferimenti. Questi creano sovraccarico di memoria, prestazioni e complessità del linguaggio. C ++ è progettato per essere "vicino al metallo", in altre parole, prende il lato di prestazioni più elevate delle funzionalità di compromesso rispetto alla convenienza. Altre lingue rendono questo compromesso in modo diverso. Questa è una delle considerazioni nella scelta di una lingua, quale enfasi preferisci.

Detto questo, ci sono molti schemi per il conteggio dei riferimenti in C ++ che sono abbastanza leggeri e performanti, ma si trovano in librerie, sia commerciali che open source, piuttosto che parte del linguaggio stesso. Il conteggio dei riferimenti per gestire la durata degli oggetti non è lo stesso della garbage collection, ma affronta molti degli stessi problemi e si adatta meglio all'approccio di base di C ++.

A rigor di termini, non esiste alcuna gestione della memoria nel linguaggio C. malloc () e free () non sono parole chiave nella lingua, ma solo funzioni che vengono chiamate da una libreria. Questa distinzione può essere pedante ora, perché malloc () e free () fanno parte della libreria standard C e saranno forniti da qualsiasi implementazione conforme standard di C, ma questo non era sempre vero in passato.

Perché vorresti una lingua senza standard per la gestione della memoria? Questo risale alle origini di C come "assemblaggio portatile". Esistono molti casi di hardware e algoritmi che possono beneficiare o addirittura richiedere tecniche specializzate di gestione della memoria. Per quanto ne so, non c'è modo di disabilitare completamente la gestione della memoria nativa di Java e sostituirla con la propria. Questo semplicemente non è accettabile in alcune situazioni ad alte prestazioni / risorse minime. C offre una flessibilità quasi completa per scegliere esattamente quale infrastruttura verrà utilizzata dal programma. Il prezzo pagato è che il linguaggio C fornisce pochissimo aiuto nella scrittura di codice corretto e privo di bug.

La vera risposta è che l'unico modo per creare un meccanismo di raccolta dei rifiuti sicuro ed efficiente è disporre di un supporto a livello di lingua per riferimenti opachi. (O, al contrario, una mancanza di supporto a livello di lingua per la manipolazione diretta della memoria.)

Java e C # possono farlo perché hanno tipi di riferimento speciali che non possono essere manipolati. Questo dà al runtime la libertà di fare cose come spostare oggetti allocati in memoria , che è cruciale per un'implementazione GC ad alte prestazioni.

Per la cronaca, nessuna moderna implementazione di GC utilizza il conteggio dei riferimenti , quindi è completamente un'aringa rossa. I GC moderni utilizzano la raccolta generazionale, in cui le nuove allocazioni vengono trattate essenzialmente nello stesso modo in cui le allocazioni dello stack sono in un linguaggio come C ++, e quindi periodicamente tutti gli oggetti allocati di recente che sono ancora vivi vengono spostati in uno spazio "sopravvissuto" separato e un'intera generazione di oggetti viene deallocato in una sola volta.

Questo approccio presenta vantaggi e svantaggi: il lato positivo è che le allocazioni di heap in una lingua che supporta GC sono veloci quanto le allocazioni di stack in una lingua che non supporta GC, e il lato negativo è che gli oggetti che devono eseguire la pulizia prima di essere distrutti richiedono un meccanismo separato (ad esempio la usingparola chiave di C # ) oppure il loro codice di pulizia viene eseguito in modo non deterministico.

Si noti che una chiave per un GC ad alte prestazioni è che ci deve essere supporto linguistico per una classe speciale di riferimenti. C non ha questo supporto linguistico e non lo farà mai; poiché il C ++ ha un sovraccarico da parte dell'operatore, potrebbe emulare un tipo di puntatore GC'd, sebbene debba essere eseguito con attenzione. Infatti, quando Microsoft ha inventato il suo dialetto di C ++ che sarebbe stato eseguito sotto il CLR (il runtime .NET), hanno dovuto inventare una nuova sintassi per "riferimenti in stile C #" (ad esempio Foo^) per distinguerli da "riferimenti in stile C ++" (ad es Foo&.).

Ciò che ha C ++ e ciò che viene regolarmente utilizzato dai programmatori C ++ sono i puntatori intelligenti , che sono in realtà solo un meccanismo di conteggio dei riferimenti. Non considererei il conteggio dei riferimenti come GC "vero", ma offre molti degli stessi vantaggi, a costo di prestazioni più lente rispetto alla gestione manuale della memoria o al vero GC, ma con il vantaggio della distruzione deterministica.

Alla fine della giornata, la risposta si riduce davvero a una funzionalità di progettazione del linguaggio. C ha fatto una scelta, C ++ ha fatto una scelta che gli ha permesso di essere retrocompatibile con C pur fornendo alternative che sono abbastanza buone per la maggior parte degli scopi, e Java e C # hanno fatto una scelta diversa che è incompatibile con C ma è anche abbastanza buona per la maggior parte degli scopi. Sfortunatamente, non esiste un proiettile d'argento, ma avere familiarità con le diverse scelte là fuori ti aiuterà a scegliere quella corretta per qualsiasi programma che stai attualmente cercando di costruire.

Perché, quando si utilizza la potenza del C ++, non è necessario.

Herb Sutter: " Non scrivo cancellare da anni. "

vedi Scrivere codice C ++ moderno: come si è evoluto il C ++ negli anni 21:10

Potrebbe sorprendere molti programmatori C ++ esperti.

"Tutto" è un garbage collector è un processo che viene eseguito periodicamente controllando se sono presenti oggetti non referenziati in memoria e se sono eliminati. (Sì, so che questa è una semplificazione eccessiva). Questa non è una proprietà della lingua, ma il framework.

Ci sono netturbini scritti per C e C ++ - questo uno per esempio.

Uno dei motivi per cui uno non è stato "aggiunto" alla lingua potrebbe essere a causa del volume di codice esistente che non lo userebbe mai poiché usano il proprio codice per gestire la memoria. Un altro motivo potrebbe essere che i tipi di applicazioni scritte in C e C ++ non necessitano dell'overhead associato a un processo di garbage collection.

C è stata progettata in un'epoca in cui la raccolta dei rifiuti era a malapena un'opzione. Era inoltre destinato a usi in cui la garbage collection non funzionava generalmente: bare metal, ambienti in tempo reale con memoria minima e supporto minimo di runtime. Ricorda che C era il linguaggio di implementazione per il primo unix, che girava su un pdp-11 con 64 * K * byte di memoria. Il C ++ era originariamente un'estensione di C: la scelta era già stata fatta ed è molto difficile innestare la garbage collection su un linguaggio esistente. È il tipo di cosa che deve essere integrato dal piano terra.

Non ho le virgolette esatte ma sia Bjarne che Herb Sutter dicono qualcosa del genere:

C ++ non ha bisogno di un garbage collector, perché non ha spazzatura.

Nel moderno C ++ usi i puntatori intelligenti e quindi non hai immondizia.

Ti chiedi perché queste lingue non sono state aggiornate per includere un garbage collector opzionale.

Il problema con la garbage collection opzionale è che non è possibile mescolare il codice che utilizza i diversi modelli. Cioè, se scrivo un codice che presume che tu stia utilizzando un garbage collector, non puoi usarlo nel tuo programma che ha la garbage collection disattivata. Se lo fai, perderà dappertutto.

Riesci a immaginare di scrivere un gestore di dispositivi in ​​una lingua con Garbage Collection? Quanti bit potrebbero scendere lungo la linea mentre il GC era in esecuzione?

O un sistema operativo? Come hai potuto avviare l'esecuzione della garbage collection prima ancora di avviare il kernel?

C è progettato per un livello basso vicino alle attività hardware. Il problema? è un linguaggio così carino che è una buona scelta anche per molte attività di livello superiore. Gli zar del linguaggio sono consapevoli di questi usi ma devono supportare i requisiti dei driver di dispositivo, del codice incorporato e dei sistemi operativi come priorità.

La risposta breve e noiosa a questa domanda è che deve esserci un linguaggio raccolto non spazzatura là fuori per le persone che scrivono i garbage collector. Concettualmente non è facile avere un linguaggio che allo stesso tempo consenta un controllo molto preciso sul layout della memoria e che abbia un GC in esecuzione.

L'altra domanda è perché C e C ++ non hanno garbage collector. Bene, so che il C ++ ne ha un paio in giro, ma non sono molto popolari perché sono costretti a gestire un linguaggio che non è stato progettato per essere GC-ed in primo luogo, e le persone che usano ancora C ++ in questa età non è proprio il tipo che manca a un GC.

Inoltre, invece di aggiungere GC a un vecchio linguaggio non GC-ed, in realtà è più facile creare un nuovo linguaggio che abbia la stessa sintassi supportando un GC. Java e C # ne sono un buon esempio.

Ci sono vari problemi, tra cui ...

• Sebbene GC sia stato inventato prima del C ++, e probabilmente prima del C, sia il C che il C ++ furono implementati prima che i GC fossero ampiamente accettati come pratici.
• Non è possibile implementare facilmente un linguaggio e una piattaforma GC senza un linguaggio non GC sottostante.
• Sebbene GC sia dimostrabilmente più efficiente di un non GC per il tipico codice di applicazioni sviluppato in tempi tipici, ecc., Ci sono problemi in cui un maggiore sforzo di sviluppo è un buon compromesso e la gestione della memoria specializzata supererà un GC generico. Inoltre, il C ++ è tipicamente più efficiente della maggior parte dei linguaggi GC anche senza ulteriori sforzi di sviluppo.
• GC non è universalmente più sicuro di RAII in stile C ++. RAII consente di ripulire automaticamente risorse diverse dalla memoria, fondamentalmente perché supporta distruttori affidabili e tempestivi. Questi non possono essere combinati con i metodi GC convenzionali a causa di problemi con i cicli di riferimento.
• I linguaggi GC hanno i loro tipi caratteristici di perdite di memoria, in particolare per quanto riguarda la memoria che non verrà mai più utilizzata, ma dove esistevano riferimenti esistenti che non sono mai stati annullati o sovrascritti. La necessità di farlo esplicitamente non è diversa in linea di principio rispetto alla necessità deleteo freeesplicitamente. L'approccio GC ha ancora un vantaggio - nessun riferimento penzolante - e l'analisi statica può rilevare alcuni casi, ma ancora una volta non esiste una soluzione perfetta per tutti i casi.

Fondamentalmente, in parte riguarda l'età delle lingue, ma ci sarà comunque sempre posto per le lingue non GC - anche se è un po 'un posto di nicchia. E seriamente, in C ++, la mancanza di GC non è un grosso problema: la tua memoria è gestita in modo diverso, ma non è non gestita.

Il C ++ gestito da Microsoft ha almeno una certa capacità di mescolare GC e non GC nella stessa applicazione, consentendo un mix-and-match dei vantaggi di ciascuno, ma non ho l'esperienza per dire quanto funzioni in pratica.

Collegamenti di puttana alle mie risposte correlate ...

• https://stackoverflow.com/questions/1529679/how-do-you-program-safely-outside-of-a-managed-code-environment/1529731#1529731
• https://stackoverflow.com/questions/1424660/garbage-collection-vs-non-garbage-collection-programming-languages/1496547#1496547
• https://stackoverflow.com/questions/4984849/why-circular-referenced-objects-with-del-defined-are-uncollectable-in-python/4984934#4984934
• https://stackoverflow.com/questions/5009869/how-to-implement-garbage-collection-in-c/5009984#5009984

La garbage collection è fondamentalmente incompatibile con un linguaggio di sistema utilizzato per lo sviluppo di driver per hardware compatibile con DMA.

È del tutto possibile che l'unico puntatore a un oggetto venga archiviato in un registro hardware in alcune periferiche. Dato che il garbage collector non lo sapeva, avrebbe pensato che l'oggetto non fosse raggiungibile e lo avrebbe raccolto.

Questo argomento vale doppio per la compattazione di GC. Anche se stai attento a mantenere i riferimenti in memoria agli oggetti utilizzati dalle periferiche hardware, quando il GC riposiziona l'oggetto, non saprebbe come aggiornare il puntatore contenuto nel registro di configurazione delle periferiche.

Quindi ora avresti bisogno di una miscela di buffer DMA immobili e oggetti gestiti da GC, il che significa che hai tutti gli svantaggi di entrambi.

Perché, C & C ++ sono linguaggi di livello relativamente basso pensati per scopi generali, anche, ad esempio, per funzionare su un processore a 16 bit con 1 MB di memoria in un sistema incorporato, che non poteva permettersi di sprecare memoria con gc.

Esistono garbage collector in C ++ e C. Non sei sicuro di come funzioni in C, ma in C ++ puoi sfruttare RTTI per scoprire dinamicamente il tuo grafico a oggetti e usarlo per Garbage Collection.

Per quanto ne so, non è possibile scrivere Java senza un Garbage Collector. Una piccola ricerca ha rivelato questo .

La differenza chiave tra Java e C / C ++ è che in C / C ++ la scelta è sempre tua, mentre in Java spesso non hai opzioni di progettazione.

È un compromesso tra prestazioni e sicurezza.

Non vi è alcuna garanzia che i rifiuti vengano raccolti in Java, quindi potrebbe rimanere inutilizzato per molto tempo, mentre la scansione di oggetti non referenziati (ad esempio i rifiuti) richiede anche più tempo rispetto all'eliminazione o alla liberazione esplicita di un oggetto non utilizzato.

Il vantaggio è, ovviamente, che si può costruire una lingua senza puntatori o senza perdite di memoria, quindi è più probabile che produca codice corretto.

A volte questi dibattiti possono avere un leggero vantaggio "religioso": attenzione!

Ecco un elenco di problemi inerenti a GC, che lo rendono inutilizzabile in un linguaggio di sistema come C:

• Il GC deve funzionare al di sotto del livello del codice di cui gestisce gli oggetti. Semplicemente non esiste un tale livello in un kernel.

• Un GC deve arrestare il codice gestito di volta in volta. Ora pensa a cosa succederebbe se lo facesse al tuo kernel. Tutta l'elaborazione sulla macchina si arresterebbe, per esempio, per un millisecondo, mentre il GC esegue la scansione di tutte le allocazioni di memoria esistenti. Ciò ucciderebbe tutti i tentativi di creare sistemi che funzionino con severi requisiti in tempo reale.

• Un GC deve essere in grado di distinguere tra puntatori e non puntatori. Cioè, deve essere in grado di guardare ogni oggetto di memoria esistente ed essere in grado di produrre un elenco di offset in cui è possibile trovare i suoi puntatori.

  Questa scoperta deve essere perfetta: il GC deve essere in grado di inseguire tutti i puntatori che scopre. Se dereferenziasse un falso positivo, probabilmente si schianterebbe. Se non fosse in grado di rilevare un falso negativo, probabilmente distruggerebbe un oggetto ancora in uso, causando l'arresto anomalo del codice gestito o corrompendo silenziosamente i suoi dati.

  Ciò richiede assolutamente che le informazioni sul tipo siano archiviate in ogni singolo oggetto esistente. Tuttavia, sia C che C ++ consentono oggetti dati semplici vecchi che non contengono informazioni sul tipo.

• GC è un'attività intrinsecamente lenta. I programmatori che sono stati socializzati con Java potrebbero non rendersene conto, ma i programmi possono essere ordini di grandezza più veloci quando non sono implementati in Java. E uno dei fattori che rendono lento Java è GC. Questo è ciò che impedisce ai linguaggi GCed come Java di essere utilizzati nel supercalcolo. Se la tua macchina costa un milione di consumi energetici all'anno, non vuoi pagare nemmeno il 10% di quello per la raccolta dei rifiuti.

C e C ++ sono linguaggi creati per supportare tutti i possibili casi d'uso. E, come vedi, molti di questi casi d'uso sono preclusi dalla raccolta dei rifiuti. Quindi, al fine di supportare questi casi d'uso, C / C ++ non può essere garbage collection.