Diskussion:Garbage Collection/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Garbage Collection/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Garbage_Collection/Archiv/2#Thema_1

Deterministisch ggü. nicht-deterministisch

Wenn ich mich mal dazugesellen darf:

Salomonisch gesprochen haben beide Seiten recht. ;-)

Spätestens seit Entdeckung und Formulierung der Unschärferelation durch Heisenberg ist der Laplacesche Dämon tot. D.h. den 100%igen Determinismus gab es, was praktische Belange betrifft, davor schon nicht (Knackpunkt: „unter der Kenntnis sämtlicher Naturgesetze und aller Initialbedingungen“) und kann es seither nicht mal mehr theoretisch geben. (Auch wenn Einstein sich im Grabe winden möge: „Gott würfelt sehr wohl!“ ;-)

(Ganz abgesehen davon, wird uns, nach heutigem Stand der Erkenntnis, die Kenntnis „aller Initialbedingungen“ noch etwas länger [möglicherweise für immer] verwehrt bleiben, da es da die Planck-Zeit gibt. Das ist zwar schon sehr nah an den inititalsten Inititalbedingungen [des Urknalls] dran, aber eben nicht genau dort.)

Das führt dann im Weiteren zu Dingen, wie, dass die Wahrscheinlichkeit, dass alle Atome eines (quantenmechanischen) Tischtennisballes an allen Atomen einer (quantenmechanischen) Tischtennistischplatte „vorbeiflutschen“, der Ball also solcherart durch die Platte fällt, zwar nicht sehr hoch, aber doch größer Null ist.

Das widerspricht „natürlich“ milliardenfach erlebter Alltagserfahrung in makroskopischen Größenordnungen und man schafft sich Abhilfe dadurch, dass man gedankliche und praktische Ebenen (a.k.a. Black Boxes) bildet und annimmt, dass die Ebene auf der man aufbaut zu 100% das tut, was sie grundsätzlich nur zu 99,9999999…% tun kann.

In dem Sinne und in dem Rahmen kann ein GC für sich, auf seiner Ebene, in seiner Black Box, durchaus deterministisch agieren. Ein Anwendungsprogrammierer eine Ebene darüber, außerhalb der BB des GCs, kann sich lediglich danach richten, wie der GC angibt sich zu verhalten. Und wenn der angibt, dass, wie bspw. beim GC der Oracle-SE-JVM, eine Ausführung nicht garantiert ist, d.h. dass die Ausführung im nächsten Taktzyklus bis im Unendlichen – also praktisch auch nie – geschehen kann, dann ist das, zieht man die Definition aus Determinismus (Algorithmus) heran, aus (praktischer) Sicht des Programmierers bzw. der Anwendung nicht-deterministisch.

Aus theoretischer Sicht, d.h. wenn die Anwendung unendlich lange laufen würde und solcherart auch unendlich lange auf ein Agieren des GCs im Unendlichen warten könnte, dann ist es (aber nur quasi, da der Dämon ja längst tot ist) deterministisch. Die Frage ist, was wir hier beschreiben wollen und belegen können: Realitäts- und Praxisnahes oder abgehoben Wissenschaftstheoretisches? --Geri, ✉ ^Mentor 18:49, 6. Feb. 2013 (CET)

[PS: Persönliche Anmerkung nur am Rande des Themas: Es würde mich wirklich interessieren, wie viele, gemeinhin „Abstürze“ aufs Konto der quantenmechanischen Unbestimmtheit gehen. D.h. dass, ohne dass irgendeine HW oder SW auch nur irgendwie fehlerhaft gearbeitet hätte, hier oder dort mal ein Bit kippt und dementsprechendes Durcheinander angerichtet wird. --Geri, ✉ ^Mentor 18:49, 6. Feb. 2013 (CET)]

Ich versuche mal gezielt, weitere Anspielung auf diese recht lange Diskussion zu vermeiden. Grundsätzlich ging es hierbei um Determinismus i. S. v. einer vorherbestimmten Abfolge von internen Zuständen aus Sicht des Anwendungsprogrammierers. Grenzwertbetrachtungen können hier nicht angestellt werden.

Zu deiner Frage, inwiefern sich Quanteneffekte auswirken: Das plötzliche Kippen eines oder auch mehrer Bits im Speicher (o. ä.) ist ein durchaus irdisches und alltägliches Problem. Wenn auch nicht durch die Unschärferelation, deren Wahrscheinlichkeit für ein solches Ereignis ich eher bei Null ansiedeln würde. Es entsteht durch radioaktiven Zerfall, wenn ein Alphateilchen auf Komponenten trifft, kann eine Speicherzelle durch dieses externe Ereignis ihren Wert ändern. Darum führen Telekommunikationsbetreiber auch Abrechnungen meist redundant im "Lock Step"-Verfahren durch. Und deshalb ist auch der "Ruhezustand" (oder Suspend-to-disk) umstritten. In noch höherem Maße ist dies ein Problem bei Satelliten, wo die harte Röntgen- bzw. kosmische Strahlung Speicherinhalte verändern und Bauteile zersetzen kann.

Die fehlertolerante Hard- und Softwarearchitektur beschäftigt sich mit dieser Problematik. -- Plankton314 (Diskussion) 23:21, 6. Feb. 2013 (CET)

Einspruch, Euer Ehren! Unter den in Dotierung#Hintergrund genannten Elementen finde ich keinen einzigen Alphastrahler. Außer natürlich, selbst hochreines bspw. Silizium ist noch mit einem solchen verunreinigt. Externe Strahlung wird es ja bei der geringen Reichweite/Eindringtiefe nicht sein können.

Wo Du oben eine Grenzwertbetrachtung siehst, erschließt sich mir nicht. Ich hatte jedenfalls keine im Sinn. --Geri, ✉ ^Mentor 00:25, 7. Feb. 2013 (CET)

Das hat nichts mit der Dotierung zu tun, sondern mit der alltäglichen "Hintergrund"-Radioaktivität.

Du schreibst oben, dass man theoretisch unendlich lang warten könnte; das verstand ich als Grenzwertbetrachtung. -- Plankton314 (Diskussion) 10:15, 7. Feb. 2013 (CET)

Was soll „"Hintergrund"-Radioaktivität“ sein (wenn auch in Anführungszeichen)? Es gibt Hintergrundstrahlung und es gibt Radioaktivität. Die haben aber nicht viel miteinander zu tun. Aber lassen wir das hier, gehört ohnehin nicht hierher.

Darf ich das so verstehen, dass wir hier also nicht „abgehoben Wissenschaftstheoretisches“ beschreiben wollen, sondern das andere Erwähnte? Ist mir recht. --Geri, ✉ ^Mentor 12:30, 7. Feb. 2013 (CET)

Ich habe "Hintergrund" in Anführungszeichen gesetzt, weil es nicht den physikalischen Begriff der "Hintergrundstrahlung" beschreiben sollte, sondern die natürliche Radioaktivität auf der Erde und kosmische Strahlung weiter oben.

Und ja, so war es angedacht. Dies ist ein Artikel aus der Kategorie Informatik, eigentlich sollten hier keine metaphysischen/quantentheoretischen/o. ä. Einlassungen dargestellt werden. Außer natürlich es vertieft den Artikel, aber das ist hier, glaube ich, nicht gegeben.-- Plankton314 (Diskussion) 13:09, 7. Feb. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 16:01, 11. Feb. 2013 (CET)

Verbreitung

Mal so eine Frage am Rande: der Abschnitt Verbreitung ist doch eigentlich nicht richtig, oder? Dort ist mehrfach die Rede davon, daß Programmiersprachen über eine automatische Speicherbereinigung verfügen. Aber es sind doch nicht die Sprachen, sondern die jeweiligen Laufzeitumgebungen, oder? Einer Sprache kann es vollkommen egal sein, ob etwas hinterher den Speicher aufräumt oder nicht? (nicht signierter Beitrag von 84.179.49.54 (Diskussion) 19:02, 2. Sep. 2014 (CEST))

