Warum sind Garbage Collectors böse?

Hobbyist schrieb:
> Trotzdem lese ich hier oft, dass bestimmte Zeitgenossen diese
> Funktionalität verteufeln. Warum eigentlich? Was spricht gegen die
> Verwendung einer automatischen Speicherverwaltung?

Der Anwendungsbereich.

Auf einem Mikrocontroller wuerde sich der Overhead eines GC sehr 
bemerkbar machen.

Das und Generationskonflikte.. ;)
Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"

In dem Artikel über Android und der neuen VM ART wird ein wenig auf die 
Vor- und Nachteile eingegangen und die Schwierigkeiten einen guten 
Garbage Collector zu bauen.
http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2

Peter II schrieb:
> Fast jede javaanwendung hat ein Speichleck. Je länger sie laufen, desto
> mehr Speicher wird verwendet.

Wenn ich mir das hier so ansehe
http://acadopus.de/java/die-typischen-faelle-von-memory-leaks-in-java-anwendungen_4002.html
dann hängen diese Probleme weniger mit GC zusammen, als mit der recht 
freizügigen Verwendung von Speicher generell, mit Links an sonstundeiner 
Stelle. Die meisten dort beschriebenen Effekte betreffen Speicher, der 
tatsächlich noch referenziert wird, auch wenn die Links vielleicht 
niemand mehr wirklich braucht. Ob das dann per GC oder anders behandelt 
wird ändert nichts am Volumen.

Peter II schrieb:
> Fast jede javaanwendung hat ein Speichleck. Je länger sie laufen, desto
> mehr Speicher wird verwendet.
>
> Bei einfachen Objekten mag das ja noch alles gehen, aber sobald
> resourcen verwendet werden (files, Schriftarten, threads), klappt das
> einfach nicht.

Ein GC verhindert nicht alle Speicherlecks, genausowenig wie selber den 
Speicher zu verwalten, nur muss man mit einem GC weniger darauf achten 
wo ich einen String erzeugt habe und wo ich ihn dann aufraeumen muss.

Es ist IMHO schon mal ein Schritt in die richtige Richtung auf 
"nicht-embedded Systemen" einen GC zu verwenden, falls Entwicklungszeit 
eine Rolle spielt.

Michael schrieb:
> Es gibt seit
> Jahrzehnten speziell für den Embedded-Bereich entwickelte GCs, die nicht
> nur berechenbar sind, sondern sogar Echtzeitgarantien geben.

einen Namen dazu?

Ich verzichte auf Controllern generell auf dynamischen Speicher. Waer 
bloed wenn's grad keinen mehr hat, oder nur zerstueckelt

dumdi dum schrieb:
> Michael schrieb:
>> Es gibt seit
>> Jahrzehnten speziell für den Embedded-Bereich entwickelte GCs, die nicht
>> nur berechenbar sind, sondern sogar Echtzeitgarantien geben.
>
> einen Namen dazu?

Michael schrieb:
> Ist nicht wirklich mein Gebiet, aber ich weiß, daß Harlequin das hatte.
> Mittlerweile heißen die LispWorks.

Ich kann mir das kaum vorstellen, weil LispWorks eigentlich nicht für 
Embedded Anwendungen gedacht ist. F

Magst Du da nicht mal nachforschen ? Wäre sehr interessant.

Grüße
Andreas

Peter II schrieb:

> Fast jede javaanwendung hat ein Speichleck. Je länger sie laufen, desto
> mehr Speicher wird verwendet.

Ich hab eine ähnliche Erfahrung mit einem C# Programm gemacht, in deren 
Weiterentwicklung ich vor Jahren mal eine Zeit lang involviert war.