Jein. Programmiersprachen, die auf GC zählen, haben keine Möglichkeit um anderswie Speicher aufzuräumen. D.h. es fehlt ihnen das "delete" bzw. "free". GC ist somit aus meiner Sicht impliziter Bestandteil der Sprachen. --Sebastian.Dietrich ✉ 10:13, 3. Sep. 2014 (CEST)

Formulierung in der Einleitung

Wo wir gerade dabei sind: Was mir schon beinahe seit Jahren nicht so recht passt ist der Nebensatz in der Einleitung

[eine automatische Speicherverwaltung], die den Speicherbedarf eines Computerprogramms minimiert.

Ich finde die Aussage nicht sehr glücklich. Ja, eine automatische Speicherverwaltung gibt (und auch nur von Zeit zu Zeit) nicht mehr benötigten Speicher frei. Unter Minimierung verstehe ich eher als eine Art der Optimierung, hier geht es aber nur um die Verwaltung.
Und gleich im folgenden Satz "Dabei wird zur Laufzeit versucht ..."' steht auch schon eine präzise Erklärung des Vorgangs.
Hängt irgendjemand an dieser Formulierung oder fällt ihm eine bessere ein?--Plankton314 (Diskussion) 10:11, 18. Mär. 2015 (CET)

+1 für die Löschung von ", die den Speicherbedarf eines Computerprogramms minimiert. " --Sebastian.Dietrich ✉ 12:44, 18. Mär. 2015 (CET)

Richtig, der Satz hakelt. Weglassen oder ausführlicher (z.B. en eine automatische und vom Programm unabhängige Speicherverwaltung], die zur Laufzeit des Computerprogramms die Speicherverwendung selbstständig mitprotokolliert und optimiert.) --Shaddim (Diskussion) 13:00, 18. Mär. 2015 (CET)

Dass GC "die Speicherverwaltung optimiert" kann sein, muss aber nicht.

Auch kommt es darauf an, was genau man unter "optimieren" versteht. Gemäß welcher Kriterien?

Und auch die Aussage "vom Programm unabhängig" ~ tut ziemlich weh. Als ob die GC das Programm gar nicht beachten würde...

--arilou (Diskussion) 13:10, 19. Mär. 2015 (CET)

Tut's auch nicht, das ist ja eine gute Eigenschaft: "separation of concerns" der Code für das Speichermanagment ist separiert von meinem applikationscode (statt wie beim expliziten management "untergemischt") & läuft auch in nem anderen Kontext/prozess. Shaddim (Diskussion) 16:45, 19. Mär. 2015 (CET)

Fachlich ist GC sicher vom Programm abhängig. Technisch vielleicht sogar auch (siehe z.B. Excape Analyse bei Java [1]) --Sebastian.Dietrich ✉ 17:58, 19. Mär. 2015 (CET)

Die GC ist nicht das Programm das verwaltet wird: unterschiedlicher code, unterschiedlicher prozess. Gewünschte Eigenschaft, die das attribut "unabhängig" durchaus verdient. (Unabhängig bedeutet naterulich nicht "im-leerraum", die GC nimmt auf das Programm und dessen Status Bezug. Ähnlich wie ein Journlist unabhängig sein kann und trotzdem Bezug auf sein Thema nimmt) Shaddim (Diskussion) 19:02, 19. Mär. 2015 (CET)

Kein Journalist ist unabhängig. Er hängt von seinen Auftraggebern, Lesern etc. ab. Unabhängig ist bei Journalisten/Experten/Beratern immer nur ein Mascherl, dass mit der Realität nichts zu tun hat. Wenn der GC "auf das Programm und dessen Status Bezug nimmt", dann ist sie davon abhängig. Zumindest fachlich, wenn nicht sogar technisch indem die GC das Programm inspiziert und sich auf dessen (noch kommendes) Verhalten einstellt. --Sebastian.Dietrich ✉ 19:55, 19. Mär. 2015 (CET)

vielleicht ist das so in Österreich ;) Unabhängig davon, GCs agieren selbständig & unabhängig und lassen sich nicht in ihrer objektiven Speicherverwaltungmoral durch Zuckerli und andere Zuwendungen des Programms beeindrucken. Shaddim (Diskussion) 20:04, 19. Mär. 2015 (CET)

D.h. in Deutschland arbeiten Journalisten auch genauso weiter, wenn sie gekündigt werden? Unabhängig ist ja was anderes als "nicht-weisungsgebunden". Technisch mag eine GC unabhängig sein, aber fachlich ist sie es nicht. Gibt es viel aufzuräumen und wird der Speicher knapp verhält sie sich anders als, wenn es nix aufzuräumen ist und noch genug Speicher da ist. Solange sie nur ein einziges if enthält, welches indirekt vom Programm abhängt ist sie fachlich abhängig.--Sebastian.Dietrich ✉ 20:53, 23. Mär. 2015 (CET)

Genau genommen ist so manches in der Einleitung als muss formuliert, das aber tatsächlich (für GC) ein kann ist.

Z.B. macht eine GC oft so ziemlich gar nichts, solange sie nicht muss.

Vor- und Nachteile gehören imo nicht in die Einleitung.

Und den 'Nachteil' "nicht-deterministisches Verhalten der Ausführungsumgebung und damit unter Umständen auch des Programms selbst." würde ich als sehr strittig ansehen, da in solchen Fällen normalerweise ein Programmierfehler vorliegt - und Dummheit des Programmierers als Nachteil der GC anzusehen, tztztz...

--arilou (Diskussion) 13:20, 19. Mär. 2015 (CET)

@macht oft so ziemlich gar nichts: Er "macht" die aktive Entscheidung nix zu machen. Shaddim (Diskussion) 16:45, 19. Mär. 2015 (CET)

@Vor- und Nachteile in Einleitung: das ist eine exotische Meinung ;) Shaddim (Diskussion) 16:45, 19. Mär. 2015 (CET)

@nicht-deterministisches Verhalten: Nein, das ist kein Programmierfehelr sondern eine direkte Folge des Konzepts GC und der Entkopplung. Shaddim (Diskussion) 16:44, 19. Mär. 2015 (CET)

Bitte nicht...Vorlage:Smiley/Wartung/:'( --Plankton314 (Diskussion) 17:19, 19. Mär. 2015 (CET)

"macht gar nichts" - in der Einleitung (und im Artikel) wird unterstellt, dass eine GC auf jeden Fall

• "den Speicherbedarf eines Computerprogramms minimiert." - Das ist (fast immer) falsch. Eine GC wird nur aktiv, wenn's knapp wird mit dem Ram. Bis dahin wird im Allgemeinen gar nichts "minimiert", sondern das Programm darf im Ram "wüten" und verbrauchen soviel wie es will.
  Lediglich bei Echtzeitsystemen ist die GC eher vorsichtig, und kümmert sich auch schon ein bischen "vorab" darum, spätere "Probleme" zu vermeiden. Bei Nicht-Echtzeit-Programmen lässt die GC es meist drauf ankommen, dass das Programm endet, bevor sie überhaupt auch nur 1* tätig werden musste - oder zumindest nur aktiv zu werden, wenn's nicht mehr anders geht.
• "Dabei wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben." - dito, das wird nur gemacht, wenn's sein muss, und nicht "generell/andauernd".

'GC sei unabhängig vom Programm' ~ hm, es scheint, wir verstehen "unabhängig" nicht 100%-ig gleich. Ja, die GC läuft i.A. automatisch, in eigenem Prozess usw., ihre Implementierung ist für alle Programme dieser Programmiersprache identisch und (in dieser Hinsicht) "unabhängig"; aber ihr Verhalten (z.B. wann sie aktiv wird und was macht) ist durchaus abhängig vom Programm, ob dieses viele kleine Speicherbereiche anfragt, oder wenige, oder große, oder bereits vorhandene Bereiche verlängern/vergrößern will, ... in dieser Hinsicht ist die GC durchaus abhängig vom konkreten Programm.
Daher müsste eine Aussage "die GC ist unabhängig vom Programm" präzisiert werden, bzgl. welcher Aspekte das gemeint ist.

"Programmierfehler": In Sprachen, bei denen solch ein nicht-deterministisches Verhalten droht, wird i.A. darauf hingewiesen, dies zu berücksichtigen und Programmaktionen, die bei der Freigabe eines Speicherbereichs erfolgen sollen, explizit und vorab durchzuführen. Wenn ein Programmierer das ignoriert, ist das kein Nachteil/Fehler der GC, sondern Murks/Unwissenheit des Programmierers - vergleichbar damit, bei manueller Speicherverwaltung einfach keinen free() aufzurufen (aus Unwissenheit).

"GCs agieren selbständig & unabhängig und lassen sich nicht in ihrer objektiven Speicherverwaltungmoral durch Zuckerli und andere Zuwendungen des Programms beeindrucken." - doch, i.A. schon. Zum einen kann das Programm die GC explizit auffordern, "jetzt" aktiv zu werden. Auch könnte ein Programm durchaus während der Laufzeit einen anderen GC-Algorithmus anfordern, z.B. auf "Echtzeit-GC" umschalten für entsprechende zeitkritische Programmabschnitte, oder Abschnitte definieren "hier bitte keine GC-Unterbrechung".

@Vor- und Nachteile in Einleitung: "das ist eine exotische Meinung ;)"
Bisher vertrittst nur du die gegenteilige Meinung...

Ein Leser schlägt einen Begriff in einer Enzyklopädie nach, primär um zu erfahren "was ist dieses 'Garbage Collection'?", und das sollte die Einleitung kurz beschreiben. Und Vor- oder Nachteile sind nur relevant für

• Programmiersprachen-Entwerfer (die mit Sicherheit nicht in der WP nachsehen, was eine GC ist, sondern stapelweise Bücher über Detailfragen der GC auf dem Schreibtisch liegen haben)
• Jemand, der eine bestimmte Sprache (z.B. für ein Projekt) auswählen soll.

Aber die große Mehrheit der Leser, z.B. Programmier-Anfänger, haben keine Wahl, ob sie GC verwenden sollen oder nicht - und damit ist eine Vor-/Nachteil-Betrachtung ziemlich nachrangig, und beileibe nicht "wichtig" oder "sehr relevant" -> Raus aus der Einleitung damit!

--arilou (Diskussion) 09:34, 20. Mär. 2015 (CET)

Also zumindest die Determinismus-Sache haben wir das letzte mal in einer epischen Breite diskutiert, die seinesgleichen sucht. Bevor wir diesen Punkt nun wieder aufwärmen, würde ich dich bitten, auf den Stand der letzten Diskussion bezugzunehmen und Fachliteratur zu deiner Argumentation anzuführen.--Plankton314 (Diskussion) 11:10, 20. Mär. 2015 (CET)

Macht-was-macht-nix: Die GC passt permanent/aktiv auf den Speicherbedarf auf und räumt (schnell, mit kurzer Latenz) auf wenn es notwendig wird. Nach deiner Argumentation macht ein Wächter der nur 1-2 mal im Jahr "aktiv" wird auch nix & sollte unbezahlt bleiben?

Vorteile-nachteile: natuerlich sind die für jeden Programmeir und Softaredesigner hoch interessant (und nicht nur Programmeirsprachendesigner). GC sind ein mächtiges Werkzeug aber mit ausgeprägten Vor- wie Nachteilen (wie sechsmal grösserem Speicherverbrauch, ne Grössenordnung welche für ne menge Programmierdomänen relevant oder dem nicht-determinismus). Shaddim (Diskussion) 22:05, 20. Mär. 2015 (CET)

Macht-was-macht-nix: "[...] und räumt [...] auf wenn es notwendig wird." - Und sehr oft ist es nicht notwendig bis zum Programmende. Und genau dieses "nicht notwenig" fehlt in der Einleitung ~ als ob die GC bei jedem 'malloc'/'free' eine komplette "Minimier-Aktion" durchführen würde.

(Es gibt GC-Algorithmen, insbesondere für Echtzeit, die tatsächlich sehr feingranular bei jedem malloc/free ein wenig "nachbessern" (mit maximal Zeitbedarf x), und dadurch einen "großen Einsatz" vermeiden.)

Sollte also das Programm enden, bevor die GC auch nur 1* "reorganisieren" musste, dann hat sie den Speicherverbrauch des Programms ja sowas von minimiert während des Programmablaufs...

Vorteile-Nachteile: "natuerlich sind die für jeden Programmeir und Softaredesigner hoch interessant"
Quatsch. Wenn dein Chef sagt: "Unsere bisherigen Programme sind in Java, und du verwendest daher auch Java!", dann können dir alle Vor- und Nachteile von Java (und seiner GC) egal sein, du kannst sowieso keine andere Sprache wählen. Und wenn er C# anordnet - dito. Kaum ein Programmierer (und auch kaum ein Softwaredesigner) kann die zu verwendende Sprache frei wählen; außerdem besteht die meiste Programmierarbeit aus Erweitern und Überarbeiten von bestehendem. Dessen Sprache ist dann schon vorab fix.

--arilou (Diskussion) 16:29, 23. Mär. 2015 (CET)

@Nachbessern: In üblichen Programmen ist GC immer notwendig - niemand hat soviel Speicher. Zumindest im Java Bereich lauft der GC aber auch, wenn es theoretisch nicht notwendig wäre. Zumindest die gerade neu angelegten Objekte werden rasch wieder freigegeben - d.h. ein Java Programm muss schon < 1Sek. laufen um keine GC zu verursachen. Der Speicher der dem Programm zugewiesen wird liegt zwischen min- und max-Werten - dass der tatsächlich dem Programm zugewiesene Wert mit der Zeit auch schwankt erkennt man nach wenigen Minuten Laufzeit.

@Vorteile-Nachteile: In der Praxis sind die Nachteile üblicherweise kein Problem. Zeitlicher Indeterminismus ist überall üblich (da überall Threads laufen & wir preemtives Multitasking haben), Indeterminismus im Ablauf kommt in der Praxis auch bei GC nicht vor (Ressourcen im finalizer freizugeben ist ein lange bekannter Codesmell), und RAM ist auch meist mehr als genug vorhanden. Das noch gar nicht angesprochene Problem ist meist eine besondere Form des zeitlichen Indeterminismus: Stop-The-World Collections von alten Objekten. Alte GCs führten oft zu seltenen, aber doch vorkommenden Pausen von mehreren Sekunden - was auch bei Nicht-Echtzeit Anwendungen oft inakzeptabel ist. Dieses Problem kann auch bei modernen GCs, selten aber doch & insbesondere wenn sie schlecht eingestellt sind, vorkommen. Nur wenige GCs (z.B. Azul C4) kommen ohne Stop-The-World Collections aus. --Sebastian.Dietrich ✉ 23:10, 23. Mär. 2015 (CET)

"niemand hat soviel Speicher"

"und RAM ist auch meist mehr als genug vorhanden."

Wat denn nu? --arilou (Diskussion) 14:19, 25. Mär. 2015 (CET)

"Niemand hat soviel Speicher" bezieht sich darauf, dass ein Speicheraufräumen bis zum Programmende nicht notwendig wäre. Also die GC bis zum Programmende nix wegschmeissen muss. Bis auf Mini-Programme, die nur wenige Sekunden laufen ist das nicht üblich. Normalerweise werden ständig Objekte erzeugt und wenn die GC gar nicht läuft bist bald im zig GB bzw TB Bereich. "Soviel Speicher hat niemand".