Es war eigentlich keine großartige Sache, trotzdem präsentierte sich das 
System so, dass man beim Hochfahren der Applikation im Taskmanager 
zusehen konnte, wie die MB in die Höhe kletterten. Nach einigen Stunden 
gab die Applikation dann mit einem 'Out of Memory' auf.
Wie gesagt, war keine großartige Sache, ein paar dynamische Listen, in 
die immer wieder mal Einträge dazu kamen, aber auch im Zuge der 
Abarbeitung wieder wegkamen. Das waren Störungsmeldungen von 
Gebäudemanagment-Steuerungen, die gesammelt, klassifiziert und je nach 
Situation an diverse Abnehmer verteilt wurden. Mit C++, 
Standardcontainern und den RAII Konzept keine großartige Sache in der 
Speicherverwaltung, aber in C# kam es da wohl zu irgendwelchen 
gegenseitigen Blockaden, so dass der GC den Speicher nicht mehr 
vollständig aufgeräumt hat. Jedenfalls hat das Suchen nach den Ursachen 
einiges an Zeit verschlungen (hab nicht ich gemacht). Mehr Zeit als ein 
ganz einfacher RAII Ansatz in C++ gekostet hätte.

> Das und Generationskonflikte.. ;)
> Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"

Da hast du nicht ganz unrecht.
Für meinen Teil kann ich sagen: Ich vermisse einen GC nicht und komm 
auch ohne ganz gut zurecht.

Karl Heinz schrieb:
> Jedenfalls hat das Suchen nach den Ursachen
> einiges an Zeit verschlungen (hab nicht ich gemacht). Mehr Zeit als ein
> ganz einfacher RAII Ansatz in C++ gekostet hätte.

Wenn ich mit einem Hammer schneller bin als mit einer Nagelpistole, 
liegt das Problem sehr wahrscheinlich nicht an der Nagelpistole, sondern 
daran wie ich sie nutze ;)

Mna kann alles falsch bedienen, d.h. aber nicht, dass das Werkzeug 
fehlerhaft ist.

Mladen G. schrieb:
> Karl Heinz schrieb:
>> Jedenfalls hat das Suchen nach den Ursachen
>> einiges an Zeit verschlungen (hab nicht ich gemacht). Mehr Zeit als ein
>> ganz einfacher RAII Ansatz in C++ gekostet hätte.
>
> Wenn ich mit einem Hammer schneller bin als mit einer Nagelpistole,
> liegt das Problem sehr wahrscheinlich nicht an der Nagelpistole, sondern
> daran wie ich sie nutze ;)
>
> Mna kann alles falsch bedienen, d.h. aber nicht, dass das Werkzeug
> fehlerhaft ist.

Da stimme ich dir durchaus zu.
Wenn allerdings das Werkzeug 'Nagelpistole' als das Beste seit 
geschnittenem Brot beworben wird und sich dann ganz offensichtlich in 
der Praxis rausstellt, das nicht alles Gold ist was glänzt und es einem 
nicht davon entbindet mitzudenken und aufzupassen (was aber keiner 
wahrhaben will), dann komm ich auch mit meinem bewährten Werkzeug 
'Hammer' durchaus klar und benutzte den lieber. Vor allen Dingen dann, 
wenn der Hammer mir dann auch noch einen Nagelauszieher mitliefert, den 
ich mit einer Nagelpistole nicht habe (ich spiele damit auf Destruktoren 
an, die in C++ zuverlässig zum Aufräumen benutzt werden können, 
zumindest in C# jedoch völlig nutzlos sind)

> Das und Generationskonflikte.. ;)
> Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"
Da hast du nicht ganz unrecht.
Für meinen Teil kann ich sagen: Ich vermisse einen GC nicht und komm 
auch ohne ganz gut zurecht.

Karl Heinz schrieb:
> Für meinen Teil kann ich sagen: Ich vermisse einen GC nicht und komm
> auch ohne ganz gut zurecht.

Hat alles seine Vor- und Nachteile. GCs kamen auf, weil die 
Speicherverwaltung von C/C++ den Leuten über den Kopf wuchs. Mit 
Programmen, die auch sehr gerne Lecks hatten oder Speicher doppelt 
freigaben.

Ist das Ei des Kolumbus mittlerweile erfunden?

Karl Heinz schrieb:
>> Das und Generationskonflikte.. ;)
>> Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"
> Da hast du nicht ganz unrecht.
> Für meinen Teil kann ich sagen: Ich vermisse einen GC nicht und komm
> auch ohne ganz gut zurecht.