"RAM ist meist mehr als genug vorhanden" bezieht sich auf die Nachteile der GC - konkret auf den Nachteil dass um eine performante GC zu haben dem Programm mehr Speicher zugebilligt werden muss, als es maximal benötigt. +20% oder +500% (je nachdem wen man fragt s.o.) ist aber nichts, was heutzutage ein Problem ist. Eclipse z.B. ist eine Applikation, die sicherlich zu den größten Applikationen im Java Bereich gehört, und es kommt in den meisten Fällen mit 256MB aus (d.h. wirft keine OutOfMemory Exception) - wenn ich jetzt den Speicher auf 1GB hochschraube bin ich noch lange nicht an den Grenzen des heutzutage "mehr als genug vorhandenen" RAMs. --Sebastian.Dietrich ✉ 16:02, 25. Mär. 2015 (CET)

Vor- und Nachteile in der Einleitung

In der Einleitung stand folgender Satz:

Ein großer Vorteil von GC ist die Vermeidung von Fehlern, die bei einer manuellen Speicherverwaltung leicht auftreten können (z. B. Speicherlecks, doppelte Freigaben, hängende Zeiger). Nachteilig sind ein signifikanter zusätzlicher Verwaltungsoverhead und häufig ein nicht-deterministisches Verhalten der Ausführungsumgebung und damit unter Umständen auch des Programms selbst.

Ich habe diesen Satz jetzt aus folgenden Gründen gelöscht:

• Es ist unüblich in der Einleitung die Vor- und Nachteile eines Lemmas stark verkürzt zu beschreiben
• Es gibt dazu bereits einen ausführlichen Abschnitt "Eigenschaften", in dem die Vor- und Nachteile breit behandelt werden
• Es gibt wesentlich mehr Vor- und Nachteile als in der Einleitung stehen (siehe Abschnitt "Eigenschaften")
• Viele der Vor- und Nachteile sind umstritten und es gibt unterschiedliche Aussagen in der Literatur (siehe Abschnitt "Eigenschaften") - sie in der Einleitung verkürzt & somit einseitig darzustellen ist daher inkorrekt.

Ich hatte diese Entfernung mit der Begründung "Vor- und Nachteile zu anderen Vor- und Nachteilen in Eigenschaften verschoben..." bzw. den Abschnitt unten damit ausgebaut/bequellt etc.[2], Benutzer:Shaddim hat ihn mit der Begründung "-rekonstruktion der unbegründeter entfernung der in langer konsens arbeit erstellten einführung" wieder eingebaut [3].

Einen "erarbeiteten Konsens" kann ich in der Diskussion nicht erkennen. Trotz vieler Vorschläge (die meisten davon ohne die Vor- und Nachteile) gabs schlussendlich keinen Konsens. In der Diskussion gings vor allem um "Determinismus" - dieser ist ja auch weiterhin im Artikel beschrieben, nur halt im Abschnitt Eigenschaften. --Sebastian.Dietrich ✉ 09:35, 18. Mär. 2015 (CET)

An den akzeptierten konsens mehrerer autoren solltest du dich erinnern koennen da du daran beteiligst warst. Auch stellt die formulierung einen vernuenftigen, ausgrwogennen kompromiss bei der darstellung der eigenschaften der gc dar (in vor- und nachteilen, ja auch den nachteilen). Und prinzipell sind darstellungen der kerneigenschaften im lemma sehr wohl ueblich sogar erwuenscht. Gruesse Shaddim (Diskussion) 11:02, 18. Mär. 2015 (CET)

Es gab keinen Konsens. Siehe [4].

Die Einleitung stellt auch keinen "vernuenftigen, ausgrwogennen kompromiss" dar - nichts steht z.B. dort zu Performance, was einer der größten Streitpunkte ist. Der "signifikante Verwaltungsoverhead" ist auch nicht belegt (Beleg 1 spricht nur von konservativer GC - also von einem Teilbereich der GC der heutzutage irrelevant ist, Beleg 2 spricht gar nicht von Verwaltungsoverhead, sondern betrachtet die Performance bei unterschiedlich viel reserviertem Speicher). Ich halte den "Verwaltungs"overhead für minimal (wieviel kb hat wohl der Code/Speicherverwaltung eines GC?). Wenn dann gibt es wie belegt aus Performancegründen einen erhöhten Speicherbedarf, aber keinen Verwaltungsoverhead.

Die Vor- und Nachteile sind keine Kerneigenschaften und somit generell in Einleitungen unerwünscht.

Ich bin wie gesagt nicht für die Streichung der Punkte - nur in der Einleitung haben sie nichts verloren - Begründung siehe oben. --Sebastian.Dietrich ✉ 12:41, 18. Mär. 2015 (CET)

Es gab einen Konsens bei einer Version bei der keiner mehr widersprochen hatte, ein typischer Kompromiss. Die knappe Erwähnung von Kerneigenschaften eines Themas hat in der Einleitung sehr wohl was verloren. Shaddim (Diskussion) 13:02, 18. Mär. 2015 (CET)

Wir drehen uns im Kreis - ich sage es gab keinen Konsens & belege das, du sagst, es gab doch einen und belegst es aber nicht.

Ich sage dass Vor- und Nachteile keine Kerneigenschaften sind, und somit nicht in die Einleitung gehören, du sagst dass Kerneigenschaften in die Einleitung gehören (aber nichts ob Vor- und Nachteile Kerneigenschaften wären).

Ich sage, dass in der Einleitung ein nicht belegter Punkt steht, & dass dort der umstrittenste Vor- bzw. Nachteil nicht drinnen steht, du sagst dazu nichts.

Brauchen wir wirkliche eine WP:3M? --Sebastian.Dietrich ✉ 17:12, 18. Mär. 2015 (CET)

Nein, nur die History: Version 7.12.2012, Kommentar Sebastion.Dietrich 7.12.2012: "Ok lassen wirs dabei. Jedes Programm hat ein nicht-deterministisches Laufzeitverhalten, somit auch GCs. Solange "Laufzeitverhalten" dabei bleibt. Ob sonstiger Determinismus bei GCs die Ausnahme oder die Regel ist steht nicht in der Einleitung, also passts für mich. --Sebastian.Dietrich ✉ 11:50, 7. Dez. 2012 (CET)" Habe für eine Einleitung mit kurzem Überblick über relevante Aspekte die WP-Richtlinien für gute Artikel auf meiner Seite, ich zitiere "Wie schreibe ich gute Artikel#Begriffsdefinition und Einleitung": "Unmittelbar darauf [Benamungserklärung] sollte eine kurze Einleitung mit einer Zusammenfassung der wichtigsten Aspekte des Artikelinhalts folgen. Die Einleitung soll dem Leser einen kurzen Überblick über das Thema ermöglichen und das Lemma in Grundzügen erklären. Es empfiehlt sich (vor allem bei Personenartikeln) bereits an dieser Stelle die Bedeutung hervorzuheben." Ich hoffe nicht das du bestreitest das Performance ein wichtiger Aspekt des Artikels und vieldiskutierter, bedeutender Aspekt von GC ist, so das dieses folgerichtig in der Einleitung erscheint. Wenn etwas der Fall ist, dann das die Einleitung zu knapp ist nicht zu lang, so das man mutwillig kürzen könnte. Shaddim (Diskussion) 18:39, 18. Mär. 2015 (CET)

Genau - da gings nur mehr um den Punkt des deterministischen Verhaltens - also schon längst nicht mehr um die gesamte Einleitung. Einen Konsens (aller Diskussionsteilnehmer & zur gesamten Einleitung) hat es nie gegeben. Die Disk wurde eher abgebrochen. Keiner der diskutierten Vorschläge wurde danach umgesetzt.

@"Performance ein wichtiger Aspekt des Artikels" Siehst - genau das meine ich. Weil über Performance steht gar nichts in der Einleitung & sogar du hast Performance mit Verwaltungsoverhead verwechselt. Die Einleitung enthält nur willkürlich ausgewählte Vor- und Nachteile, die Infos zu Verwaltungsoverhead (= Speicherbedarf der GC selbst) sind zudem falsch und auch nicht belegt (siehe oben) und noch dazu mit einem willkürlichen "signifikant" versehen. Zudem ist der winzige Verwaltungsoverhead (siehe oben) heutzutage nicht von Bedeutung.

Die Einleitung dient - wie du auch geschrieben hast - dem Überblick und den Grundzügen des Lemmas. Dazu gehören keine Vor- oder Nachteile. Darum findest auch in keinem/kaum einem Artikel Vor- oder Nachteile im Lemma. --Sebastian.Dietrich ✉ 20:33, 18. Mär. 2015 (CET)

Verwechselt wurde gar nichts, Overhead kann sich auf Laufzeitoverhead als auch Speicheroverhead beziehen. Deiner Interpretation des vorherigen Diskussionsverlauf ist schwer zu folgen, Fakt ist es wurde eine Version gefunden bei der die Diskussion keiner mehr fortführen wollte und keiner mehr in Edit-War Laune war. Ein klassischer Erschöpfungskompromiss. ;) Gut, wenn du nun plotzlich für eine Erweiterung der Einleitung (anstelle der radikalen Zusammenstreichung) bist, können wir vorankommen. Haha, winzig ;) Und natuerlich sind Vor- und Nachteile charakterisieredne Eigenschaften, absurd anderes zu behaupten.Shaddim (Diskussion) 21:17, 18. Mär. 2015 (CET)

"Zudem ist der winzige Verwaltungsoverhead (siehe oben) heutzutage nicht von Bedeutung." bitte Belege hierfür bin wirklich gespannt, sollte ja dann kein Problem sein hier Paper zu finden. Shaddim (Diskussion) 21:23, 18. Mär. 2015 (CET)

Sorry - ich muss jetzt WP:3M einfordern, da du nicht auf meine Argumente eingehst. Hier nochmals meine Punkte:

• Es ist unüblich in der Einleitung die Vor- und Nachteile eines Lemmas stark verkürzt zu beschreiben. Vor- und Nachteile sind nicht charakterisierende Eigenschaften - insbesondere dann nicht, wenn sie umstritten sind.
• Es gibt wesentlich mehr Vor- und Nachteile als in der Einleitung stehen (siehe Abschnitt "Eigenschaften"). Die aktuelle Aufzählung ist somit eine willkürlich ausgewählte.
• Der in der Einleitung genannte Nachteil des "signifikant zusätzlichen Verwaltungsoverheads" ist falsch und nicht belegt. (Beleg 1 kommt aus der Steinzeit, betrachtet nur die konservative GC - also einen Teilbereich der GC der heutzutage irrelevant ist, Beleg 2 spricht gar nicht von Verwaltungsoverhead, sondern betrachtet die Performance bei unterschiedlich viel reserviertem Speicher) - darum werden beide Belege unten auch für 2 gänzlich andere Punkte verwendet (Beleg 1 für Speicherverbrauch, Beleg 2 für Leistungsfähigkeit).

--Sebastian.Dietrich ✉ 17:37, 19. Mär. 2015 (CET)

Die veränderte Verwendung wurde von dir eingeführt. Und du änderst deine Argumentation permanent, zB ursprünlgich hast du behauptet Vor- und Nachteil in der Einleitung wären völlig unüblich, nun argumentierst du das Problem ist das dies umstritten ist... schwer so zu diksutieren. Shaddim (Diskussion) 19:02, 19. Mär. 2015 (CET)

Vor uns Nachteile sind in der Einleitung völlig unüblich. Ich kenne keinen einzigen Artikel in dem die Vor- und Nachteile in der Einleitung stehen. Darüberhinaus sind Vor- und Nachteile keine charakterisierenden Eigenschaften - insbesondere dann nicht, wenn sie umstritten sind. Das sind 2 Punkte, die sich ergänzen und kein Gegensatz zueinander... --Sebastian.Dietrich ✉ 19:50, 19. Mär. 2015 (CET)

Das dir persönlich kein Beispiel bekannt ist (aufgefallen, whatever you meant with that) hat natuerlich keinerlei Bedeutung- wichtiger ist der von mir zitierte Text zu WP-empfehlungen für Einleitungen der besagt das Einleitungen den Artikel zusammenfassen sollen. Im Softare-Engineeringbereich (und jedem engineering) sind Vorteils-Nachteilsüberlegungen von essentieller Bedeutung zur Beurteilung einer Technologie, d.h. diese nicht in der Einleitung zu haben wär sträflich unvollständig. Deine andere Argumentation über die Strittigkeit der konkreten Vor- und Nachtiele, ist eine (von dir neu aufgebrachte) davon völlig unabhängige Argumentationslinie. Shaddim (Diskussion) 20:26, 19. Mär. 2015 (CET)

Klar hat mein Nichtwissen keine Bedeutung, allerdings scheinst auch Du kein Beispiel zu haben, wo Vor- und Nachteile ein bestandteil der Einleitung wären. Fazit: Vor- und Nachteile in der Einleitung sind völlig unüblich - auch im Software-Engineeringbereich, wo sie deiner Meinung nach so wichtig wären.

Vor- und Nachteilsüberlegungen sind für Techniker etc. sicher wichtig, aber wir schreiben nunmal eine Enzyklopädie und kein Technologievergleichshandbuch. D.h. das wichtige eines Lemmas ist das Lemma selbst zu beschreiben. Vergleiche mit anderen Dingen sind bestenfalls Nebensache. Hier geht es um den Artikel Garbage Collection und nicht um den Vergleich Garbage Collection vs. manuelle Collection. Dieser Vergleich ist ja auch in den meisten Programmiersprachen hinfällig, da sie nur entweder das eine oder das andere bieten. Allein darum fällt ein Vergleich schwer und die Benchmarks können nur das eine, aber nicht das andere messen.

Bisher hast du dich noch nicht geäußert zu a) der völlig willkürlichen Auswahl einiger der Vor- und Nachteile und b) zu dem unbelegten Nachteil des angeblich signifikanten Verwaltungsoverhead. Beides habe ich bereits zu Beginn der Diskussion eingebracht. Wenn hier nicht bald was kommt, dann Lösche ich die Vor- und Nachteile wieder, weil ins Leere zu Diskutieren macht keinen Sinn. --Sebastian.Dietrich ✉ 21:54, 19. Mär. 2015 (CET)

Willkürlich war diese Version nicth sondern Ergebnis harter "Kompromiss-Arbeit", auch unter deiner Beteiligung (und hatte über Jahre Bestand). Deswegen denke ich kann man die die aktuelle Version durchaus als ausgewogen ansehen, nach so langer Reifzeit- und viel investierter Arbeit, wenn du der Meinung bist es gibt bessere Lösungen, mach doch mal bitte nen Vorschlag für ne ausgewogenere Formulierung & Content ich bin ganz Ohr. Shaddim (Diskussion) 21:51, 20. Mär. 2015 (CET)

Sorry - aber das stimmt einfach nicht. Es gab keinen Kompromiss, es gab Vorschläge, die gänzlich anders waren - nachdem man sich für keinen Vorschlag mit einem Kompromiss einigen konnte, bliebs de facto beim Ist-Stand. Dass der leider jahrelang Bestand hatte tut nichts zur Sache.

So wie es jetzt ist kanns auf gar keinen Fall bleiben, weil eben der eine Satz unbelegt und falsch ist. Ich habe den jetzt wie angekündigt rausgenommen. Meinen Vorschlag kennst du. Streichung der Vor- und Nachteile. Dafür haben sich inzwischen schon drei Leute ausgesprochen.

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Software- und Informationstechnik eine automatische Speicherverwaltung, die den Speicherbedarf eines Computerprogramms minimiert. Dabei wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben. Manche automatische Speicherbereinigungen führen darüber hinaus die noch verwendeten Speicherbereiche zusammen (Defragmentierung).