Ich sage mal so, mit GC suche ich jetzt zumindest nicht mehr die 
Speicherleaks anderer :-), und entgegen Peter II's Aussagen, laufen bei 
uns sogar in Java programmierte Mutithreaded Server in 
Finanzanwendungen, die wochenlang nicht runtergefahren werden.

Und ein Destruktor nützt halt nichts, wenn er nicht aufgerufen wird. 
Genausowenig wie ein GC was freigeben kann, wenn das Programm es noch 
benutzt, bzw Referenzen davon nicht freigegeben werden.

Karl Heinz schrieb:
> Wenn allerdings das Werkzeug 'Nagelpistole' als das Beste seit
> geschnittenem Brot beworben wird und sich dann ganz offensichtlich in
> der Praxis rausstellt, das nicht alles Gold ist was glänzt und es einem
> nicht davon entbindet mitzudenken und aufzupassen, dann komm ich auch
> mit meinem bewährten Werkzeug 'Hammer' durchaus klar.

Da stimme ich völlig zu.

Karl Heinz schrieb:
> Da stimme ich dir durchaus zu.
> Wenn allerdings das Werkzeug 'Nagelpistole' als das Beste seit
> geschnittenem Brot beworben wird und sich dann ganz offensichtlich in
> der Praxis rausstellt, das nicht alles Gold ist was glänzt und es einem
> nicht davon entbindet mitzudenken und aufzupassen (was aber keiner
> wahrhaben will), dann komm ich auch mit meinem bewährten Werkzeug
> 'Hammer' durchaus klar.

Naja, Marketing hat auch immer Einfluss.. Java war die Sprache die vom 
Marketing als Sprache beworben wurde, die keine Zeiger hat, und damit 
viele Probleme vermeidet.
Woher kommen denn dann diese NullPointerExceptions? ;)

Da haben die Entwickler nicht schnell genuig mit dem Marketinggefasel 
mitgehalten und sind nichtmehr dazu gekommen es in 
"NullReferenceException" umzubennen.

Selbst mit GC kann man immer noch Speicherlecks haben.

Karl Heinz schrieb:
>> Das und Generationskonflikte.. ;)
>> Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"
> Da hast du nicht ganz unrecht.
> Für meinen Teil kann ich sagen: Ich vermisse einen GC nicht und komm
> auch ohne ganz gut zurecht.

Ach, das geht ja nicht erst beim GC los.
Habe bei einem fruehren AG in der Kantine oefters Diskussionen ala "Wozu 
eigentlich OO und C++? Ging doch auch alles mit C und prodzedural. 
Diejenigen die wissen was sie machen, brauchen das nicht."

Diese Diskussionen gab es schon vor 30 Jahren, damals ging es allerdings 
um Assembler vs C, "Wozu eigentlich Hochsprachen? Diejenigen die wissen 
was sie machen, koennen das in Assembler viel besser.."

Ich bin Java Entwickler seit ueber 14 Jahren, arbeite seit 12 Jahren mit 
Eclipse, mich bringt keiner dazu zu IntellJ zu wechseln :D

Peter II schrieb:
> wenn bei dem Werkzeug aber nicht offensichtlich ist wie man es bedienen
> soll, das ist das Werkzeug daran schuld.

Ist aber gerade bei Java jetzt nicht wirklich der Fall. Der funktioniert 
automatisch und seit spätestens 1.5 ziemlich gut.

Peter II schrieb:
> leider nicht. Wir haben bei uns einige Tomcat Anwendungen, und diese
> müssen einmal in der Woche neu gestartet werden, sonst müsste man
> Unmengen an Speicher in den Server stecken.

Bei sowas gibt es ja zwei Möglichkeiten:
- Auf den bösen GC schimpfen der ja nix kann
- Mal mit einem passendem Tool (z.B. JProfiler) sich mal ansehen welche 
Objekte da immer mehr Speicher verbrauchen und den Bug fixen