@Shaddim - warum hast du meine Änderung rückgängig gemacht [5]? Ich habe dich bereits X mal darum gebeten zu diesem Teilaspekt (unbelegter Satz über angeblich "signifikanten zusätzlichen Verwaltungsoverhead") deinen Senf dazuzugeben. Bisher verweigerst du jede Diskussion dazu - aber rücksetzen kannst. Du fährst offensichtlich eine Blockadepolitik - zurücksetzen mit Hinweis auf Diskussion, aber dazu nicht diskutieren. Ich fordere jetzt dich zum letzten Mal auf, dich (auch) zu diesem Punkt zu äußern. --Sebastian.Dietrich ✉ 08:57, 21. Mär. 2015 (CET)

unfug. Erstens wartest du deine selbst angeleierte 3te meinung nicht ab, 2ten verstehe ich nicht was du an den beigebrachten referenzen nicht verstehst: entweder signifikanter speicheroverhead oder signifikanter laufzeitoverhead, im schluss signifikanter overhead. Umgekehrt hast du bis jetzt weder quellen noch alternativen beigebracht. Shaddim (Diskussion) 09:39, 21. Mär. 2015 (CET)

Die 3te Meinung geht Richtung "Vor- und Nachteile in der Einleitung" und nicht Richtung "Unbelegter Schwachsinn in der Einleitung". Gelöscht habe ich 2teres, aber du hast es wieder reingestellt.

Bitte lies dir doch (endlich) mal das durch was ich oben schon mehrmals geschrieben habe: Der "signifikante Verwaltungsoverhead" ist nicht belegt.

• Beleg 1 ist aus der Steinzeit und spricht nur von konservativer GC - also von einem Teilbereich der GC der heutzutage irrelevant ist.
• Beleg 2 ist aus der Antike und spricht gar nicht von Verwaltungsoverhead, sondern betrachtet die Performance bei unterschiedlich viel reserviertem Speicher).

Unten sind die Belege im richtigen Zusammenhang, in der Einleitung nicht. Der Satz ist nicht belegt und was Performance betrifft unten sogar durch die C't Artikel widerlegt. --Sebastian.Dietrich ✉ 10:37, 21. Mär. 2015 (CET)

1993 und 2005 sind kein problem da die Aussagen prinzipiell gueltig sind. Bitte (neuere?) Belege bringne die was gegenteiliges sagen. "sogar" C't artikel, hinter paywall ;) ? Gegen wissenschaftliche Analyse? Hier ist 3. beleg der eine signifikanten Overhead diagnostiziert: "sechsmal grösserer Speicherverbrauch GC" "expl. MM significant better page locality". Zu deiner andauerenden Verständnisblockade "sondern betrachtet die Performance bei unterschiedlich viel reserviertem Speicher" -> ein programm das mit expliziten speichermanagment X speicherressourcen benötigt und Y rechenzeitressourcen, benötigt entweder 6*X (auch reserviert, muss vorhanden sein) oder 2*Y (und alle zwischenmischungen beider) mit GC. Diese Situation ist die Definition von bloat, overhead. Z.B ein System mit nur X Speicher insgesamt müsste mit GC 2mal lahmer laufen als mit expl. MM. Shaddim (Diskussion) 22:50, 21. Mär. 2015 (CET)