Peter II schrieb:
> Noch schlimmer ist wenn man mit sehr großen Datenmengen arbeitet, dann
> hilft es auch nicht die Referenz zu löschen. Dann muss man den GC
> teilweise von Hand aufrufen

NEEEIN! Bitte nicht, das ist erstens Unnötig und Verschlechtert zweitens 
die Performance und ist drittens nicht garantiert da überhaupt etwas 
passiert...

Peter II schrieb:
> ist nicht von uns die Anwendung, also kein Quelltext vorhanden

Bugreport? Jammern über Fehler die man nie meldet bringt ja wohl noch 
weniger...

Michael schrieb:
> Komisch. Irre ich mich mit Harlequin? Oder haben die das aufgegeben?

ALso bei Harlequin bin ich mir nicht sicher. Aber bei LispWorks ist mir 
nie aufgefallen, dass die auch Embedded Versionen haben.
Vielleicht hat Dave das bei der Übernahme rausgeworfen ?

Der GC der Windows Version war aber schon nice.

Mladen G. schrieb:
> Das und Generationskonflikte.. ;)
> Die alte Laier von "Derjenige der weiss was er macht, braucht das nicht"

Appropos:
Der LispWorks GC ist ein Generational-GC und macht (meist) keine 
Probleme.

Aber falls Du die Generation der Hacker meintest:
GCs wurden schon in Sprachen eingesetzt (z.B. Lisp, Smalltalk) als die 
einzige Anwendung von Java noch "mahlen und mit heissem Wasser 
aufkochen" war.

Von daher ist das für diese (Hacker-)Generation eher kalter Kaffee ;-)

Grüße
Andreas

Peter II schrieb:
> z.b. eine Verkette Liste wo das Ende auf den Anfang zeigt.
> Wann räumt der GC das nun auf?

Im Gegensatz zu Referenzzählern können GCs damit problemlos umgehen. 
Wenn die beispielsweise ausgehend von einem Wurzelobjekt Links nur in 
Objekten berücksichtigen, die sie bereits kennen. Tote Strukturen, die 
nur auf sich selbst verweisen, fallen dabei automatisch raus.

Peter II schrieb:
> die Frage ist wie man es schafft immer die Referenz freizugeben.
>
> z.b. eine Verkette Liste wo das Ende auf den Anfang zeigt.
>
> Wann räumt der GC das nun auf?

Er räumt immerhin auf, ohne musst du alles aufräumen indem du es von 
Hand freigibst. Solange die Werte benutzt werden und in der Liste sind 
kann der GC natürlich nichts freigeben, solange kannst du Objekte auch 
nicht in C++ oder C freigeben

Peter II schrieb:
> Noch schlimmer ist wenn man mit sehr großen Datenmengen arbeitet, dann
> hilft es auch nicht die Referenz zu löschen. Dann muss man den GC
> teilweise von Hand aufrufen, damit man den Speicher gleich wieder
> verwenden kann, weil der GC sonst erst später aufräumen will.

Er räumt spätestens dann auf, wenn er Speicherprobleme bekommt. Und ja 
man kann ihn auch manuell aufrufen wenn man weiß jetzt habe ich eh etwas 
Zeit...

Peter II schrieb:
> Bei C(C++) muss ich ihn zwar von Hand freigeben, weiß aber das er dann
> auch wirklich frei ist.
Du kannst in Java bei komplexeren Strukturen Pointer explizit nullen und 
so dem GC das Leben einfacher machen, aber es funktioniert auch 
erstaunlich gut ohne.

Wir benutzen Java auch um XML Dateien, die mehrere GByte groß sind zu 
parsen, mit Daten aus einer Datenbank einen Vollabgleich zu fahren und 
ggf in die Datenbank zu speichern. Da werden viele GByte an Speicher 
alloziert und wieder weggeworfen, alles ohne Probleme und ohne manuelle 
Nachhilfe, es geht also.

Und das Schönste: Es geht mit einer Lib auf Sun, Aix, allen Linux 
Derivaten, Windows.
Und auf allen diesen Systemen mit DB/2, Oracle und MS-SQL ohne daß ich 
eine Zeile spezifischen Code schreiben musste und ohne daß wir für jede 
Betriebssystem/Datenbank Kombination eine extra Auslieferungsversion 
compilieren/linken, archivieren und nicht zuletzt testen müssen!

Peter II schrieb:
> so einfach ist das glaube ich nicht. Dann würde der GC ein Threadobjekt
> auch wegschmeißen.

Nein, denn irgendwo gibts garantiert eine Liste aller Threads. Und diese 
Liste wiederum irgendwo anders, und ... und irgendwann bist du an der 
Wurzel. So jedenfalls läuft das in jenen Sprachen, wo GC herkommt, wie 
Lisp oder Smalltalk.

Es entbehrt nicht einer gewissen Komik, ausgerechnet das klassischste 
aller Beispiele für GC und gegen Referenzzähler gegen GC in Stellung 
bringen zu wollen.

dumdi dum schrieb:
> Michael schrieb:
>> Es gibt seit
>> Jahrzehnten speziell für den Embedded-Bereich entwickelte GCs, die nicht
>> nur berechenbar sind, sondern sogar Echtzeitgarantien geben.
>
> einen Namen dazu?

MetronomeGC, JamaicaVM/GC etc.

http://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175
https://www.aicas.com/cms/en/publication-details/351
http://reports-archive.adm.cs.cmu.edu/anon/2001/abstracts/01-174.html
http://dl.acm.org/citation.cfm?id=2602996

Perfekt, im Sinne von: erreichen den selben geringen Overhead wie 
manuelle Speicherverwaltung, sind die aber alle nicht.
Ebenso ist eine manuelle Speicherverwaltung nicht perfekt. Stichworte 
u.a.: Heap fragmentation, heap compaction

Peter II schrieb:

> z.b. eine Verkette Liste wo das Ende auf den Anfang zeigt.
>
> Wann räumt der GC das nun auf?

Du meinst bei Objekten die auf sich selbst referenzieren? Na das wird 
aufgeräumt wenn der GC läuft. Such einmal nach "Tracing garbage 
collectors". Nur die billigsten GCs sollten darauf hineinfallen.

> Noch schlimmer ist wenn man mit sehr großen Datenmengen arbeitet, dann
> hilft es auch nicht die Referenz zu löschen. Dann muss man den GC
> teilweise von Hand aufrufen, damit man den Speicher gleich wieder
> verwenden kann, weil der GC sonst erst später aufräumen will.

Das ist wohl ein spezieller Spezialfall und wenn das wirklich der Fall 
ist, dann ist auch manueller GC-Aufruf kein Beinbruch. Im Normalfall ist 
das Environment aber so intelligent selbst zu merken, dass es jetzt 
aufräumen muss. Ich habe zumindest noch nie einen manuellen Aufruf 
benötigt.

> Bei C(C++) muss ich ihn zwar von Hand freigeben, weiß aber das er dann
> auch wirklich frei ist.

Was dir nicht viel bringt außer eventuell ein gutes Gewissen.

Peter II schrieb:
> z.b. eine Verkette Liste wo das Ende auf den Anfang zeigt.
>
> Wann räumt der GC das nun auf?

Wenn er Zeit dazu hat ;) Normalerweise ist das kein Problem so was 
aufzuräumen/freizugeben. Der GC sucht bspw. von sogenannten GC roots 
(lokalen Variablen, statischen Variablen etc.) ausgehend auf was diese 
verweisen. Alles was nicht erreicht werden kann, kann freigegeben 
werden.

> Bei C(C++) muss ich ihn zwar von Hand freigeben, weiß aber das er dann
> auch wirklich frei ist.

Frei schon, aber nicht zwingend nutzbar (Fragmentierung...)

Peter II schrieb:
> Warum wird ein Filehandle nicht vom GC aufgeräumt wenn keine Referenz
> mehr da ist? Die Datei bleibt ewig geöffnet.