Wunderbar - also (neben den c't Artikeln, deren Zusammenfassung was Performance anbelangt du im ref nachlesen kannst) noch ein Beleg (schon Beleg 2 spricht von "its runtime performance matches or slightly exceeds that of explicit memory management"), dass bei genügend Speicher die GC schneller ist als manuelles Memory Management. Damit haben wir dafür jetzt schon 3 Belege, das gehört unbedingt in die Einleitung. "Comparing runtime, space consumption, and virtual memory footprints, we find that when space is plentiful, the runtime performance of garbage collection can be competitive with explicit memory management, and can even outperform it by up to 4%". Und immer noch kein einziger Beleg zu "Verwaltungsoverhead" - die Artikel sprechen von Memory, dass man der Applikation zuweist - das ist was anderes als "Verwaltungsoverhead". --Sebastian.Dietrich ✉ 22:22, 23. Mär. 2015 (CET)

seufz selektive wahrnehmung. Hier eine weitere Hilfestellung für mehr Durchblick: "Comparing runtime, space consumption, and virtual memory footprints, we find that when space is plentiful [und kann deshalb verschwendet werden, also Speicherressourcen-Overhead], the runtime performance of garbage collection can be competitive with explicit memory management, and can even outperform it by up to 4%. We find that copying garbage collection can require six times the physical memory as the Lea or Kingsley allocators to provide comparable performance. We also show that garbage collection suffers orders-of-magnitude performance penalties when paging occurs. This first-ever comparison of explicit memory management and copying garbage collection shows where garbage collection must improve in the future . Von "quantifiying the performance of GC": These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a non-copying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. Das ist exakt overhead. Shaddim (Diskussion) 13:23, 24. Mär. 2015 (CET)

Das ist Overhead a la Shaddim. Was andere unter Overhead verstehen (und was auch in dem angekreideten Satz verlinkt war), wird im Artikel Overhead (EDV) definiert. Und das ist was ganz anderes: "Daten, die nicht primär zu den Nutzdaten zählen, sondern als Zusatzinformation zur Übermittlung oder Speicherung benötigt werden". --Sebastian.Dietrich ✉ 21:43, 24. Mär. 2015 (CET)

Was immer Aufmerksamkeit erregen sollte sind Abweichung in Größenordnungen. Sie sind meist erwähnenswert.

Das Paper halte ich für eine reputable Quelle (da über ACM publiziert und immerhin 76 mal zitiert) und 10 Jahre sind da im Allgemeinen auch nicht viel. In Java hat sich seit dem jedoch einiges getan (welche Version war das damals?), insofern ist die Information möglicherweise schon überholt. Hier ist zB. ein aktuelles Paper aus diesem Jahr [6], leider bin ich derzeit unterwegs und komme daher nicht durch die Pay-Wall.

Ich würde anbieten, bis nächste Woche mal eine Paper-Recherche zu machen, was der aktuelle Stand in Sachen GC-Performance ist. Interessiert mich selber und könnte dann auch irgendwo in den Artikel einfließen. Noch wichtiger aber: Es wäre ein etwas solideres Diskussionsfundament.

In Sachen Overhead: Begrifflich ist das grundsätzlich jeder Mehrverbrauch an Ressourcen, der über das Notwendige hinaus geht. Wenn die Java-GC nur mit dem 6-fachen des eigentlich benötigten Speichers vernünftig arbeitet, dann ist das auch für mich ein klarer Overhead von 500% des Speichers, denn wenn man ihn wegnimmt bricht die Performance katastrophal ein.--Plankton314 (Diskussion) 23:09, 24. Mär. 2015 (CET)

2005 war Java 1.5 (jetzt haben wir 1.8) - das Paper verwendet aber gar nicht die Java VM (sondern die Jikes Research VM, die selbst in Java geschrieben ist) und es verwendet auch nicht einen Java GC, sondern verwendet den Garbage Collector der Jikes RVM (GenMS), der z.B. kein mark-and-compact macht wie die Java GCs & deshalb den Speicher nicht defragmentiert (Defragmentierung reduziert die Speicheranforderungen & erhöht die Performance). Die Erkenntnisse sind also per se nicht auf Java GCs umlegbar. Dass der GC in dem Paper noch dazu in Java geschrieben ist macht aus meiner Sicht das Paper völlig unglaubwürdig. Niemand würde heutzutage einen GC in Java schreiben und dann behaupten, dass GC langsamer ist als klassische Allokation/Deallokation. Gerade das tiefe Einbetten eines GCs in die Sprache und Ablaufumgebung machen die Performance eines GCs aus.

Was diese Paper auch allesamt nicht überprüfen, ist, dass konventionelle GC ebenfalls deutlich mehr Speicher "benötigt", da sie keine Defragmentierung macht. Ich brauche also deutlich mehr als X GB RAM, auch wenn ich Objekte in der Größenordnung von X GB allokiere. Es gibt Situationen (bei z.B. laufend größer werdenden Allokationen), wo man auch bei 10x soviel RAM keine Objekte mehr allokieren kann. In Java z.B. gibts garantiert erst dann einen OutOfMemory Error, wenn der Speicher tatsächlich ausgeht.

Was ebenfalls nicht überprüft wird, sind die Full-Stop-GCs - das ist in der Praxis der einzige Nachteil von GCs, da es dadurch zu Hickups von mehreren Sekunden kommen kann. Je mehr Speicher man einem Programm gibt, desto seltener sind die zwar, aber desto länger dauern sie auch. In der Praxis sehr selten (in den Benchmarks natürlich häufig), aber dennoch untragbar.

In Java macht man in der Praxis folgendes: Man schaut, wieviel RAM ein Java Programm in der Realität max benötigt und gibt der Applikation dann etwas mehr (vielleicht +20% oder +50%, aber selten +100% und niemals +500%) Speicher. Mehr Speicher macht die Applikation in der Praxis nur geringfügig schneller (weniger Full GCs), führt aber zu mehr Hickups (längere Full GCs). Wäre in Java die GC Performance tatsächlich um 70% geringer bei doppelt soviel Speicherverbrauch, wäre Java als Programmiersprache für Android untragbar, da Speicher und CPU dort ja noch eher Mangelware ist.

@Overhead: Das ist eben nicht der "simple Mehrverbrauch" an Ressourcen, sondern der "unnötige" Mehrverbrauch an Ressourcen. Ein Auto, dass 15l auf 100km benötigt hat keinen Overhead gegenüber einem, dass nur 5l benötigt. Wenn es deshalb soviel verbraucht, weil der Reifendruck gesenkt wurde, um besser auf Sand fahren zu können, dann ist das kein Overhead (weil der geringe Reifendruck ja einen Zweck hat). Es ist nur dann Overhead, wenn der geringe Reifendruck keinen Sinn hat.

Bei GC bedeutet das, dass Overhead an Speicher der Speicher sein muss, denn die GC selbst für die Verwaltung des ihr zugewiesenen Speichers benötigt (also z.B. die Verwaltung der Generationslisten etc.). Es kann aber nicht der Speicher sein, den man der GC zuweist um (vermeintlich) die Geschwindigkeit zu erhöhen.

D.h. Overhead ist das falsche Wort. --Sebastian.Dietrich ✉ 09:35, 25. Mär. 2015 (CET)

Haarspalterei, natuerlich ist das overhead. "Ein Auto, dass 15l auf 100km benötigt hat keinen Overhead gegenüber einem, dass nur 5l benötigt." Natuerlich ist auch das Overhead an Ressorucenverbrauch (der deutsch-sprachige Overhead artikel ist mla wieder deutlich schlechter als der enWP...todo). Und anectdotal references ala "JAva verwendet meinem gefühl nach "nur" 50% mehr" sind natuerlich nicht belastbar. Ausserdem wurde das erklärt, das bedeutet einfahc den Trade-off Richung mehr Laufzeitressourcen verbrauchen schieben (aka häufiger garbage collection cycles...) Und zum Beispiel Android, es gibt Quellen (such ich noch raus) die zeigen das native apps teilweise grössenordnungen schneller und effizienter laufen.

PS: just for fun, best-practices für das performante programmieren von android spielen, "Manual tracking of objects, sadly." & ne gute analyse füpr mobile Shaddim (Diskussion) 10:09, 26. Mär. 2015 (CET)

Klar ist das Overhead - Overhead a la Shaddim. Und wenn die WP Seite zu Overhead (EDV) was anderes sagt, dann muss diese Seite geändert werden (dein ToDo oben). Vielleicht änderst bei der Gelegenheit auch gleich Overhead und Gemeinkosten. Aber egal - Overhead ist ja mal draussen aus der Einleitung, da waren wir uns einig. Unten stehts richtig, auch deine Refs zu lustigen GCs, die mit der Realität nichts zu tun haben. --Sebastian.Dietrich ✉ 19:42, 26. Mär. 2015 (CET)

Worüber einigkeit bestand war dein indiffernziertes löschen rückgängig zu machen und dem aspekt leistungsfähigkeit (oder die fehlden) nen gebührenden Raum zu geben. Die aktuelle formulierung ist ein kompromiss und meiner meinung nahc zu knapp - dafür verständlich. PS: Developer Tools Kickoff - session 300. In: WWDC 2011. Apple, inc., 24. Juni 2011, abgerufen am 27. März 2015: „"At the top of your wishlist of things we could do for you is bringing garbage collection to iOS. And that is exactly what we are not going to do… Unfortunately garbage collection has a suboptimal impact on performance. Garbage can build up in your applications and increase the high water mark of your memory usage. And the collector tends to kick in at undeterministic times which can lead to very high CPU usage and stutters in the user experience. And that’s why GC has not been acceptable to us on our mobile platforms. In comparison, manual memory management with retain/release is harder to learn, and quite frankly it’s a bit of a pain in the ass. But it produces better and more predictable performance, and that’s why we have chosen it as the basis of our memory management strategy. Because out there in the real world, high performance and stutter-free user experiences are what matters to our users."“ Shaddim (Diskussion) 11:18, 27. Mär. 2015 (CET)

@PS - was genau soll das belegen? Dass Apple nicht auf die Wünsche der Entwicklergemeinde hört? Dass Apple GC verteufelt und statt dessen bewusst Entscheidungen für "pain in the ass" Programmierung macht? Und dann kommens mit einer Compileroption namens "automatic reference counting", was nichts anderes als ein Einbau eines GCs mittels reference counting ist und lassen sich feiern, als ob sie das Rad neu erfunden hätten? Nein Apple unterstützt weiterhin GC, nennt es aber ARC und das läuft seriell und somit vorhersagbarer, kann aber keine zyklischen Referenzen auflösen und verursacht deshalb Memory Leaks. Und klar gibts Apple Fanboys die sagen, dass aus genau diesem Grund IPhones schneller als Android Phones mit mehr Speicher sind. --Sebastian.Dietrich ✉ 20:22, 27. Mär. 2015 (CET)

WP:Dritte Meinung

Das ist nach meiner Erfahrung ein häufiges Dritte-Meinung-Problem. Einleitungen wachsen gerne wie Krebsgeschwüre an, weil jeder noch irgendwas wichtiges weiß, was der Leser auf jeden Fall lesen muss, bevor er beim Inhaltsverzeichnis aufhört. Die einfachste Lösung besteht darin, die Einleitung auf ein Minimum zu reduzieren und dann gleich mit Absätzen zu beginnen. Also ungefähr:

Die Garbage Collection GC (englisch für „Müllabfuhr“) ist ein Teil der Speicherverwaltung in der Informationstechnik. Dabei werden, bereits zur Laufzeit eines Programmes, nicht mehr benötigte Speicherbereiche automatisch identifiziert und freigegeben. Andere Bezeichnungen sind Automatische Speicherbereinigung oder Freispeichersammlung.

Und dann kommt erstmal das Inhaltsverzeichnis, aus dem der Leser dann das aussucht, was ihn darüber hinaus interessiert. --Siehe-auch-Löscher (Diskussion) 11:43, 20. Mär. 2015 (CET)

Knapp ist gut, zu knapp ist aber auch nicht gut .... und das Problem ist "aus dem der Leser dann das aussucht, was ihn darüber hinaus interessiert." != "Was relevant zu dem Thema zu wissen ist". Meine Vision (&der Richtlinien "Wie schreibe ich gute Artikel#Begriffsdefinition und Einleitung": "Unmittelbar darauf [Benamungserklärung] sollte eine kurze Einleitung mit einer Zusammenfassung der wichtigsten Aspekte des Artikelinhalts folgen. Die Einleitung soll dem Leser einen kurzen Überblick über das Thema ermöglichen und das Lemma in Grundzügen erklären") ist mehr ein Abstract/Übersicht die alle relevanten Aspekte zumindest anschneidet/zusammenfasst. Shaddim (Diskussion) 21:51, 20. Mär. 2015 (CET)

Also auch du bist somit der Meinung, dass die Einleitung schlecht ist, weil sie nicht _alle_ relevanten Aspekte anschneidet. --Sebastian.Dietrich ✉

Quatsch, ich bin vor allem dagegen das relevante Aspekte gelöscht werden, wie ursprünlgich von dir vorgenommen was das Gegenteil war von "mehr relevante Aspekte in die Einleitung bringen". Shaddim (Diskussion) 10:09, 26. Mär. 2015 (CET)

Das ist wirklich ein kniffliges Problem. Wenn die Darstellung der Vor- und Nachteile konsensfähig wäre, scheint mir das in zwei Sätzen hinreichend kompakt formuliert zu sein. Andererseits ist demjenigen, der nur die Zusammenfassung liest, auch nicht damit gedient, wenn die Auswahl der Teilaspekte und die Bewertung ihrer Tragweite nicht in der gebotenen Kürze neutral darstellbar ist. Gewissermaßen möchte ich den schwarzen Peter zurückgeben: wenn ihr eine Einigung findet, um so besser für den Leser. Ein denkbarer Kompromiss wäre die beispielhafte Nennung des jeweils stärksten Pro- und Contra-Arguments. Sollte sich aber kein erkennbarer Konsens abzeichnen, dann ist die Einleitung auch ohne diese beiden Sätze in Ordnung, darüber sollte man sich nicht nachhaltig in die Wolle kriegen. --Eloquenzministerium (Diskussion) 22:23, 20. Mär. 2015 (CET)

Danke fuer den schlichtungsbeitrag. stimme zu, das waere eine gute salomonische kompromissloesung, vor- und nachteil gleichgewichtet darzustellen. Shaddim (Diskussion) 09:39, 21. Mär. 2015 (CET)

Genau - kopieren wie doch einfach den Abschnitt Eigenschaften in die Einleitung und dann hat es sich. Die Vor- und Nachteile sind wie geschrieben umstritten, die "Auswahl der Teilaspekte und die Bewertung ihrer Tragweite sind nicht in der gebotenen Kürze neutral darstellbar". Du kannst ja mal einen Vorschlag machen, wie a) die Auswahl der Teilaspekte in der Einleitung dargestellt werden soll und b) die ausgewählten Vor- und Nachteile so dargestellt werden, dass sich ihre Tragweite bewerten lässt oder c) wie alle Vor- und Nachteile so dargestellt werden, dass sich ihre Tragweite bewerten lässt. Derzeit ist weder a) noch b) noch c) gegeben. --Sebastian.Dietrich ✉ 10:37, 21. Mär. 2015 (CET)