Die überschreitest damit die Grenze von Anwenderprogramm und 
Betriebssystem. GC gilt nicht systemweit, sondern ist auf die 
Anwendungsebene des Prozesses begrenzt. Filehandles als API-Elements 
eines Betriebssystems sind somit nicht automatisch Teil eines GC 
Mechanimusses des Anwenderprogramms.

Wenn man in der betreffenden Sprache einen Wrapper um das Handle baut, 
um ein Sprachobjekt daraus zu zimmern, dann kann man diesem Wrapper eine 
Aufräum-Methode verpassen, die spätestens mit Freigabe des Wrappers im 
GC das Handle schliesst. So das gewollt ist.

Peter II schrieb:

> die Frage ist wie man es schafft immer die Referenz freizugeben.
>
> z.b. eine Verkette Liste wo das Ende auf den Anfang zeigt.

Da gibt es die verschiedensten Ansätzte (mark & sweep und wie die alle 
heissen). Das ist für einen modernen GC nun kein Problem.

Voraussetzung dafür ist aber, dass es ausserhalb der Kette keine 
Referenz mehr auf irgend ein Element der Kette gibt. Das liegt dann aber 
in der Verantwortung des Entwicklers.

Die Ursache in Memory Leaks kommen häufig daher, dass mit Frameworks 
gearbeitet wird, die von den Entwicklern zuwenig genau verstanden werden 
(z.B. liefert ein getElement() nun eine Refernz oder eine Kopie? 
Speichert ein putElement() eine Referenz oder eine Kopie?).

> Wann räumt der GC das nun auf?

Das ist ein sehr heikler Punkt. Auch hier gibt es verschiedenste 
Strategien (wenn der Speicher zu 90% aufgebraucht ist, nach x ms, nach x 
Maus-Events, etc.). Ein anderer interessanten Punkt ist, ob immer 
vollständig aufgeräumt wird (kann lange dauern) oder nur eine maximale 
Zeit lang (ist sehr viel komplexer).

==> GC an sich funktioniert heute sehr gut und kann auch sehr gut auf 
die Rahmenbedingungen ausgerichtet werden. Es schützt aber nicht davor, 
dass ein schlechter Entwickler schlechte Software schreibt.

Gruss
Claude

PS: Ich kenne komplexe Server-Applikationen, mit denen rund um die Uhr 
sehr viele Leute arbeiten, die monatelang nicht herunter gefahren 
werden.

Nachdem ich es auf meinem ersten Computer geschafft habe, ein
Basic-Programm immer wieder für jeweils ca. 2s in der GC verharren
zu lassen, war für mich GC auch böse :)

Mittlerweile, auf moderneren Computern mit moderneren
Programmiersprachen und Laufzeitsystemen, machen sich die von der GC
verursachten Unregelmäßigkeiten im Programmablauf kaum noch bemerkbar.
Deswegen mag ich für die High-Level-Programmierung ganz gerne auch
wieder Sprachen mit GC.

Man muss sich aber eben bewusst sein, dass GC zwar ungültige Pointer und
mehrfache Freigaben perfekt verhindert, nicht aber Speicherlecks. Die
Verhinderung von Speicherlecks wird zwar von der GC bis zu einem
gewissen Grad unterstützt, bleibt aber ohne Mitdenken des Programmierers
erfolglos. In dem von A. K. verlinkten Artikel

  http://acadopus.de/java/die-typischen-faelle-von-memory-leaks-in-java-anwendungen_4002.html

gibt es schöne Beispiele dafür.

Das nach wie vor bestehende Problem der GC: Um Speicherlecks zu
vermeiden, muss der Programmierer ziemlich genau wissen, wie
Bibliotheksfunktionen den Speicher nutzen und wo möglicherweise
versteckte Referenzen auf Objekte gehalten werden. Bei den immer größer
werdenden Laufzeit- und anderen Bibliotheksfunktionen ist es aber nahezu
unmöglich, diesbezüglich den erforderlichen Überblick zu behalten.