Den ganzen Abschnitt Eigenschaften? Ausserdem, die vor- und nachteile sind nicht umstritten sondern wohl bekannt und wohl belegt. Was umstritten ist, ist die gewichtung die bei der Darstellugn gewährt werden soll. Die aktuell, durch Kompromiss existierende Variante nennt recht deutlich die vorteile aber auch die damit erkauften nachteile. Von diesem wohlgewichteten verhältnis sollten wir nicht abgehen. Vorschlag fuer reduktion auf 1 zu 1:" Ein großer Vorteil von GC ist die Vermeidung von Fehlern, die bei einer manuellen Speicherverwaltung leicht auftreten können (z. B. Speicherlecks, doppelte Freigaben, hängende Zeiger). Nachteilig sind die Notwendigkeit eines zusätzlichen zur Laufzeit eigenständig und heuristisch agierenden Managerprogramms, was zu zusätzlichen Ressourcenbelastungen als auch zu schwer vorhersagbarem, nicht-deterministischem Verhalten führt." Shaddim (Diskussion) 22:50, 21. Mär. 2015 (CET)

Je kompakter man versucht, komplexe Vorgänge darzustellen, desto schwieriger wird es. Die Einleitung wird eine ausgewogene Diskussion sämtlicher Vor- und Nachteile nicht leisten können. Mein Formulierungsvorschlag, der deutlich vereinfachender ist, als was aktuell zur Debatte steht, geht in diese Richtung:

---

Wesentlicher Vorteil von GC gegenüber manueller Speicherverwaltung ist die Vermeidung von Fehlern, der mit einem erhöhten Ressourcenverbrauch erkauft wird.

---

Das ist natürlich noch deutlich besser formulierbar, aber ich denke eine Einigung ist um so einfacher, je weniger detailliert die Vor- und Nachteile benannt werden. Im Artikel selber wird die Frage ja dann auch ausführlichst und nuanciert erläutert. Ich hoffe, das könnte eine Basis für eine zügige Einigung sein. --Eloquenzministerium (Diskussion) 14:12, 22. Mär. 2015 (CET)

Ok! extrem zusammengeschmurrgelt...aber den Nagel auf den Kopf getroffen -> relevanter automatischer vorteil hat relevanten resourcennachteil zur folge! ;) (ok, bis auf den determinismus, welcher wirklich relevant noch drüberhausgeht... egal, für den lesefluss!) Shaddim (Diskussion) 22:27, 22. Mär. 2015 (CET)

Damit kann ich auch leben. Der "Verwaltungsoverhead" ist weg und Ressourcenverbrauch geht deutlich weg vom vermeintlichen Nachteil der geringeren Performance. --Sebastian.Dietrich ✉ 22:29, 23. Mär. 2015 (CET)

Es freut mich sehr, hier eine für alle konsensfähige Lösung gefunden zu haben, bedanke mich für die sachliche Diskussionsatmospäre und setze das dann mal um. Die eine ref, die dadurch aus dem Artikel verschwunden wäre, werfe ich hier vorsichtshalber nochmal ab, falls sie anderwo noch gebraucht wird:

<ref>[http://www.fridi.de/rts/papers/cc01_fsiebert.pdf Constant-Time Root Scanning for Deterministic Garbage Collection] (PDF; 375 kB): ''Garbage Collection [...] typically brings a high degree of indeterminism to the execution environment.''</ref>

--Eloquenzministerium (Diskussion) 23:27, 23. Mär. 2015 (CET)

Danke. Die steht ohnedies unten bei Determinismus. --Sebastian.Dietrich ✉ 23:50, 23. Mär. 2015 (CET)

Gerne. Da ich zwei named refs sah, nahm ich an, diese könnte ein Einzelstück sein. Ich würde Euch ja auch gerne bei den teilweise recht langen Diskussionen um andere Formulierungen in der Einleitung helfen, fürchte allerdings, daß die hier erfolgreich praktizierte Methode nur eingeschränkt portierbar ist. Was vielleicht helfen würde, wäre eine kurze, objektive Zusammenfassung der zahlreichen Vordiskussionen zur Einleitung mit Archivlinks. Dss könnte zirkuläre Teile der Debatte reduzieren und den Fokus auf noch nicht diskutierte Aspekte lenken. So ähnlich wie das bei den RK praktiziert wird: [7]. Das ist natürlich mit Arbyte verbunden, würde aber sicher langfristig frustrierende, immer wieder neu beginnende Diskussionen vermeiden oder zumindest in eine produktive Richtung orientieren, wenn alle Teilnehmer sich mit vertretbarem Aufwand ein Bild vom damaligen Konsens machen können. --Eloquenzministerium (Diskussion) 01:16, 24. Mär. 2015 (CET)