Bei den klassichen auf malloc() und free() basierenden Systemen ist das
vergleichsweise einfach: Normalerweise gibt diejenige Programmeinheit,
die Speicher anfordert, diesen auch wieder zurück. Ist dies nicht
möglich (bspw. wenn eine Funktion ein dynamisch angelegtes Objekt an den
Aufrufer zurückgibt), dann ist dies in der Dokumentation vermerkt
zusammen mit Hinweisen, wann und wie der Speicher wieder freigegeben
werden soll. Das funktioniert aber natürlich auch nur dann, wenn die
Dokumentation entsprechend vollständig ist und vom Programmierer auch
gelesen wird. In beide Bereichen gibt es noch Defizite.

Peter II schrieb:

> ist nicht von uns die Anwendung, also kein Quelltext vorhanden. Damit
> bringt es auch wenig wenn ich den Fehler finden würde.

Das ist aber jetzt schon ganz hart am Getrolle. Da hat jemand ein 
Memory-Leak fabriziert und daher ist der GC schuld und unnötig. Als ob 
der Programmierer in C++ nicht noch ein viel größeres Memory-Leak 
produziert hätte.
Das Einzige was man dem GC hier vorwerfen kann ist, dass der 
Programmierer die Anwendung in C++ ev. gar nicht stabil bekommen hätte 
und daher ein fähigerer Programmierer oder mehr Zeit notwendig gewesen 
wären.

Yalu X. schrieb:
> Bei den klassichen auf malloc() und free() basierenden Systemen ist das
> vergleichsweise einfach: Normalerweise gibt diejenige Programmeinheit,
> die Speicher anfordert, diesen auch wieder zurück.

Das führt freilich zum umgekehrten Extrem. Wenn Code von Modul A einen 
Link auf ein Objekt von Modul B speichert, ohne dass der Programmierer 
das weiss, dann gibts bei GC ein scheinbares Speicherleck - wie im Link 
beschrieben - und bei malloc/free einen Sprung ins Nichts. Such es dir 
aus. ;-)

Peter II schrieb:
> es werden also ständig versucht alle Objekte zu Prüfen ob sie
> weggeschmissen werden können - kein Wunder warum Java Programm so
> langsam sind

Ja, das ist ein Nebeneffekt. GC benötigt auch temporären Speicher. Die 
Alternativen haben freilich auch Nebeneffekte. So entsteht 
beispielsweise durch Referenzzähler ebenfalls Zusatzaufwand, in Platz 
und Zeit, aber anders verteilt.

Peter II schrieb:
> (Kommentar nicht 100% erst gemeint, gibt es werte wie viel CPU zeit der
> GC alleine braucht? )

Lässt sich nicht verallgemeinern, weil es die eine GC-Methode nicht 
gibt, ebenso wenig wie das eine für alle anderen typische Programm. 
Für Beispiele siehe wie oben schon genannt:
http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/2

Jan Hansen schrieb:
> Als ob der Programmierer in C++ nicht noch ein viel größeres Memory-Leak
> produziert hätte.

Dem wäre statt dessen wahrscheinlich das Programm weggeflogen. Mit einem 
schönen sauberen Crash. Statt Tag für Tag langsamer zu werden, bis der 
Server aus Speichermangel die Grätsche macht.

Karl Käfer schrieb:
> Nein, das bezieht sich auf so ziemlich alle zeitkritischen Anwendungen.
> Wir stellen eine Echtzeit-Betrugserkennung bei Kreditkartenzahlungen
> her; dabei ist die Garbage Collection ein Dauerthema.

Wir machen hier etwas sehr aehnliches, der GC ist aber nicht unser 
Problem, sondern die Queries die von Hibernate generiert werden und 
damit die Oracle DB so langsam machen dass die sich nicht mehr vor dem 
Timeout meldet.

Parallelen GC anwerfen sollte zumindest nicht die ganze VM einfrieren 
bei einem GC run.

Hobbyist schrieb:
> Zudem läuft der GC ja üblicherweise nebenläufig, so dass die anderen
> Threads davon nichts mitbekommen (es sei denn man hat nur einen Kern

Es ist nicht ganz so einfach, eine GC so zu bauen, dass sie ohne 
grössere Aufwirkungen auf andere Threads bleibt. Der Link zur Davik/ART 
Migration erwähnt auch diese Problematik. So wird darin die 
GC-Implementierung von Dalvik als einer der Gründe für Ruckler in 
Android gesehen.

Peter II schrieb:
> es werden also ständig versucht alle Objekte zu Prüfen ob sie
> weggeschmissen werden können - kein Wunder warum Java Programm so
> langsam sind
> (Kommentar nicht 100% erst gemeint, gibt es werte wie viel CPU zeit der
> GC alleine braucht? )

Wie schon geschrieben wurde, kommt es auf die konkrete Implementierung 
des GCs an z.B. Mark&Sweep
http://en.wikipedia.org/wiki/Mark_and_sweep

In den Links oben zu Echtzeit-GCs sollte sich auch einiges finden 
lassen.
Interessante Ansätze für Echtzeit-GCs auf FPGAs z.B.:
Parallel Real-time Garbage Collection of Multiple Heaps in 
Reconfigurable Hardware, Bacon, Cheng, Shukla, 2014
http://dl.acm.org/citation.cfm?id=2602996

A. K. schrieb:
> Das führt freilich zum umgekehrten Extrem. Wenn Code von Modul A einen
> Link auf ein Objekt von Modul B speichert, ohne dass der Programmierer
> das weiss, dann gibts bei GC ein scheinbares Speicherleck - wie im Link
> beschrieben - und bei malloc/free einen Sprung ins Nichts. Such es dir
> aus. ;-)

Ja, hast recht, das kann natürlich auch passieren.

Vielleicht sollten wir einfach wieder zu den klassichen statischen
Sprachen wie Fortran≤77 zurückkehren. Fortran war damals so statisch,
dass man nicht einmal einen Stack brauchte. Und bei den heutzutage
typischen 16GiB Hauptspeicher kann man alle Arrays so groß
dimensionieren, dass ihre Grenzen erst erreicht werden, wenn ein
GC-basiertes Programm schon lange auf Grund von Speicherlecks mit einer
"memory full"-Exception ausgestiegen wäre ;-)

Arc Net schrieb:
> benso ist eine manuelle Speicherverwaltung nicht perfekt. Stichworte
> u.a.: Heap fragmentation,

Haben GCs nicht auch dieses Problem?

Yalu X. schrieb:
> Und bei den heutzutage
> typischen 16GiB Hauptspeicher

Mann was hätten wir vor 25 Jahren mit so viel Ram angefangen? Wir hätten 
gar nicht gewusst was wir damit tun sollen :-)

dumdi dum schrieb:
> Arc Net schrieb:
>> benso ist eine manuelle Speicherverwaltung nicht perfekt. Stichworte
>> u.a.: Heap fragmentation,
>
> Haben GCs nicht auch dieses Problem?

Wenn sie keine Heap Compaction machen, ja. Bspw. gibt es im aktuellen 
.NET-GC einen Schalter mit dem im LOH (Large Object Heap) eine 
Defragmentierung bei Bedarf erzwungen werden kann, Standardeinstellung 
ist, dass dort keine durchgeführt wird. Im SOH (Small Object Heap) wird 
es dagegen automatisch gemacht.

Peter II schrieb:
> es werden also ständig versucht alle Objekte zu Prüfen ob sie
> weggeschmissen werden können - kein Wunder warum Java Programm so
> langsam sind

Erstens nicht ständig, sondern nur dann wenn der GC läuft.
Und auch da werden bei intelligenten Implementierungen nicht immer alle 
Objekte geprüft. Da gibt es z.B. generationenbasierte Implementierungen. 
Viele Objekte leben nämlich nur ganz kurz (z.B. in einer Schleife) - die 
werden immer berücksichtigt. Lebt ein Objekt länger so wandert es 
irgendwann in die nächste Generation und wird nur noch selten geprüft. 
Es gibt nämlich nur wenige Objekte die eine mittlere Lebensdauer haben. 
Wenn ein Objekt eine gewisse Lebensdauer erreicht hat, dann ist die 
Wahrscheinlichkeit recht groß, dass es noch länger lebt.