Diskussion:Garbage Collection/Archiv/1

Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite. 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/1#Abschnittsüberschrift]] oder als Weblink zur Verlinkung außerhalb der Wikipedia https://de.wikipedia.org/wiki/Diskussion:Garbage_Collection/Archiv/1#Abschnittsüberschrift

Ist "handleless" häufiger oder nicht?

Zitat aus dem Artikel, unter Algorithmen, Mark&Sweep: Nachteil dieser Methode ist das Verschieben der lebenden Objekte selber, denn Zeiger auf diese werden ungültig und müssen angepasst werden. Meistens wird dies erreicht, indem ein Objekt über zwei Indirektionen angesprochen wird: über einen Zeiger auf einen Zeiger auf das Objekt. Beim Verschieben des Objekts muss nun nur noch der Zeiger, der direkt auf das Objekt zeigt, angepasst werden. Die Referenzen in Java und C# sind beispielsweise solche "Zeiger auf Zeiger".

Das ist zumindest im Falle von heutigen Java-Versionen falsch. Dort werden schon lange Handleless-Objekts verwendet, wie man auch unter [1] zu lesen ist. Weis jemand, wie das unter C# aussieht? --Deabyte 12:45, 28. Mär 2005 (CEST)

Gemeint ist wohl "Mark&Compact" und was nun heute in der Praxis häufiger ist, ist ja nun unklar, so dass ich im Rahmen einer Überarbeitung beides ohne solche Wertung nebeneinander gestellt habe... --Heimschützenverein 14:29, 6. Feb. 2008 (CET)

Speicherlecks

Wo steht, dass die Garbage-Collection unter Umständen Speicherlecks verursacht? --(nicht signierter Beitrag von 62.225.112.236 (Diskussion) 11:34, 10. Jun. 2005 (UTC))

Diese Frage möchte ich unterstreichen. Ich habe unter Component Pascal im BlackBox Component Builder bereits abertausende von automatischen Garbage-Collectionen erlebt, ohne dass es jemals zu einem Problem gekommen wäre (weder Speicherlecks noch fälschlich freigegebener Speicher). Die unvollkommene automatische Speicherbereinigung in C-basierten Systemen oder wenn das Laufzeitsystem bewusst umgangen wird (zum Beispiel durch die explizite Verwendung von plattform-spezifischen Komponenten (in CP durch IMPORT SYSTEM eindeutig gekennzeichnet)) sollte nicht verallgemeinert werden. --Bautsch 09:33, 18. Dez. 2006 (CET)

Also das ist so: Wegen der semi-Entscheidbarkeit des Halteproblems kann kein noch so toller "garbage collector" sagen, ob bestimmt Code-Bereiche noch erreicht werden können, so dass man im Falle von "toten Code-Bereichen" einen Spezialfall des Speicherlecks hätte... Daher kann man also auch bei "automatischer Speicherbereinigung" Speicherlecks haben, allerdings jedoch ohne dass die "automatische Speicherbereinigung" selbst solche verursacht (vielmehr ist es der Software Designer, der für sein Projekt gammelige Algorithmen ausgesucht hat -- respektive der Programmierer, der die dann falsch eingetippt hat)... --Heimschützenverein 14:16, 6. Feb. 2008 (CET)

Mal ein typisches Beispiel: Ein Stapel (Kellerspeicher) wird durch ein Feld und die Anzahl der verwendeten Elemente implementiert. Nun betrachten wir einen Stapel von Zeigern. Diese werden alle von der automatischen Speicherbereinigung untersucht. Bei einem 'pop' würde es etwa in C völlig reichen, den Wert für die Anzahl der verwendeten Elemente um eins zu verringern. Bei automatischer Speicherbereinigung würde das nicht reichen, da müsste man noch des entfernte Element auf NIL setzen, andernfalls denkt das Laufzeitsystem, dass des referenzierte Objekt noch benötigt wird. DrLemming 22:55, 23. Jun. 2008 (CEST)

hmm... ja... da könnte man noch sagen, dass das lebensende des "feldes" auch reicht... außerdem verwendet man dann ja eh eher n vector und muss sich über das NIL keine gedanken machen... wichtiger sind die fälle, in denen zwar das pop-en im quellcode steht, aber nie ausgeführt werden kann, weil es wegen eines programmfehlers (etwa endlosschleife) unerreichbar ist... --Heimschützenverein 23:24, 23. Jun. 2008 (CEST)

Anglizismus

ich muss ja doch sagen, dass ich ein wenig überrascht war, diese doch nicht so ganz unbekannte technik unter einem artikelnamen zu finden, den ich so noch nie gehört oder gelesen habe. ich denke doch, dass Garbage Collection der gebräuchlichere name ist und daher auch der artikelname sein sollte. vielmehr überrascht mich allerdings, dass diese diskussion hier noch nicht geführt wird. ist die deutsche bezeichnung doch gebräuchlich und lese ich einfach nur die falschen bücher?

ich hab mal versucht, die verbreitung der begriffe per google zu testen, doch leider gibt es auch bei der einschränkung auf deutschsprachige seiten in der .de-domain vereinzelte englische treffer. dennoch denke ich, dass 500 zu 28.000 recht eindeutig sein sollte: Google:Automatische Speicherbereinigung site:.de Google:Garbage Collection site:.de

auch in den wikipedia-artikeln scheint die englische variante weitaus verbreiteter zu sein: Wikipedia:Whatlinkshere/Automatische_Speicherbereinigung --plasmagunman 6. Jul 2005 18:04 (CEST)

"Automatische Speicherbereinigung" ist keine neue Wortschöpfung, sondern der gängige deutschsprachige Fachausdruck. Es geht auch nicht nach Häufigkeit, denn Wikipedia ist kein Wörterbuch. Oder soll auch der Artikel Automobil in Auto umbenannt werden?
Wikipedia ist auch kein Expertenforum. Vielmehr sollen Zusammenhänge für Laien möglichst verständlich dargestellt werden. Ich glaube nicht, dass Wikipedia verständlicher wird, indem wir den Artikel in Garbage-Collection umtaufen, im Gegenteil. --62.225.112.68 13:53, 24. Jul 2005 (CEST)

Zustimmung. Der deutsche Begriff sollte beinehalten werden. Stern 14:09, 29. Nov 2005 (CET)

+1 für "Automatische Speicherbereinigung". Darunter kann sich jeder sofort etwas vorstellen, unter Garbage collection hingegen nicht. Offenbar hat uns aber bereits jemand vor vollendete Tatsachen gestellt. DrLemming 22:49, 23. Jun. 2008 (CEST)

mal was ganz anderes, was aber entfernt auch was mit dem thema zu tun hat: ich verstehe google nicht mehr. wieso liefert eine suche nach "automatische Speicherbereinigung" weniger(!) hits als eine suche nach "automatische Speicherbereinigung" -wikipedia? --seth 22:04, 29. Nov 2005 (CET)

war vermutlich ein bug; evtl. war der schaetz-algorithmus buggy. das trat frueher haeufiger auf; mittlerweile zumindest bei mir gar nicht mehr. -- seth 14:18, 6. Okt. 2007 (CEST)

Konservative Speicherbereinigung

Der Abschnitt beschreibt die Situation beim Boehm-Kollektor, das ist aber nicht auf alle konservativen Kollektoren zu verallgemeinern. -- ZZ 13:52, 11. Mai 2007 (CEST)

Fehlerhaftes?

"Untersuchungen haben gezeigt, dass nacheinander erzeugte Objekte oft gleichzeitig für eine bestimmte Operation gebraucht werden. Wenn sie nicht nahe genug beieinander liegen, werden Zugriffe anstatt auf den schnellen Cache-Speicher auf den dahinterliegenden, langsameren Speicher umgeleitet, was den Zugriff stark bremsen kann."

Hoppla, da hat jemand die Funktionsweise eines Caches nicht richtig verstanden... Entscheidend ist in Zusammenhang mit Caches nicht ob zwei in verschiedenen Belegungen reservieren Speicherblöcke (z.B. für Objekte) hintereinanderliegen, sondern das die Datenausrichtung korrekt ist. Wenn mir ein malloc () für eine 6 Byte große Datenstruktur auf einem Intel Rechner als Adresse die 8000 liefert, erwarte ich als nächste Adresse nicht die 8006, sondern die 8008 (Speicherverwaltungsstrukturen mal nicht berücksichtigt) Eine Cacheline enhält z.B. bei meinem Prozessor 8 Byte und ist dementsprechend ausgerichtet. Bei einem Zugriff auf die Adresse 8006 wird von 8000 bis 8007 in den Cache geladen. Würde eine Datenstruktur mit 6 Byte bei 8006 beginnen, so wäre sie auf zwei Cachelines verteilt - und das ist ungünstig....denn das Datum müsste auch in zwei Buszyklen gelesen und geschrieben werden. --PF20070205 --(nicht signierter Beitrag von 193.109.238.110 (Diskussion) 12:09, 6. Feb. 2008 (UTC))

Hmm... "alignment" ist wichtig... "prefetch-en" aber auch... Ist also beides richtig, wobei das erstere (das mit dem "nahe beieinander) gerade bei Festplatten-Caches (da geht es derzeit noch zumeist gleich um 512B und zukünftig wohl noch deutlich mehr; aber auch bei Hauptspeicher macht es sinn, gleich 64B oder gleich 64KB in den Cache zu holen (z. B. bei dem Erstellen einer Kopie eines Speicherbereiches; prefetchnta is dann auch n SSE befehl; noch n stichwort: SIMD)...) für den Artikel von hinreichender Relevanz ist, während "alignment" hier eher nicht so relevant ist... --Heimschützenverein 13:56, 6. Feb. 2008 (CET)

user:MrBurns / defrag

Diese Änderung scheint mir nach wie vor falsch zu sein... sprachlich ist sie auch ziemlich falsch... wegen WP:WAR darf ich aber wohl nicht nochmal... --Heimschützenverein 16:14, 29. Feb. 2008 (CET)

Die aktuelle Version schaut aber schon anders aus. Ich glaub auch nicht, dass meine ursprünglich Aussage falsch ist, aber schwer zu belegen, deshalb hab ichs jetzt aufs belegbare reduziert. Und Sprachlich hab ich keinen Fehler gefunden. Stilistisch könnte man s vielleicht schöner formulieren. --MrBurns 16:33, 29. Feb. 2008 (CET)

ist immernoch falsch, weil defragmentierung ja gerade ein feature der automatischen Speicherbereinigung ist, die ja gerade nicht dermaßen den ablauf stört... außerdem geht es ja gerade um den fall ohne jegliche automatische Speicherbereinigung... --Heimschützenverein 16:55, 29. Feb. 2008 (CET)

"Dritte Meinung": An dem letzten Absatz gibt es an sich nicht mehr viel auszusetzen. Allerdings sollte eher darauf hingewiesen werden, dass diese Defragmentierung über die Festplatte geht und Varianten ohne Festplatte und kleinschrittigeren Arbeiten ohne Aussetzer arbeiten können (gibt es sowas implementiert?). Der letzte Punkt in diesem Absatz wirkt übrigens auch merkwürdig (evtl ganz falsch). Trublu ?! 17:12, 29. Feb. 2008 (CET)

sowas gibt es nich ma als ansatz, glaub ich... wozu das mit der festplatte zu tun haben soll, versteh ich nich... sieht nach WP:OR aus... --Heimschützenverein 17:31, 29. Feb. 2008 (CET)

Hmm, sollte ich das mal implementieren, vielleicht ist das ja wirklich neu. Oder sowas einfach nicht benötigt. Wird denn überhaupt RAM-Defragmentierung praktiziert bzw. gibt es Untersuchungen, die aussagen, dass RAM-Defragmentierung einen Effekt bringen kann? Trublu ?! 17:35, 29. Feb. 2008 (CET)

lies ma den artikel erstma... das defragmentieren ist na klar eine wesentliche aufgabe der automatischen Speicherbereinigung... --Heimschützenverein 18:01, 29. Feb. 2008 (CET)

Dann sollte das auch im Artikel stehen, bisher taucht Defragmentierung nur zweimal auf, einmal davon im kritisierten Bereich. Und mein Ansatz steht da sogar auch beschrieben, scheint also schon längst gängig zu sein. Trublu ?! 18:52, 29. Feb. 2008 (CET)

was meinst du mit "mein Ansatz"? lies ma "Mark-and-Compact-Algorithmus"... "defragmentieren" ist nur ein anderes wort für "Compact"ifizieren... man muss eben etwas mitdenken... --Heimschützenverein 19:03, 29. Feb. 2008 (CET)

Das ist ja die von mir angesprochene Stelle. Dafür dass es eine wesentliche Aufgabe ist, ist das zu wenig. Mit "mein Ansatz" meine ich "[...]Varianten ohne Festplatte und kleinschrittigeren Arbeiten ohne Aussetzer arbeiten können[...]", welches mit "sowas gibt es nich ma als ansatz" quittiert wurde. Trublu ?! 19:28, 29. Feb. 2008 (CET)

Das "sowas gibt es nich ma als ansatz" bezog sich na klar auf Dein "Allerdings sollte eher darauf hingewiesen werden, dass diese Defragmentierung über die Festplatte geht"... es geht hier nicht darum, nochmehr sachen reinzuschreiben, sondern darum diesen Humbug von user:MrBurns rauszuwerfen... --Heimschützenverein 20:20, 29. Feb. 2008 (CET)

user:Sebastian.Dietrich's änderungen

• hier sehe ich nicht so recht, dass es offenbar ist, dass ein programm schneller abläuft, weil seine speicherverwaltung zum teil in idle zeiten erledigt wird... das trifft wohl mehr nur für micro benchmarks zu, aber nicht für reale anwendungen... es wird also eine quelle gemäß WP:Q gebraucht...
• hier verstehe ich nicht, wie man das bilden eines speicherlecks nicht als "versagen" verstehen kann... ein speicherleck ist ja ein schwerer fehler in der speicherverwaltung... nur doppelte vergabe ist schlimmer... :-)
• hier soll offenbar betont werden, dass "manuelle" freigabe irgendwie auch nich das gelbe vom ei ist... _aber_ gemeint war vorher: wenn einer den _bestehenden_ "garbage collector" umgeht oder sonstwie verhunzt, kann es wiederum _trotz_ Garbage Collection zu fehlern kommen, was ohne quelle leicht ersichtlich ist... vllt sollte man den satz auch ganz weglassen, weil so jmd eh selbst schuld ist...

machst du das bitte wieder rückgängig, damit ich nicht das ganze feuerwerk (quellenwarnung, dritte meinung, etc. pp.) abbrennen muss...? --Heimschützenzentrum (?) 22:45, 22. Okt. 2009 (CEST)

Hi - das mit Quellenwarnung & dritter Meinung meinst wohl nicht ernsthaft - in dem ganzen Artikel sind null Quellen angegeben, auch nicht in den Änderungszusammenfassungen - dann müsstest Du schon den ganzen Artikel löschen, was keiner von uns will...

Aber nun zu Deinen Punkten:

• Dass GCs in idle Zeiten Speicher freigeben können betrifft real-life Programme wesentlich mehr als Micro-Benchmarks. Letztere stressen ja meist das System 100%, da gibt es keine Idle Zeiten. In RL Apps - zumindest in denen wo die CPU nicht ständig auf Vollast läuft, passiert es schon recht oft (z.B. wenn gerade die DB werkt), dass der GC zu Idle Zeiten Speicher freigibt. Erst unlängst hab ich wieder einen Vortrag gehört, wo ein Sun HotSpot Entwickler auf diesen entscheidenden Performance-Vorteil (neben der möglichen Defragmentierung, wenn der GC das kann) von GCs hingewiesen hat.
• Ein Speicherleck wäre ein dramatischer Bug eines GCs, wenn er Speicher, der nicht mehr referenziert wird nicht freigeben kann. Ein GC darf Speicher, der noch referenziert wird (aber vielleicht nie mehr gebraucht wird) gar nicht freigeben. D.h. das was als "versagen" beschrieben wurde ist "as designed". Ein "Speicherleck" bei Programmiersprachen mit GC ist kein "Versagen" des GC, sondern der Entwickler - also ein Bug im Code und nicht im GC. Ich würde also vorschlagen den Satz noch weiter abzuschwächen in: "Automatische Speicherbereinigung kann - als Folge des Satzes von Rice - Speicherlecks nicht verhindern, da nicht festgestellt werden kann, ob gewisse noch referenzierte Objekte jemals wieder benutzt werden."
• Hab schon verstanden was vorher gemeint war. Der Artikel beschreibt aber GarbageCollection und nicht, was passiert wenn man bei systemnaher Programmierung Bugs einbaut. Dasselbe gilt ja auch für nicht-systemnahe Programmierung oder bei Sprachen die keine VirtualMachine kennen. Darum hab ich den Satz verallgemeinert - mMn sollte er, wie Du auch vorgeschlagen hast, ganz rausgenommen werden.

Ich hoffe wir können es schaffen auch ohne Feuerwerk auf eine gemeinsame Lösung zu kommen...

--Sebastian.Dietrich 00:02, 23. Okt. 2009 (CEST)

doch... :-) wenn der artikel schlecht ist, muss er ja nicht schlechter werden...

• mit microbenchmarks meinte ich solche, die eben niemals garbage collection brauchen, weil sie zu kurz laufen, so dass man in wirklichkeit nur den aufwand für allokation misst... wie es nun wirklich ist, weiß ich nicht... ob man irgendwelche gurkigen DB benchmarks oder werbe-aussagen in vorträgen verallgemeinern kann, bezweifel ich... z b in einer unix umgebung, die viele programme aufruft, die nur kurz laufen, fällt die speicherverwaltung vllt gar nicht ins gewicht...
• nochmal das bsp von der speicherleck disk seite: eine schleifenbedingung, die nicht erfüllt werden kann, ist nicht immer trivial als solche zu erkennen... die speicherverwaltung versagt da also genauso wie bei manueller freigabe... dass der programmierer/entwickler an allem schuld ist, ist eh klar, aber das von ihm ausgewählte werkzeug (garbage coll.) versagt eben...
• ok - das neue bitte auch, weil sich da leicht ein gegenbeispiel konstruieren lässt...

dange... --Heimschützenzentrum (?) 02:10, 23. Okt. 2009 (CEST)

• das war keine Werbeaussage - sondern die eines Entwicklers. Ich spreche auch nicht von gurkigen DB Benchmarks oder kurz laufenden Unix Mini-Apps, sondern von kleinen bis grossn Business Applikationen, die 24x7 laufen. Beispielsweise musste ich mal Performancetuning für eine ziemlich grosse Flughafen-App machen (übrigens Unix). Hier konnte ich deutlich sehen, dass während der DB oder Message-Bus Requests, wo der App-Server idle war, der GC munter Speicher freigegeben hat. Ich wills auch gar nicht verallgemeinern - darum steht ja auch "kann Programme beschleunigen".
• beim zweiten Punkt verstehe ich Dich nicht ganz. Du sagst ja selbst auf der Disk: "ohne dass die "automatische Speicherbereinigung" selbst solche verursacht" - das widerspricht doch "kann die automatische Speicherbereinigung zu Speicherlecks führen". Das Werkzeug GC verspricht ja nur "nicht mehr referenzierte Objekte" zu löschen und nicht "nicht mehr benötigte Objekte zu löschen" - somit "führt" es nicht zu Speicherlecks, sonder kann sie nur einfach nicht verhindern.
• letzteres hab ich jetzt ausgebessert - bitte schau nach obs so auch Dir passt...

lg --Sebastian.Dietrich 09:57, 23. Okt. 2009 (CEST)

P.S: Möchte die Diskussion gerne auf die Disk-Seite von GC verschieben wenn Du einverstanden bist. Denke hier kommt was raus, das für andere auch interessant sein könnte...

• eines speziell ausgewählten entwicklers... :-) "kann Programme beschleunigen" ist ja gar nicht eingeschränkt... im allgemeinen gilt eben nicht, dass GC beschleunigen/funktionieren kann... nebenbei: dieses "muntere" speicher-freigeben fällt ja bei GC viel mehr auf, als wenn man einfach nur in einem bitfeld eine "1" einträgt... beim allozieren muss man dann eben eine "0" finden, was ich mir immernoch leichter als drei-farben-trallala vorstelle... :-)
• die heutige automatische Speicherbereinigung kann zu Speicherlecks führen, ohne sie selbst zu verursachen... dies liegt eben daran, dass die automatische Speicherbereinigung dem anspruch _unnötige_speicheransprüche_ zu verhindern nicht gerecht wird... mit "selbst verursachen" meine ich na klar, dass der GC nicht selbst dermaßen fehlerhaft ist, dass er ein speicherleck hat...
• oki

--Heimschützenzentrum (?) 10:49, 23. Okt. 2009 (CEST)

• Sorry - die eines Entwicklers der Java Virtual Machine - d.h. nicht ein x-beliebiger, sondern einer der sich mit der Materie täglich beschäftigt & von SUN ausgewählt wird auf Konferenzen darüber auch zu sprechen. - aber klar: Garbage Collection braucht länger um Speicher freizugeben als ein simples free()/delete() (auch wenn auch dort mehr als 0/1 gemacht wird). Aber noch schneller ist halt gar nix zu machen - und das passiert eben bei GC zunächst. Somit beschleunigt GC rechenintensive Programmteile & verwendet (mehr) CPU in CPU-schwachen Teilen. Typische Businessapps warten einen Großteil ihrer Zeit auf Benutzereingaben und DB- bzw. andere synchrone Antworten. Hier bringt das spätere Freigeben meist einiges an Gesamtperformance. Wennst willst können wir aber auch _zusätzlich_ in etwar folgendes schreiben "GC kann Programme auch verlangsamen, da Speicherfreigabe via GC aufwändiger ist als ohne GC".
• Woher hast Du das mit dem Anspruch, dass GC _unnötige_speicheransprüche_ verhindern soll. Das ist mir neu. Wenn das so wäre, dann hat GC versagt, da ich immer noch sinnloserweise GB an Daten erzeugen kann ohne sie zu nutzen (z.B. für einen Cache). Ich glaube aber nicht, dass das jemals ein Anspruch bzw. eine Aussage von GC gewesen wäre. "Kann zu Speicherlecks führen" heisst für mich, dass der Einsatz von GC zu leaks führt, welche ohne GC nicht auftreten würden. Darum stimmt der Satz einfach nicht & sollte wie gesagt in "kann Speicherlecks nicht verhindern" umgewandelt werden. Was hältst Du davon?

--Sebastian.Dietrich 12:05, 23. Okt. 2009 (CEST)

• also für das "meist einiges" bräuchten wir dringend eine quelle... auch das mit der verlagerung in idle zeiten leuchtet mir nicht ein...
• das steht ganz oben in der einleitung... die grenze zwischen schlechter algorithmus und speicherleck sind wohl fließend... "im allgemeinen Fall durch Bildung eines Speicherlecks versagen" passt also doch gut...

--Heimschützenzentrum (?) 13:57, 23. Okt. 2009 (CEST)

• Ich fürchte dafür werden sich keine Paper finden lassen - vermutlich weils für die meisten unter "eh klar" fällt. Wenn man sich die GC Zeiten ansieht und parallel dazu die Systemlast kann man ja deutlich sehen, dass der GC auch dann läuft, wenn die Applikation sonst idle ist. Sag mir doch bitte was Dir hier nicht einleuchtet. Für mich ist das so sonnenklar, dass ich vielleicht die entscheidende Lücke in meiner Denkweise gar nicht erkenne.
• Ja sehe ich - in der Einleitung steht "... Wiederverfügbarmachung von nicht mehr benötigtem Speicher ..." - das ist nicht korrekt und sollte auf "... Wiederverfügbarmachung von nicht mehr refrenziertem/verwendetem Speicher ..." verbessert werden. In der englischen WP stehts mMn besser - "reclaim garbage, or memory occupied by objects that are no longer in use by the program". So wie es jetzt drinnen steht kann man herauslesen dass es ja eigentlich die Aufgabe der GC wäre auch noch referenzierten Speicher (der aber aus irgenwelchen Gründen nicht mehr benötigt wird) wegzuräumen. Das scheint auch Deine Interpretation von GC zu sein oder? So als ob die Müllabfuhr all die Dinge mitnehmen sollte, die ich nicht mehr brauche, und nicht nur die Dinge, die ich in die Mülltonne schmeisse ;-) Wär vielleicht eine nette Dienstleistung - aber wie Du schreibst lt. Satz von Rice nicht wirklich umsetzbar. Die Müllabfuhr & unsere Hirne sind ja auch nur Turingmaschinen...

--Sebastian.Dietrich 21:00, 25. Okt. 2009 (CET)

• da traditionelle speicherverwaltung (malloc/free) ja insgesamt weniger aufwand hat, ist mir nicht klar wie nun GC ein programm beschleunigen könnte... man kann höchstens froh sein, wenn es nicht noch lahmer wird... das einzige was mich etwas zuversichtlich stimmt, ist die kompaktifizierung/defragmentierung des speichers...
• nö - wieso so spezialisiert? nur weil 's (noch) nich geht? :-) am anfang konnte GC auch gewisse zykel nicht als "vom wurzelknoten ausgehend unreferenziert" erkennen... --Heimschützenzentrum (?) 22:19, 25. Okt. 2009 (CET)

Sorry - aber inzwischen hege ich die Befürchtung, dass Du mich nicht verstehen möchtest. Du bleibst mir die Antworten schuldig & willst anscheinend den Artikel in Stein meisseln. Die Fragen waren: 1) Was ist daran unverständlich, dass Programme schneller laufen, wenn sie es schaffen Rechenleistung in Idle Zeiten zu verschieben? und 2) Ist es Deine Interpretation von GC, dass diese alle nicht mehr benötigten aber noch referenzierten Objekte freigeben können muss?

1) ist für mich sonnenklar und benötigt keine Referenzen um im Artikel drinnenbleiben zu können - Defragmentierung arbeitet ja auch nach demselben Prinzip und 2) ist diese Interpretation sicherlich falsch --> GarbageCollection muss nur nicht mehr referenzierte Objekte freigeben können & das tut sie auch (wenn sie nicht buggy ist) - d.h. der Satz von Rice ist hier an der falschen Stelle und GC kann nicht zu Speicherlecks führen (wenn dann nur psychologisch, weil man sich darauf verlässt - dann führt aber auch schönes Wetter zu Speicherlecks).

--Sebastian.Dietrich 02:02, 26. Okt. 2009 (CET)

1. wenn zusätzliche Rechenleistung in idle zeiten verschoben wird, ergibt sich ja nicht notwendig eine beschleunigung, so dass der hinweis auf die verschiebung eine unnütze verlängerung (und somit eine verschlechterung) ist... defragmentierung wäre möglicherweise ein grund für eine beschleunigung, nämlich wenn sekundärer speicher nicht benutzt werden muss, aber das hat ja nichts mit der "verschiebung in Idle Zeiten" zu tun...
2. "nicht verwendetem Speicher" und "nicht benötigtem Speicher" dürfte hier wohl bedeutungsgleich sein, so dass ich den einwand für falsch halte... --Heimschützenzentrum (?) 07:34, 26. Okt. 2009 (CET)

• Wenn ich in C++ einige der delete() dann aufrufen könnte, wenn der Prozessor Idle ist, wär C++ schneller. Es ist nicht nur zusätzliche Rechenleistung, die in Idle Zeiten verschoben wird, sondern auch ohnedies anfallende.
• "nicht mehr referenziertem Speicher" wäre der Vorschlag. Aber die Frage hast immer noch nicht beantwortet. Ich vermute Du denkst eh nicht, dass es die Aufgabe von GC wäre referenzierten aber nicht mehr benötigten Speicher freizugeben. Habe somit den Absatz mit "kann zu Speicherlecks führen" in "kann Speicherlecks nicht verhindern" ausgebessert.

Übrigens gibt es zu insgesamten Performance von GC ein paar Referenzen die darauf hinweisen dass GC gleich schnell, wenn nicht schneller als händisches delete() sind

• en:wikipedia behauptet (mit referenzen), dass das Anlegen/Löschen von Objekten in Java deutlich schneller sei als in C/C++ (siehe en:Java_performance#Program_speed.
• in "Benjamin Zorn, The Measured Cost of Conservative Garbage Collection Software - Practice and Experience 23(7): 733-756, 1992." wird behauptet, dass bei der Einführung von GC die Performance gleich bleibt bzw. sogar steigt - siehe [2].
• auch in einem recht alten c't (2003) gabs was darüber - GCs sind inzwischen auch noch rascher geworden, malloc/free/delete aber nicht.

Hab die Referenzen eingebaut. --Sebastian.Dietrich 11:56, 26. Okt. 2009 (CET)

WP:DM: Ich sehe hier eine sehr gesittete und sachliche Fach-Diskussion, weshalb aus meiner Sicht eigentlich eine DM noch nicht nötig ist. Aber vielleicht kann ich trotzdem mit meiner Informatiker-Fachmeinung weiterhelfen.

1. Das Argument, dass GC auch beschleunigen kann, ist plausibel. Das erkauft man sich mit dem grundsätzlichen Problem der GC, nämlich dass die Menge benutzer Speicher bei GC immer >= manuelle Speicherverwaltung ist (sofern das Programm frei von Memleaks ist). Quelle wäre trotzdem nicht schlecht.
2. Ich würde in der aktuellen Version die ersten zwei Absätze ans Ende des Abschnitts schieben, denn die sind aus meiner Sicht von geringerer Bedeutung als die Tatsache, dass Programmierfehler ganz verhindert werden können. Daher damit starten (und auch nur wirklich das "ganz verhindert werden" erwähnen, also die Speicherlecks dort streichen), dann Performance-Erwägungen, und dann Speicherlecks und Beschleunigung. -- Jan Rieke 17:46, 26. Okt. 2009 (CET)

WP:3M: Für mich ist das Argument mit der Beschleunigung nachvollziehbar und scheint jetzt auch bequellt (die Quellen habe ich nicht nachgeprüft). Es stimmt zwar schon, dass es sich dabei eigentlich nur um eine Verschiebung der Aufräumarbeiten auf später handelt. Wenn dadurch ein Programm mit GC aber schneller läuft, wenn gerade viel Betrieb herrscht oder sich ein Programm in einer kritischen Schleife befindet, und die Aufräumarbeiten erst dann geschehen, wenn wenig los ist, ist das Wort Beschleunigung in meinen Augen treffend, selbst wenn im Summe dafür vielleicht mehr CPU-Cycles benötigt werden. Das trifft sicher nicht für alle Anwendungsfälle zu, aber das behauptet die aktuelle Artikelversion auch nicht. lg, --Nikolei21 ^tratsch 18:35, 26. Okt. 2009 (CET)

dafür dass da nicht äpfel und birnen verglichen wurden, sehe ich keinen nachweis... ich könnte mir auch eine GC implementation vorstellen, die andauernd fast alles zum stillstand bringt... man müsste also eine effiziente manuelle speicherverwaltung mit einem effizienten GC vergleichen und da kann ich mir nicht vorstellen, wie die ganzen listen/vektoren des GC schneller sein könnten als die bitfelder von malloc/free... und wenn dann noch der speicherhunger des GC größer ist, hinkt der vgl immer mehr... also: wenigstens der offensichtlich fanatisch geschönte satz mit "in summe" muss raus... der rest sollte auch stärker relativiert werden... --Heimschützenzentrum (?) 11:42, 1. Nov. 2009 (CET)

Ich hab jetzt mal gemäß Vorschlag von Jan die Absätze umgestellt. Halte ich auch besser so, da es die für den Leser wichtigeren Punkte an den Beginn stellt.

Den Satz mit "in Summe" habe ich abgeschwächt hinsichtlich "es gibt Benchmarks" (d.h. es könnte natürlich auch Benchmark-Veröffentlichungen geben, die was anderes zeigen - wenn Du so eine findest, kannst Du das natürlich relativieren) und "schneller" statt "wesentlich schneller", weil "wesentlich" ist natürlich relativ - auch wenn dieses Wort in den Artikeln steht.

Ich hoffe wir haben damit einen Kompromiss gefunden, der jetzt auch auf Grund der Referenzen den Artikel insgesamt deutlich verbessert hat.

lg Sebastian.Dietrich 12:29, 1. Nov. 2009 (CET)

regelmäßig / automatisch

Zum Passus in der Einleitung "... Verfahren zur regelmäßigen automatischen Wiederverfügbarmachung ...":

"regelmäßig": Wiktionary "regelmäßig": "Etwas in festen Abständen wiederholen."

Dies kann bei der "Garbage Colletion" der Fall sein, ist aber nicht notwendigerweise der Fall. Ein Programmierer von Echtzeitsystemen wäre zum Beispiel schlecht beraten, die Speicherbereinigung in festen Abständen wiederholen zu lassen. Das ist schlichtweg eine falsche Aussage und zudem irreführend. Meiner Meinung muss "regelmäßig" an dieser Stelle definitiv entfernt werden. Ich kenne auch Laufzeitsysteme, bei denen die Garbage Collection ganz und gar nicht in festen Abständen durchgeführt wird, sondern bei Bedarf, wenn zum Beispiel eine gewisse Speichermenge überschritten ist oder ein bestimmte Benutzerhandlung durchgeführt wird (beispielsweise "Fenster schließen").

"automatisch": Wiktionary "automatisch"; "... ohne Dazwischentreten einer Entscheidung und ohne weiteres Zutun zu erfordern."

Dies gilt sicherlich in Hinsicht auf die Garbage Collection selbst (genauso wie der Aufruf jedes anderen Programmes ohne weitere Benutzerinteraktion), nicht jedoch auf den Aufruf derselben. Aus denselben Gründen wie weiter oben angegeben, ist es bei bestimmten Anwendungen (zum Beispiel Echtzeitsysteme) nicht gewünscht, dass diese Routine automatisch aufgerufen wird, sondern es wird unabhängig vom Garbage Collector entschieden, wann dieser ausgeführt wird - das kann auch manuell vom Benutzer selbst geschehen. In diesem Sinne kann man aber den von mir kritisierten Passus mit "automatisch" missverstehen, und daher sehe ich auch hier Verbesserungsbedarf.

Möglicherweise gibt es Kritikpunkte an meinem Vorschlag, aber ich kann nicht nachvollziehen, warum mein Vorschlag keine Verbesserung darstellen soll, wie von Benutzer:Homer Landskirty ohne Angabe von Gründen behauptet wird.

Warum sollen wir uns in der Einleitung schon auf falsche beziehungsweise irreführende Aussagen festlegen ? Ich habe beide Adjektive zur Korrektur und definitiven Verbesserung der Einleitung entfernt - so ist es sogar kürzer und dennoch völlig korrekt und vor allem nicht missverständlich.

Vor weiteren Änderungen bitte ich um eine qualifizierte Diskussion an dieser Stelle. Membeth 18:40, 25. Okt. 2009 (CET)

1. WP:Q: WP ist keine Quelle für WP... Dies gilt sicherlich auch für Wiktionary...
2. regelmäßig: Es passen eben je nach Spezialfall verschiedene Bedeutungen des Wortes... insbesondere "wiederholt"... Was das nun im Spezialfall heißen mag, kommt dann ja weiter unten...
3. automatisch: die _Wiederverfügbarmachung_ selbst erfolgt _automatisch_, was allseits wohl nicht bestritten wird... Es ist insbesondere keine vorherige Maßnahme/Planung seitens des Programmierers erforderlich, weil eben der theoretisch mögliche "früheste Zeitpunkt zur Freigabe" niemals unterschritten werden kann...
4. Beide Wörter liefern wichtige Informationen für den Leser: Das Verfahren wird also nicht erst ganz am Ende des Prozesses mit der Freigabe der Betriebsmittel angewendet und es entlastet den Programmierer...

Das hielt ich für dermaßen trivial, dass ich eine Diskussion für überflüssig hielt... Eine Verschlechterung des Artikels durchzuführen, um die dann zu diskutieren, ist wohl auch kaum im Sinne der WP... --Heimschützenzentrum (?) 19:23, 25. Okt. 2009 (CET)

Es scheint, dass wir aneinander vorbei diskutieren: Ein Garbage Collector muss (vom wem auch immer) weder notwendigerweise wiederholt aufgerufen werden, noch ist notwendigerweise keine Planung des Programmierers erforderlich, wie ich oben bereits mit der Nennung von praktischen Beispielen beschrieben habe. Deshalb sollten wir das auch nicht allgemein behaupten, und schon gar nicht in der Einleitung, sondern bestenfalls, dass dies bei bestimmten oder meinetwegen vielen Systemen so gehandhabt wird. Membeth 00:06, 26. Okt. 2009 (CET)

ein GC, der nur einmal (also nicht wiederholt) aufgerufen wird, ist ein so merkwürdiger spezialfall, dass man ihn nicht in der einleitung erwähnen muss, find' ich... normal ist jedenfalls die immer wiederkehrende "müllabfuhr", die dann automatisch "den müll" findet und entsorgt... --Heimschützenzentrum (?) 07:27, 26. Okt. 2009 (CET)

Im Artikel Müllabfuhr steht auch nichts davon, dass diese regelmäßig kommt; sie kommt auch nicht automatisch, sondern nur auf Bestellung. Außerdem: Warum sind häufig auftretende und ganz alltägliche Spezialfälle merkwürdig ? Nur weil sie nicht in ein bestimmtes Teilschema passen ? Nur einige willkürliche Beispiele:

• Prototype SMM Application Instantiation insbesondere "Note that the Jbed run-time system ..."
• Adaptive Optimization of the Sun Java Real-Time System Garbage Collector
• A real-time garbage collector with low overhead and consistent utilization
• Real-time garbage collection for flash-memory storage systems of real-time embedded systems

Für mich ist da nichts merkwürdig oder ungewöhnlich. Membeth 17:01, 26. Okt. 2009 (CET)

WP:DM: ad regelmäßig: Auch wenn es ein seltener Spezialfall sein mag, sollte die Einleitung trotzdem korrekt sein und nicht einfach diesen Spezialfall ausschließen. Man könnte z.B. eine abgeschwächte Formulierung wie "üblicherweise regelmäßig" verwenden. Streichen wäre auch ok, da mMn die Regelmäßigkeit keine entscheidende Charakteristik der GC ist. ad automatisch: Selbstverständlich ist eine GC automatisch, denn wenn man von GC spricht, dann ist natürlich nur das Verfahren gemeint und nicht, wie es aufgerufen wird. Wenn ich z.B. sage "Dieses Programm kann automatisch die Festplatte defragmentieren", dann würde ja auch keiner auf die Idee kommen, das "automatisch" in Frage zu stellen, nur weil ich vorher manuell das Programm starten muss. Das automatisch bezieht sich auf den Ablauf des Programms/der Methode. -- Jan Rieke 17:24, 26. Okt. 2009 (CET)

Gibt es auch Programme, die eine Festplatte nicht automatisch defragmentieren ? Ich habe zumindest noch keines gesehen, was aber nichts heißen muss. Jedenfalls ist der automatische Ablauf einem jeden Computerprogramm inhärent, denn es ist definiert als "Folge von Anweisungen", die nur während der Softwareentwicklung (oder beim Cracken) - also in besonderen "Spezialfällen" - mit einem Run-Time-Debugger nicht-automatisch abgearbeitet werden.

(Nebenschauplatz: Der Run-Time-Debugger ist für die zeitgemäße Programmierung übrigens ein überflüssiges Werkzeug, das nur scheinbar eine Kontrolle über den Programmablauf erlaubt, was bei Objektzugriff in echten objektorientierten Laufzeitumgebungen, durch parallel laufende Prozesse oder beim präemptiven Multitasking sehr schwierig ist, wenn es dabei überhaupt möglich oder sinnvoll anwendbar ist. C- und Java-Programmierer werden das aber oft nicht völlig nachvollziehen können). Membeth 23:19, 28. Okt. 2009 (CET)

Wenn du unter "Computerprogramm" nur eine Folge von Anweisungen verstehst, dann mag das sein, dass "der automatische Ablauf einem jeden Computerprogramm inhärent" ist. Sicherlich gibt es aber Methoden, Verfahren und Algorithmen, die auf Benutzerinteraktion angewiesen sind. Und auf nichts anderes bezieht sich das Adjektiv "automatisch", nämlich auf die Tatsache, dass die GC ohne Benutzerinteraktion bzw. manuelles Eingreifen des Benutzers auskommt. -- Jan Rieke 17:48, 30. Okt. 2009 (CET)

Ich habe das so verstanden, dass es darum geht, ob eine Interaktion des Programmierers notwendig ist oder nicht, und nicht ob der Benutzer manuell eingreifen soll. Ein vom Programmierer programmierter Dispose-Befehl läuft aus der Sicht des Benutzers Benutzers genauso automatisch ab, wie ein Garbage Colletor oder andere Programme ohne Benutzer-Eingabe. Membeth 19:10, 31. Okt. 2009 (CET)

es geht darum, ob bei der automatischen speicherverwaltung (GC) die "wiederverfügbarmachung" "automatisch" und/oder "regelmäßig" erfolgt... nun ist es bei einer idealen GC so, dass weder das aktiv werden der GC noch die dann folgenden "entscheidungen" der GC von dem programmierer oder sonstwem gesteuert werden muss... die ganzen nicht idealen aber evtl. realen abweichungen vom ideal haben in der einleitung nichts zu suchen... ich schlage also vor, die einleitung wie folgt abzuändern: "Garbage Collection (eigentlich englisch für Müllabfuhr; Abkürzung: GC; Synonyme: Automatische Speicherbereinigung, Freispeichersammlung) bezeichnet in der Softwaretechnik die Minimierung des Speicheranspruches eines Prozesses, die idealer Weise ohne Aufwand während der Software-Entwicklung und während des Prozess-Ablaufs stattfindet." Die ganzen Abweichungen vom Ideal kann man dann ja im Artikel nebst Lösungsmöglichkeit (Satz von Rice (also Unmöglichkeit der Lösung im allg. Fall), (halb-)automatische Verlagerung in Last-arme Zeiten, effiziente Unterbrechbarkeit, ...) anführen... --Heimschützenzentrum (?) 11:32, 1. Nov. 2009 (CET)

Finde ich nicht schlecht, ich würde jedoch Folgendes ergänzen, denn sonst ist es für Leser mit wenig Ahnung kaum zu verstehen: "[...] die Minimierung des Speicheranspruches eines Prozesses durch Freigeben nicht mehr benötigter Objekte , die idealerweise ohne Aufwand während der Software-Entwicklung und während des Prozess-Ablaufs stattfindet." -- Jan Rieke 12:40, 1. Nov. 2009 (CET)

da es GC auch bei nicht rein-objekt-orientierten sprachen gibt (etwa sagt der LISPler vllt gern: "nicht länger benötigter listen"), müsste es korrekt-allgemein lauten "durch Freigeben nicht mehr benötigter Speicherbereiche"... aber dann ist da ja nicht nur die freigabe sondern besonders auch die kompaktifizierung... und dann ist es ja klar, dass es sich nicht etwa um optimierungen der algorithmen zur laufzeit handeln kann (das wäre dann ja minimierung der ansprüche, indem gar nicht erst speicher beansprucht wird, so dass er auch nicht freigegeben/kompaktifiziert werden kann/muss...)... --Heimschützenzentrum (?) 13:35, 1. Nov. 2009 (CET)

Einleitung

Ich halte die neue Einleitung jetzt zwar für korrekter, aber nicht mehr OMA tauglich. Die alte Einleitung war da mMn bei weitem verständlicher... --Sebastian.Dietrich

was genau könnte den durchschnitts-leser (oder was war noch WP:OMA?) am verstehen behindern? der satzbau wohl nicht... „minimierung“ kennt jeder... „prozess“ ist verlinkt... „defrag“ auch... „speicherbereiche“ kann man sich fast schon bildlich vorstellen (wie abteile im speicher unterm dach)... dass zusammenhängende speicherbereiche gewisse vorteile haben, steht dann in dem verlinkten defrag-artikel, falls man es sich nicht wiederum sofort bildlich vorstellen kann... --Heimschützenzentrum (?) 22:53, 1. Nov. 2009 (CET)

Ich denke die Sätze sind zu kompliziert & missverständlich für jemanden der gar nicht weiss was GC ist:

• "bezeichnet im idealen Fall" - und im nicht so idealen Fall?
• "Minimierund des Speicheranspruches eines Prozesses" - also werden die Arrays kleiner?
• "während der Softwarentwicklung" - also braucht meine IDE weniger Ram?
• "ohne Aufwand stattfindet" - d.h. GC braucht keinen CPU Aufwand?
• "Freigabe oder Wiederverwendug bietet sich an" - d.h. das ist nur eine von vielen Möglichkeiten
• "Defragmentierung ist auch ein geeignetes Mittel" - d.h. ein reiner Speicher-Defragmentierer ist ein Garbage Collector?
• "Zeit-Komplexität" - hat das was mit Relativitätstheorie zu tun?
• "Speicher-Komplexität" - was ist das?
• "Abweichungen vom Ideal" - welches Ideal? Dass die Zeit weniger komplex ist?

--Sebastian.Dietrich 23:37, 1. Nov. 2009 (CET)

man muss es eben erstmal wollen (wer tatsächlich glaubt, GC in einem prozess könne rückwirkend die für seine entstehung notwendigen tools optimieren, dürfte wohl mit kaum einer definition etwas anfangen können... und ja: GC ist mMn nicht auf die analyse des referenz-graphen zur laufzeit beschränkt (man kann sich also auch einen (zukünftigen) GC vorstellen, der bereits zur compile-zeit einsetzt...)... und ja: defragmentieren allein ist bereits GC, so ist es auch mit referenzzählung... etc. pp. (bin zu müde jetzt))... und im nicht idealen (=realen) fall erreicht man eben weder das minimum noch eine komplexität = 0... das wird dann eben in den folgenden abschnitten deutlicher... man kann ja nicht in der einleitung schon alles bis ins detail erläutern... --Heimschützenzentrum (?) 23:58, 1. Nov. 2009 (CET)

Es ist wie gesagt sehr vieles missverständlich und komplex formuliert (und nicht nur für OMAs, sondern auch Informatiker) & wohl auch jetzt schon zu viel im Detail angesprochen. Dass Defragmentieren alleine bereits GC Collection ist bezweifle ich übrigens. Ich hätte es begrüßt, wenn die frühere Einleitung nur verbessert worden wäre und nicht vollständig durch eine neue ersetzt worden wäre. Ersteres war ja auch der Vorschlag von Dir (siehe oben).

Die jetzige Einleitung ist so mMn nicht haltbar - auch wenn sie für Dich verständlich klingt, für andere (z.B. mich) klingt sie stark nach Geschrubel. Bitte das nicht als Angriff auf Deine Person deuten, es geht mir nur darum, dass es auch für ein breiteres Publikum verständlich ist. --Sebastian.Dietrich 09:13, 2. Nov. 2009 (CET)

in ermangelung eines anderen begriffes und einer exakten definition fällt das bloße defragmentieren neben einem ansonsten vom programmierer angeordnetem/geplantem free()-aufruf selbstredend in die klasse der GC, weil so schließlich der "müll" (=kleine vereinzelte speicher-stückchen) eingesammelt und nutzbar gemacht wird (gibts nur leider nich, sonst müsste ich mich nich täglich wieder neu einloggen, glaub ich...)... --Heimschützenzentrum (?) 09:38, 2. Nov. 2009 (CET)

Nach vielen Monaten wieder mal ein Anlauf. Ich halte die Einleitung immer noch für untragbar. Die oben genannten Punkte sind leider immer noch in der Einleitung und sind (darüber können wir natürlich streiten) verwirrend und teils falsch und (darüber besteht denke ich Einigkeit) weit von einer einfach verständlichen Definition von GC entfernt. Ich werde also hier in den nächsten Tagen einen Entwurf für eine neue Einleitung reinstellen, die auf der alten (mMn wesentlich leichter lesbaren) und der aktuellen (teilweise exakteren) beruht. --Sebastian.Dietrich ✉ 00:11, 16. Feb. 2011 (CET)

[3] / [4]... könnte es sein, dass du nicht eigentlich an der qualität des artikels interessiert bist? und was sollte jetzt die ankündigung vis-a-vis WP:DS? im übrigen war die alte einleitung unrettbar, weil GC eben nicht allg bei betriebsmitteln benutzt wird und nicht nur nicht erreichbare objekte freigibt (im allg fall schafft sie das auffinden solcher objekte auch nich...)... --Heimschützenzentrum (?) 07:22, 16. Feb. 2011 (CET)

Was willst Du mir damit unterstellen? Selbstverständlich bin ich an der Qualität des Artikels (und im konkretem Fall insbesondere an der Einleitung) interessiert. Du (diese Absicht setze ich mal vorraus) ja auch. Wir haben nur eine unterschiedliche Sichtweise was Satzbau, Korrektheit und tw. auch die Definition von GC anbelangt. Ich bin mir schon bewusst, dass es nicht leicht sein wird mit dir auf einen Nenner zu kommen - u.U. werden wir da und dort eine dritte Meinung benötigen. Ich hoffe aber (und dafür ist auch die Ankündigung gedacht) auf eine insgesamt gute Zusammenarbeit und dass wir uns irgendwie zusammenraufen. --Sebastian.Dietrich ✉ 08:43, 16. Feb. 2011 (CET)

1. es wirkt etwas als ob du unbedingt was anderes als ich willst, ohne diesen willen sachlich begründen zu können... :-) 2. kannst ja hier gerne eine eigene version der einleitung vorschladen... ich sag dann meine inhaltlichen bedenken... 3. satzbau allein reicht nicht für einen edit, wenn die aussage gleich bleibt (sonst könnte ja jeder satz geändert werden...)... --Heimschützenzentrum (?) 11:58, 16. Feb. 2011 (CET)

user:plankton314 / nich-det

Also das geht ja nun wieder gar nicht... erst ist die kombination deterministischer algorithmen plötzlich nicht-deterministisch, weil niemand das programm über irgendetwas informiert... und im nächsten absatz kommt dann „finalize“... also wenn das nich wieder rausfliegt, bin ich hier auch weg... so marketingfantasien zu verbreiten, hat ja keinen sinn... --Heimschützenzentrum (?) 19:09, 30. Nov. 2012 (CET)

Könntest du das bitte konkretisieren? -- Plankton314 (Diskussion) 20:29, 30. Nov. 2012 (CET)

wieso ich? könntest du den nachweis führen, dass n java programm durch den GC nicht-deterministisch ist? oder hast ne qualle gemäß WP:Q? --Heimschützenzentrum (?) 21:09, 30. Nov. 2012 (CET)

Wie ich dir bereits einige Male in der obigen Disku nahegelegt habe, kannst du ja mal einen Blick in die angegebene Literatur werfen.

Sonst gibt es auch hier was zu lesen.

Und wie du weiterhin bestimmt weißt, ist es nicht nötig jede Aussage, die in einem Lehrbuch nachgelesen werden kann, zu belegen. -- Plankton314 (Diskussion) 21:28, 30. Nov. 2012 (CET)

peer review-t? nö... ich glaub nich... wie sollten auch zwei deterministische algorithmen, die einander zuarbeiten, zu einem nicht-deterministischen algorithmus werden? es nervt hier echt, weil ihr offensichtlich nicht daran interessiert seid, die qualität des artikels zu steigern, sondern nur euren komischen, aus irgendwelchen gegoogle-ten internetseiten zusammen„übersetzten“ senf da überall reinschmieren wollt... das kann und darf keinen bestand haben... ---Heimschützenzentrum (?) 21:44, 30. Nov. 2012 (CET)

Warum weigerst du dich hartnäckig, die angegebene Literatur zu lesen - oder einfach nur irgendwas dazu?

Ich sehe keinen Sinn, mit jemandem zu diskutieren, der zwar Quellen fordert, sie dann aber a) nicht liest oder b) ignoriert, weil es ihm nicht passt.

Tut mir leid, aber so macht das keinen Sinn. Ich antworte gern auf jedes fundierte Argument, nicht aber auf diese permanente haltlose Nörgelei. -- Plankton314 (Diskussion) 21:53, 30. Nov. 2012 (CET)

falsch! es gibt keinen sinn aus irgendeinem buch, das wohl kaum peer review-t ist, blindwütig aussagen abzuschreiben, die man offenbar nicht einmal selbst verstanden hat... wie/wo ist denn die exakte textstelle im original? ich les mir doch nich das ganze buch durch... vermutung: vllt meint der werte autor ja gar nicht deterministisch im sinne der informatik, sondern nur sowas wie „unter realen bedingungen vorhersagbar“... --Heimschützenzentrum (?) 22:05, 30. Nov. 2012 (CET)

Bin inhaltlich ausnahmsweise deiner Meinung, aber wo hast du die Überzeugung her, dass eine Info nur aus peer reviewten Informationen stammen darf um in die Wikipedia zu gelangen? --Sebastian.Dietrich ✉ 22:09, 30. Nov. 2012 (CET)

WP:Q WP:Q WP:Q --Heimschützenzentrum (?) 22:14, 30. Nov. 2012 (CET)

Dort steht nichts dergleichen. --Sebastian.Dietrich ✉ 22:20, 30. Nov. 2012 (CET)

Das ist im Grunde schon irgendwo richtig, nur sind das immer die Standardargumente, wenn Leute unbedingt etwas anzweifeln wollen.

Dieses "irgendein Buch" ist das Standardwerk zur Garbage Collection und wurde laut ACM über 300-mal in anderen Werken zitiert. Macht auch keinen weiteren Sinn, Argumente vorzutragen, damit sie ignoriert werden. -- Plankton314 (Diskussion) 22:23, 30. Nov. 2012 (CET)

dann hast es entweder falsch verstanden oder das Standardwerk hat n fehler... zitiert werden ist noch kein peer review (könnte auch die dollste lachnummer sein...)... --Heimschützenzentrum (?) 22:58, 30. Nov. 2012 (CET)

WP:Q: „Wikipedia-Artikel sollen gut gesichertes, etabliertes Wissen enthalten, mit dem Ziel, den aktuellen Kenntnisstand darzustellen. Grundsätzlich sind daher wissenschaftliche Publikationen, insbesondere Standardwerke, begutachtete Veröffentlichungen und systematische Übersichtsarbeiten, die für das Fachgebiet des jeweiligen Lemmas relevant sind, zu bevorzugen.“ == peer review-t --Heimschützenzentrum (?) 22:58, 30. Nov. 2012 (CET)

Peer-Review ist aber was anderes. Es gibt jede Menge Standardwerke, etc. die _nicht_ peer-reviewed sind (auch wenn es immer weniger werden). D.h. nicht das Peer-Review macht erst eine Quelle gültig. --Sebastian.Dietrich ✉ 23:18, 30. Nov. 2012 (CET)

ehm? wenn n haufen hysterischer „informatiker“ jeder „neuerung“ nachläuft, werden die entsprechenden bücher dadurch nicht zu „Standardwerke[n]“... es fehlt hier also das was ich sage: eine überprüfung durch echte experten (und nich durch welche, die n paar tausend euro für ne märchenstunde verlangen, weil die ja nur sagen können, ob es sich gut verkauft...)... --Heimschützenzentrum (?) 07:31, 1. Dez. 2012 (CET)

Was willst damit sagen? "Echte" Experten braucht das Land? Und du bist so einer? Das ich nicht lache. Egal - ich habe belegt, dass deine Aussage zu peer-reviewten Quellen nicht stimmt. EOD. --Sebastian.Dietrich ✉ 08:16, 1. Dez. 2012 (CET)

jedenfalls merk ich's noch, wenn du mir mal wieder eins vom pferd erzählst... das was ihr offenbar als „Standardwerke“ wahrnehmt, sind keine, weil die offensichtlich missverständlich sind oder nicht überprüft sind... --Heimschützenzentrum (?) 08:25, 1. Dez. 2012 (CET)

Zurück zur Änderung: GC ist deterministisch und wenn das Programm selbst auch deterministisch ist, dann ist die Summe aus GC und Programm ebenfalls deterministisch. Wenn du z.B. eine deterministische Java Applikation auf 2 identen Rechnern gleichzeitig startest, dann wird sie nicht wegen des GCs indeterministisch. D.h. der GC kommt auf beiden Rechnern zum selben Zeitpunkt daher und beseitigt denselben Speicher. --Sebastian.Dietrich ✉ 22:51, 30. Nov. 2012 (CET)

+1 :-) --Heimschützenzentrum (?) 22:58, 30. Nov. 2012 (CET)

Was oft mit "nicht-deterministisch" gemeint wird ist das (in der Praxis) unvorhersehbare Zeitverhalten der GC. In der Theorie (d.h. wenn man den Speicher und Prozesszustand exakt kennt) ist aber das gesamte Verhalten der GC deterministisch. --Sebastian.Dietrich ✉ 23:18, 30. Nov. 2012 (CET)

das ist aber missverständlich... also raus mit dem dreck... --Heimschützenzentrum (?) 08:25, 1. Dez. 2012 (CET)

Auch wenn die Beschreibung als "nicht-deterministisch" unter einem akdemischen Blick "etwas zu vereinfachend" sein könnte, bei OMA-Betrachtung wird intuitiv das richtige verstanden, GC Verwendung kann einen reproduzierbaren (Wieder-)ablauf zerstören. Bleibt. Shaddim (Diskussion) 11:46, 1. Dez. 2012 (CET)

solange son quatsch da drinsteht, bin ich hier weg! ich glaub's ja wohl nich! bye! --Heimschützenzentrum (?) 12:04, 1. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:38, 1. Dez. 2012 (CET)

P.S.

Meine persönliche Erkenntnisse aus der Diskussion:

• Determinismus/Indeterminismus ist eine Eigenschaft, die durch die Anforderungen an eine Applikation definiert wird. Ist die Anforderung an eine Applikation "immer auf die nanosekunde gleich lange dauern", dann sind alle Applikationen heutzutage indeterministisch.
• Jede Applikation kann indeterministisch geschrieben werden (eh klar)
• Ist das Zeitverhalten einer Applikation egal (z.B. nicht bei Echtzeitsystemen) und reagiert eine Applikation nicht unterschiedlich auf das Zeitverhalten der GC (z.B. keine später benötigten Systemressoucen im Finalizer freigeben), so wird diese Applikation nicht wegen des GCs indeterministisch --> die meisten Applikationen haben kein Problem mit dem indeterministischen Zeitverhalten von GCs
• Es gibt GCs deren Zeitverhalten genau definiert ist (für Echtzeitsysteme)
• GCs haben üblicherweise die alleinige Kontrolle über den ihnen zugewiesenen/zugesicherten Speicher. Damit wird eine Ressource weniger zwischen der Applikation und dem Rest geshared. Damit werden Programme mit GCs vorhersagbarer und deterministischer.

--Sebastian.Dietrich ✉ 18:40, 6. Dez. 2012 (CET)

Ich habe das Gefühl, du vermischt das hier mit Echtzeitanforderungen, besonders da du die ganze Zeit von "Zeitverhalten" sprichst. -- Plankton314 (Diskussion) 18:55, 6. Dez. 2012 (CET)

Es ging nicht um das zeitliche Verhalten. Sondern um nicht vorhersehbare Abzweigungen/Zustände. --Eike (Diskussion) 19:14, 6. Dez. 2012 (CET)

Bitte um ein Beispiel. Wie anders als über das Zeitverhalten des GCs soll ein Programm nicht vorhersehbare Abzweigungen/Zustände auf Grund des GCs einnehmen.? --Sebastian.Dietrich ✉ 19:25, 6. Dez. 2012 (CET)

Ich hab mich ungenau ausgedrückt: Es geht nicht um das Zeitverhalten der Anwendung. Das Zeitverhalten des GC kann zu unterschiedlichem inhaltlichen Verhalten der Anwendung führen. Dinge wie "Applikation "immer auf die nanosekunde gleich lange dauern"" spielen hier aber keine Rolle. --Eike (Diskussion) 19:29, 6. Dez. 2012 (CET)

Ok - dann bitte um ein Beispiel wie das Zeitverhalten des GCs zu unterschiedlichem inhaltlichen Verhalten der Anwendung führen kann. --Sebastian.Dietrich ✉ 19:31, 6. Dez. 2012 (CET)

Memory allokierung. In einem Fall "out-of memory->programm abbruch", in einem anderen nicht (GC hat gerade aufgräumt). Kann durch die nebenläufige und asynchrone GC passieren. Und nicht-deterministische zeitvariationen durch die GC können im Programm gravierende Zustandsvariationen aulösen. (zB bei zeitkritischer HW-kommunikation)Shaddim (Diskussion) 19:32, 6. Dez. 2012 (CET)

Hatten wir doch schon!?! Finalizer -> Datei schließen. Out-of-Memory würd ich da raushalten, das kann jedem Programm passieren. --Eike (Diskussion) 19:38, 6. Dez. 2012 (CET)

Genau bevor eine Speicherverwaltung einen OutOfMemoyError schmeisst muss sie versuchen _allen_ Speicher freizugeben. D.h. ein OutOfMemoryError kommt dann und nur dann wenn kein Speicher mehr vorhanden ist. Ist also deterministisch.

Im zweiten Beispiel gehts um Echtzeit (lt. Eike gilt aber "Dinge wie "Applikation "immer auf die nanosekunde gleich lange dauern"" spielen hier aber keine Rolle"). D.h. die Anwendung reagiert unterschiedlich je nachdem wie schnell sie läuft. Da bist auch ohne GC im Schlamassel, weilst ja die CPU mit anderen teilst. Und genau dafür gibts die Echtzeit GCs.

Finalizer ist per se nichts schlechtes, nur dann wenn dort erst Ressourcen freigegeben werden. Ist aber nicht Schuld der GC - d.h. der Programmierer gibt in einem anderen Thread Ressourcen frei. Wiederum Nebenläufigkeit.

D.h. Eine Applikation kann unterschiedliches Verhalten zeigen, wenn ihre Ressource CPU ihr unterschiedlich zur Verfügung steht oder der Programmierer Ressourcen in einem anderen Thread schliesst als er sie benötigt. GC selbst führt zwar zu Anforderungen an die Ressource CPU & ermöglicht es Programmierern in anderen Threads zu programmieren, führt aber nicht zu Zustandsvariationen. --Sebastian.Dietrich ✉ 19:55, 6. Dez. 2012 (CET)

Das hatten wir auch schon. Aus genau dem Grund soll man ja keine Ressourcen im Finalizer freigeben.

Wenn ein Objekt unterschiedlich lange lebt, bei gleichem Programmablauf, ist er nicht deterministisch. Egal, was irgendwelche Threads/CPU/andere Ressourcen machen. -- Plankton314 (Diskussion) 20:46, 6. Dez. 2012 (CET)

Nein, nur wenn der Programmablauf auch dadurch anders ist. Ein HelloWorld wird durch GC nicht anders. D.h. auch wenn du jede Menge verbotener Dinge in einer WeakReference oder Finalizer machst, das Programm ist dennoch deterministisch wenn es dadurch immer noch gleiche Programmablauf hat. --Sebastian.Dietrich ✉ 09:11, 7. Dez. 2012 (CET)

Dann lies dir mal Determiniertheit und Determinismus (Algorithmus) durch. Für mich scheint es so, als ob du das vermischen würdest.

Und überhaupt, finde ich das langsam schon etwas unverhältnismäßig. Und das ist jetzt nicht als PA gedacht:

Es ist ja nicht schlimm, wenn dir Grundlagen in theoretischer Informatik fehlen, aber dann gesteh dir das doch einfach ein. Auf Grund deiner Argumentation ist es ist jedem hier inzwischen klar, dass dein Wissen diesbezüglich ausbaubar ist. Und jede deiner Antworten stellt das nur noch klarer heraus.

Sorry, wirklich nicht böse gemeint, aber das musste mal raus. -- Plankton314 (Diskussion) 11:22, 7. Dez. 2012 (CET)

Sorry, denselben Eindruck habe ich von euch bekommen. Ich hab genügend Grundlagen in theoretischer Informatik beim Informatikstudium genossen um z.B. den Satz "auf eine Anweisung im Algorithmus folgt unter den gleichen Voraussetzungen immer die gleiche Anweisung" in Determinismus (Algorithmus) zu verstehen. Also nehme ich das jetzt auch nicht als PA, sondern als deine Sichtweise die ich hiermit spiegle. Lies die mal den Satz durch und erkläre mir, wie eine Applikation für die dieser Satz gilt nicht-deterministisch werden sollte? --Sebastian.Dietrich ✉ 12:09, 7. Dez. 2012 (CET)

Das ist unsere Definition von Nicht-Determinismus. Verstehe ich das richtig, dass du die für falsch hältst? Dann solltest du nämlich bei einem anderen Artikel diskutieren... --Eike (Diskussion) 12:14, 7. Dez. 2012 (CET)

Weil die "Voraussetzungen" nicht gleich sind, z. B. ob ein Objekt nun finalisiert wurde oder nicht. Dann ist der (Programm-)Zustand auch ein anderer, solange er überhaupt definiert wurde. -- Plankton314 (Diskussion) 13:24, 7. Dez. 2012 (CET)

Beschränken wir uns mal nur auf den Satz (den ich für richtig halte): Determinismus = "auf eine Anweisung im Algorithmus folgt unter den gleichen Voraussetzungen immer die gleiche Anweisung". Wenn ein Algorithmus also derart ist, dann kann er keine Objekte in einem Thread benötigen, die er in einem anderen Thread freigibt. Ebenso kann er keine Verzweigungen haben, je nachdem ob ein nicht mehr referenziertes Objekt tatsächlich finalisiert wurde oder nicht. Ansonsten entspräche der Algorithmus nicht dem Satz. So ein deterministischer Algorithmus kann aber niemals durch einen ebenfalls deterministisch arbeitenden GC indeterministisch werden. --Sebastian.Dietrich ✉ 16:40, 7. Dez. 2012 (CET)

Liest du gelegentlich, was du schreibst? Du hast mehrere Dokumente verlinkt, die belegen, dass mehrere Garbage-Collection-Implementierungen nicht-deterministisch ist. Zum Beispiel die Standard-Implementierungen von Java und .NET. Das macht die damit geschriebenen Programme potentiell nicht-deterministisch. Fertig. --Eike (Diskussion) 16:47, 7. Dez. 2012 (CET)

Das ist keine Antwort. Die Dokumente belegen 1) dass es GCs mit deterministischem Zeitverhalten gibt und 2) dass unter nicht-deterministisch im Zusammenhang mit GC _immer_ nur Zeitverhalten gemeint ist. Niemals Determinismus a la "auf eine Anweisung im Algorithmus folgt unter den gleichen Voraussetzungen immer die gleiche Anweisung". Aber egal - was ist die Antwort? --Sebastian.Dietrich ✉ 17:08, 7. Dez. 2012 (CET)

Was verstehst du unter nicht-deterministischem Zeitverhalten einer GC? Dass für den Anwendungsprogrammierer nicht vorhersagbar ist, wann Speicher abgeräumt und Finalisierer aufgerufen werden? --Eike (Diskussion) 18:15, 7. Dez. 2012 (CET)

Ja. Je nach CPU Auslastung kommt ein paralleler GC selbst früher oder später erst dazu Speicher aufzuräumen und somit Finalisierer aufzurufen. Wennst alle delete in einen anderen Thread auslagerst, dann hast dasselbe. --Sebastian.Dietrich ✉ 18:37, 7. Dez. 2012 (CET)

Ok! ...und das führt dann dazu, dass ich als Entwickler (einer Anwendung, die keine weiteren Threads startet) nicht mehr vorhersagen kann, wann meine Finalisierer aufgerufen werden. Während ich bei einem delete-Aufruf (in einer Anwendung, die keine weiteren Threads startet) genau weiß, wann mein Destruktor aufgerufen wird. Richtig? --Eike (Diskussion) 18:51, 7. Dez. 2012 (CET)

Genau - als Entwickler weisst du aber, dass der GC in einem anderen Thread läuft und alles, was du in dem anderen Thread machst deinen eigentlichen Thread beeinflussen könnte. GC stellt den Finalisierer nur zur Verfügung - einen potentiellen Indeterminismus hast dann selbst eingebaut --> GC ist deterministisch, dein Programm ist nicht deterministisch geschrieben.

Analog verhält es sich auch mit dem (FatClient) GUI. Das läuft in einem anderen Thread als dein Programm. Wennst dort dasselbe einbaust wie im Finalizer hauts dich potentiell genauso auf. Niemand wird aber auf die Idee kommen zu sagen "Nachteile der Verwendung eines GUIs ist häufig ein nicht-deterministisches Laufzeitverhalten." --Sebastian.Dietrich ✉ 21:23, 7. Dez. 2012 (CET)

Du hast jetzt zum xten Mal deinen eigenen Quellen widersprochen. EOD. --Eike (Diskussion) 21:39, 7. Dez. 2012 (CET)

Anscheinend sind dir jetzt die Argumente ausgegangen. Nichts von dem was ich sage widerspricht den Quellen. Wie ich schon oben gesagt habe reden die Quellen _immer_ nur von Indeterminismus des zeitlichen Verhaltens aber nie von was anderem. Und wie ich belegen konnte & ihr nicht entkräften konntet ist ein GC _nicht_ indeterministisch was das "auf eine Anweisung im Algorithmus folgt unter den gleichen Voraussetzungen immer die gleiche Anweisung" Verhalten anbelangt und kann auch niemals eine deterministische Applikation indeterministisch machen. EOD gerne --Sebastian.Dietrich ✉ 00:03, 8. Dez. 2012 (CET)

ich find es etwas dreist, das wort „indeterministic“ mit „non-deterministic“ gleichzusetzen... aber ihr seid ja alle so klug und gesund, dass ich dagegen schwerbehindert wirke, so dass ich das wohl alles falsch verstehe... --Heimschützenzentrum (?) 19:20, 7. Dez. 2012 (CET)

indeterministisch = non-deterministisch klar. Das "in" in der deutschen Sprache entspricht dem "non" in der englischen. --Sebastian.Dietrich ✉ 21:24, 7. Dez. 2012 (CET)

1. da würd ich ja nochmal drüber nachdenken... es könnte ja sein, dass der englische author kein homonym schaffen wollte... 2. aber: selbst für ein „in-/non-/nicht-deterministisch“ außerhalb der im Artikel verlinkten definition in der theoretischen informatik ist kein raum, weil ganz offensichtlich gemeint ist, dass bei _fehlerhaftem_ design unerwünschte, aber deterministische (also mit dem anfangszustand feststehende) Beeinflussungen auftreten können, die zu Verhalten außerhalb der Spezifikationen (=undefiniertem Verhalten) führen... --Heimschützenzentrum (?) 22:03, 7. Dez. 2012 (CET)

user:Sebastian.Dietrich hat insoweit recht, als dass user:Eike sauer nicht weiß, was ein deterministischer Algorithmus eigentlich ist... wie man mit solchen Missverständnissen umgehen soll, weiß ich nicht... vllt hilft es folgende Fragen zu beantworten (ich hab die ja schon beantwortet...): 1. Ist aus der Quelle wirklich eindeutig ersichtlich, dass das Wort „deterministic“ (o. ä.) im Sinne der theoretischen Informatik verwendet wird? 2. Wie sollte in einen realen Algorithmus Nicht-Determinismus gelangen können, ohne dass er entsprechende Anweisungen für das zufällige auswählen des nächsten Schrittes enthält? --Heimschützenzentrum (?) 16:40, 7. Dez. 2012 (CET)

und ich habe das Gefühl, dass Ihr was anderes meint als ich... --Heimschützenzentrum (?) 19:10, 6. Dez. 2012 (CET)

meint ihr vielleicht „undefiniert“? oder „rumpelcodechen“? *rotfl* --Heimschützenzentrum (?) 20:22, 6. Dez. 2012 (CET)

wie wär's denn, wenn wir erstmal determinismus gar nicht erwähnen, solange keine einigkeit über diese neu-eingebrachte theorie herrscht? stattdessen darf mal wohl von „undefinierten Ergebnissen“ schreiben (jedenfalls steht das in man pages (das ist auch sone art handbuch...) machmal...)... --Heimschützenzentrum (?) 22:06, 6. Dez. 2012 (CET)

 Pro --Sebastian.Dietrich ✉ 09:11, 7. Dez. 2012 (CET)

juhuh! :-) --Heimschützenzentrum (?) 09:24, 7. Dez. 2012 (CET)

Bleibt. Wir haben mehrere Quellen geliefert bekommen, dass GC häufig nicht-deterministisch ist. Daher schreiben wir, dass GC zu nicht-deterministischem Verhalten führen kann. --Eike (Diskussion) 11:05, 7. Dez. 2012 (CET)

Ahem, gehts noch? -- Plankton314 (Diskussion) 11:22, 7. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Sebastian.Dietrich ✉ 00:03, 8. Dez. 2012 (CET)

Ergebnis der Diskussion

Wir sind also zu dem Ergebnis gekommen, dass es deterministische GCs gibt. Uneins sind wir uns nur darüber, ob alle oder nur wenige GCs deterministisch sind. Aber egal - der Satz "... Verlust des deterministischen Laufzeitverhaltens" war eindeutig falsch und der aktuelle Satz "... – je nach Implementierung – ein nicht-deterministisches Laufzeitverhalten" ist korrekt. Heimschützenzentrum wird mir wohl zustimmen, dass man auf jeden Fall auch indeterministische GCs schreiben kann (da man alles indeterministisch schreiben kann). Also mir reicht mal das Ergebnis & bin zufrieden.  Pro--Sebastian.Dietrich ✉ 18:20, 6. Dez. 2012 (CET)

 Pro -- Plankton314 (Diskussion) 18:23, 6. Dez. 2012 (CET)

Widerspreche etwas, der Satz war richtig. Ich halte das Grundkonzept der GC inhärent für non-determinstic und nur für einen Sonderfall (eigentlich dem Grudnkonzept widersprechend) das deterministische GC baubar sind. Halte die aktuelle Formulierung ("je nach Implementierung") für zu schwach, aber zumindest für einen akzeptablen Kompromiss. deswegen  Pro Shaddim (Diskussion) 18:25, 6. Dez. 2012 (CET)

Ja, sehe ich auch so, aber darüber kann man (offensichtlich) (lange) streiten.

Differenziere es doch im Abschnitt Garbage_Collection#Nicht-deterministisches_Laufzeitverhalten_und_Finalisierung aus? -- Plankton314 (Diskussion) 18:29, 6. Dez. 2012 (CET)

Hab die Formulierung "ist der Programmfluss nicht mehr deterministisch." jetzt aus dem Absatz rausgenommen. War die letzte Formulierung zu "GC führt immer und überall zu non-deterministischen Programmen". Der Absatz passt jetzt auch für mich. --Sebastian.Dietrich ✉ 18:48, 6. Dez. 2012 (CET)

Das habe ich soeben revertiert, da der besagte Absatz so korrekt ist.

Darüber haben wir bereits gesprochen, gerade ein nebenläufiger GC verursacht nicht-deterministischen Programmfluss - egal, wie genau.

Es gibt auch andere Fälle - wie soeben besprochen -, aber in genau diesem stimmt die Aussage. -- Plankton314 (Diskussion) 18:52, 6. Dez. 2012 (CET)

Wenn es lt. dir andere Fälle gibt, warum steht dann dort "nicht mehr deterministisch" als ob das für alle Fälle gilt? Und erkläre mir doch mal wie ein einfaches HelloWorld indeterministisch sein soll, nur weil ein GC läuft? --Sebastian.Dietrich ✉ 19:23, 6. Dez. 2012 (CET)

man kann über die frage gar nicht streiten, denn: 1. real ablaufende nicht-deterministische algorithmen würden eine spezielle anweisung (CHOOSE (pseudocode)) benötigen (und eigentlich auch noch zur realen ausführung zusatz-hardware) (in meinem universitären Informatik (Grund-)Studium (also nich FH und auch nich Dring/Ing oder Statistik-Informatiker...) wurde auch noch darauf hingewiesen, dass es angelischen (findet beim ersten mal raten die lösung) und dämonischen (findet die lösung erst, wenn's keine weitere möglichkeit zu versagen gibt) nicht-determinismus gäbe... theoretisch...)... da es in der praxis keinen sinn ergibt, den GC mit solchen anweisungen wählen zu lassen (von echten zufallsgeneratoren mal ganz abgesehen), muss der GC also stets deterministisch sein... echt zufällige verzögerungen (wie etwa blitzschläge oder busfehler oder n passant, der sich von der straße in den vermittlungssaal verirrt hat und nun dauernd unvorhersehbar die knöpfe drückt...) machen einen algorithmus noch _nicht_ nicht-deterministisch... 2. entweder ist also der verweis auf den begriff Determinismus (Algorithmus) (2×) auch falsch, weil irgendwas anderes gemeint ist (bloß was?!), oder diese ganzen quellen da oben stammen von Nicht-Dipl.(U)-Informatikern (z. B. von Marketing-Fuzzis), die sich munter gegenseitig loben und „zitieren“ aber von Informatik keine Ahnung haben... 3. vielen dank für eure aufmerksamkeit und herzlichen dank, dass ich mich an meine alma ma(r)ter erinnern musste... :-| --Heimschützenzentrum (?) 19:01, 6. Dez. 2012 (CET)

Wann wurde eigentlich dazu übergegangen zu behaupten, dass der GC nicht deterministisch sei?

Es geht hier darum - und ich glaube, das ist euer Verständnisproblem -, dass das externe Wirken eines (auch deterministischen) GC auf ein Programm für das Programm selbst nicht deterministisch sein muss. -- Plankton314 (Diskussion) 19:06, 6. Dez. 2012 (CET)

Seh ich auch so. Aber wenn schon der GC nicht-deterministisch ist, kann man sich diese Diskussion ersparen. --Eike (Diskussion) 19:22, 6. Dez. 2012 (CET)

Wurde so von Shaddim in die Einleitung reingesetzt: [5]

Ja genau unser "Verständnisproblem" ist, wie ein deterministischer Programmteil einen anderen deterministischen Programmteil beeinflussen kann. Und wenn das bei GC der Fall ist, warum das nicht bei delete() der Fall sein sollte. --Sebastian.Dietrich ✉ 19:23, 6. Dez. 2012 (CET)

Den Unterschied hatte ich schon erklärt (6. Dez. 2012, 14:08). --Eike (Diskussion) 19:26, 6. Dez. 2012 (CET)

Sorry hab ich nicht verstanden. Du meintest: "eine (nicht nebenläufige) GC bei einem Aufruf entscheiden könnte, nach ihrem Gusto Speicher - anderen als den angeforderten! - freizugeben oder es bleiben zu lassen." Ja und, statt dass Speicher gleich freigegeben wird, wird er eben halt erst später freigegeben. Das ist ja "nur" das Zeitverhalten. Das macht ja für das Programm keinen Unterschied (da es diesen Speicher ja nicht mehr referenziert) und es auch nicht indeterministisch. --Sebastian.Dietrich ✉ 19:36, 6. Dez. 2012 (CET)

Auch das hatten wir schon: Bei WeakReferences hast du geändertes Verhalten, bei File Close im Finalizer hast du geändertes Verhalten, ... All das kann bei einem delete nicht passieren. --Eike (Diskussion) 19:40, 6. Dez. 2012 (CET)

Selbstverständlich kann mir das auch bei delete passieren. File Close in einem anderen Thread und schon fliege ich auf die Nase. Eine Cache Implementierung die nicht verhindert, dass Objekte deleted werden und schon weiss ich nicht mehr was im Cache noch vorhanden ist und was nicht. --Sebastian.Dietrich ✉ 09:07, 7. Dez. 2012 (CET)

Ja, man kann Nicht-Dterminismus auch ohne GC erreichen. Und? --Eike (Diskussion) 11:03, 7. Dez. 2012 (CET)

Genau - GC ist also nicht indeterministisch, sondern nur das Programm, dass in einem anderen Thread (im Finalizer) ein File Close macht. Detto ist GC nicht indeterministisch, sondern nur der Code den man mit einer WeakReference schreibt. GC bietet und Mittel (so wie die Java oder C# Klasenbibliothek / Sprache), mit denen man indeterministischen Code schreiben kann. GC selbst ist deterministisch und wenn der Code des Programmes auch deterministisch ist (z.B. nicht von File Close in anderne Threads oder dem Zustand von WeakReferences abhängt), dann ist wird auch das deterministische Programm durch den deterministischen GC nicht indeterministisch. --Sebastian.Dietrich ✉

Liest du gelegentlich, was du schreibst? Du hast mehrere Dokumente verlinkt, die belegen, dass mehrere Garbage-Collection-Implementierungen nicht-deterministisch ist. Zum Beispiel die Standard-Implementierungen von Java und .NET. Das macht die damit geschriebenen Programme potentiell nicht-deterministisch. Fertig. --Eike (Diskussion) 16:28, 7. Dez. 2012 (CET)

Wie schon mehrmals geschrieben belegen diese Dokumente nicht-deterministisches Zeitverhalten bei einigen GCs. Gemäß Determinismus (Algorithmus) sind sie jedoch deterministisch --> machen die damit geschriebenen Programme garantiert nicht indeterministisch. Aber egal es steht ja im Artikel nichts von "sind nicht deterministisch", sondern nur dass das Zeitverhalten nicht-deterministisch sein kann. --Sebastian.Dietrich ✉ 13:30, 8. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 13:30, 8. Dez. 2012 (CET)

edit war um „besser“ oder „schlechter“

es dürfte wohl zweifelsfrei so sein, dass automatische speicherbereinigung (GC) speicher- und cpu-mäßig aufwändiger ist, als „manuelle“ freigabe... die these, man könne ja die GC in lastschwachen zeiten erledigen, klappt nur, wenn die lastschwachen zeiten oft genug auftreten, was ja nicht unbedingt der fall sein muss... am schönsten sind also verfahren, die die freigabe schon während der compile-zeit planen, was sicherlich auch zusatzdaten erfordert, aber wesentlich schlanker ist... auch ist konservativer GC immer sparsamer als nicht-konservativer GC (der muss ja n bäumchen einfärben oder so...), wenn man einmal von kompaktifizierungs-vorteilen absieht... die frage ist also nur noch, ob in realen anwendungen die kompaktifizierung in signifikantem ausmaß speicherlokalität wieder herstellen kann und swapping vermeiden kann... und da dürfte es wohl solche und solche geben... --Heimschützenzentrum (?) 07:41, 19. Nov. 2012 (CET)

Klingt logisch, ist aber in der Praxis anders. Nur in trivialen Programmen ist zur Compilezeit klar, an welchen Stellen Code welcher Speicher freigegeben werden muss. Sobald Objekte über Klassengrenzen hinweg ausgetauscht werden kann aus dem Code meist nicht erkannt werden, wann diese Objekte freigegeben werden können. In normalen Programmen benötigt man daher Algorithmen, die Referenzen auf die allozierten Objekte verwalten und selbst erkennen, wann diese freigegeben werden müssen. Diese sind nicht trivial und benötigen somit genauso wie GC Speicher und CPU.

Da diese Algorithmen komplex zu implementieren sind, werden sie in der Praxis oft ungenügend implementiert (kenne da einige Projekte). Reines ReferenceCounting ohne Erkennung von Referenzzyklen ist zwar schnell, aber führt zu Memoryleaks.

Darüberhinaus arbeiten nicht-konservative GCs (wie z.B. in Java) in eigenen Speicherbereichen (weshalb sie ja auch kompaktifizieren können), benötigen also keine Betriebssystemfunktionalitäten. Über das Betriebssystem Speicher anzufordern und wieder freizugeben ist in der Praxis deutlich CPU aufwändiger als bei selbstverwaltetem Speicher.

D.h. GC hat noch mehr CPU-relevante Vorteile als nur Verlagerung in lastschwache Zeiten & Kompaktifizierung. Ob GC in realen Anwendungen in Summe jetzt schneller ist oder weniger Betriebssystemspeicher benötigt ist wie du schon geschrieben hast wohl nicht entscheidbar. Wir können hier vermutlich nur auf Microbenchmarks basierende Aussagen gegenüberstellen, dabei aber nicht vergessen, dass das Verhalten bei konservativen gänzlich anders ist als bei nicht-konservativen GCs. --Sebastian.Dietrich ✉ 10:05, 19. Nov. 2012 (CET)

1. C++'s new/delete fordern doch nich jedesmal übers OS speicher an... sondern erst wenn der vorrat nich mehr reicht... hier gibts also keinen unterschied... 2. microbenchmarks machen keine brauchbare aussage, wobei ohnehin klar ist, dass GC aufwändiger ist (aufwand: ohne GC < konv. GC < nicht-konv. GC; nutzen: da isses nich so einfach, sobald die kompaktifizierung dazu kommt...)... 3. gibt es auch n beispiel für objekte, denen man nich auf den kopf zusagen kann, dass sie nich mehr gebraucht werden? z. B. das Objekt „Anschrift von Kunde A“ wird eben gebraucht, bis die gesetzlichen speicherfristen abgelaufen sind... solche fristen kann n GC aber nich prüfen, so dass man also die arbeit doppelt machen muss... --Heimschützenzentrum (?) 18:48, 19. Nov. 2012 (CET)

@ 1) dachte dem wäre so - kannst mir da einen Link geben, wo das nachzulesen wäre? @2) bin mir nicht sicher ob konservative GC wirklich < nicht konserveative GC - durch den ganzen Speicher laufen um Bitfolgen zu suchen, die in einem gewissen Bereich sind, halte ich schon für aufwändig. Oder meintest du konventionelle GC? Was soll das sein=

@3) klar GC kann nicht alles prüfen, dafür ist es auch nicht gemacht. GC kann aber Dinge erkennen, die zur Compilezeit nicht klar sind. Daher braucht man in nicht-trivialen Programmen irgendeine Form der GC, ansonsten hat man mit Sicherheit Memoryleaks. --Sebastian.Dietrich ✉ 01:08, 20. Nov. 2012 (CET)

1. RTFM: en:sbrk... brk... 2. oops... -konv+kons (zweimal)... hielt ich für trivial, weil jeder speicherabschnitt bloß n zähler vorne braucht... dann noch die liste der freien abschnitte... hört sich leichter an, als das ganze theater mit den farben und mit der kompaktifizierung... 3. bsp für son nicht-triviales programm, das du verraten darfst? das scheinen mir ganz merkwürdige fälle zu sein, wenn ein objekt leicht erkennbar gelöscht werden darf... normal wird auch bei java am ende immer irgendwas gemacht (z B aus ner liste gelöscht)... --Heimschützenzentrum (?) 07:42, 20. Nov. 2012 (CET)

3. De facto jedes Programm, wo Referenzen auf neu angelegte Objekte weitergegeben werden. Klasse Person referenziert Adresse in Attribut hauptwohnsitz. Klasse Zustellung referenziert Adresse in Attribut lieferadresse. Person mit hauptwohnsitz wird angelegt (new Adresse()). Person bestellt im Internet was zur Zustellung an hauptwohnsitz (new Zustellung().setLieferadresse(person.getHauptwohnsitz())). Person und Zustellung referenzieren dieselbe Adresse. Frage: Darf ich delete(hauptwohnsitz) machen, wenn Kunde woanders hinzieht? Darf ich delete(lieferadresse) machen, wenn Kunde sein Paket woanders hinbekommen möchte? Antwort: Ich darf die Adresse nur dann löschen, wenn beide nicht mehr auf sie referenzieren. Nachdem aber weder Person, noch Zustellung, noch sonstwer in der Applikation weiss, wo überall die Adresse verwendet wird, kann die u.U. nirgendmehr benötigte Adresse nur durch GC freigegeben werden. --Sebastian.Dietrich ✉ 16:43, 20. Nov. 2012 (CET)

das ließe sich ja nun mit nem einfachen referenzzähler erledigen... außerdem ist die wirkliche Frage ja allein schon durch das bundesdatenschutzgesetz viel komplizierter als „Gibt es noch Referenzen?“... jede Instanz der Klasse Kunde/Bestellung müsste eben ein Datum der letzten Dateneingabe enthalten und wenn die Frist (AGB oder BDSG) abgelaufen ist, „rippeln“ die Destruktoren die zugehörigen Daten eben alle auf... :-) --Heimschützenzentrum (?) 19:16, 20. Nov. 2012 (CET)

geht nicht mit Referenzzähler, wenn es zyklische Referenzen gibt (also z.B. die Bestellung den Kunden kennt). Das mit dem Bundesdatenschutzgesetz ist wohl nicht dein Ernst - wir sprechen von Memory und nicht von DB. --Sebastian.Dietrich ✉ 23:31, 20. Nov. 2012 (CET)

1. nur die adresse hätte na klar den zähler... wenn keiner mehr die adresse sehn will/kann, fliegt sie raus... da kann die adresse sooft sie will auf kunden/bestellungen verweisen (das würd sogar den referenzzähler sparen)... 2. ich dachte wir benutzen n OODBMS? das benutzt mehr oder weniger elegant sachen wie swapping... macht man das nich mehr so? :-) --Heimschützenzentrum (?) 07:36, 21. Nov. 2012 (CET)

1. und wennst auch bei der Adresse zyklische Referenzen hast? z.B. Adresse referenziert über eine Liste auf andere Adressen als alternativeZustelladressen (um beispielsweise das Paket bei Nachbarn abzugeben). Diese referenzieren potentiell natürlich wieder zurück. Zyklische Referenzen gibts in jeder größeren App 2. nein das macht man nicht so. Im RAM werden Objekte gelöscht, wenn sie im RAM nicht mehr benötigt werden. In der DB, wenn sie gar nicht mehr benötigt werden (z.B. auch nicht aus historischen Gründen). Ersteres hat mit zweiterem überhaupt nix zu tun - egal ob OODBMS oder RDMBS oder sonstwas. --Sebastian.Dietrich ✉ 09:15, 21. Nov. 2012 (CET)

1. na das meinte ich wohl mit „aufrippeln“... da muss der destruktor eben schön aufräumen... vllt findet er dabei auch noch was zum löschen... 2. das hatten wir mal irgendwie anders gesehn... en:objectStore oder so? gibts bestimmt noch... jedenfalls in der en:WP... --Heimschützenzentrum (?) 09:26, 21. Nov. 2012 (CET)

1. wie soll das funktionieren? A->X, B->X, X->X2, X2->X3, X3->X. Beim Löschen von A reduzierst den Refcounter von X auf 2. Beim Löschen von B reduzierst den Refcounter von X auf 1. Was nun? Lösung möglich, aber nicht trivial - siehe Garbage Collection#Referenzählung - du hast also einen schönen GC basierend auf Referenzzählung implementiert.

2. vor langer langer Zeit - und hat sich auch damals nicht durchgesetzt. --Sebastian.Dietrich ✉

1. nee... beim löschen von A reduziert sich der "wieviele bestellungen brauchen mich?"-zähler auf 1, beim löschen von B auf 0... dann wird munter gelöscht: nämlich X, aber _vorher_ wird die queue-struktur um X reduziert... 2.a. würd ich heute immernoch so machen, weil es einfach super ist... ist/war wohl etwas teuer, weil die soviel nachgedacht haben... 2.b. wie macht man es denn heute? *neugierig guck* :-) --Heimschützenzentrum (?) 20:46, 21. Nov. 2012 (CET)

1. wieso - am Anfang gibt es 3 Refrenzen auf X, nach Löschen von A 2, nach Löschen von B 1 ergo wird X nie gelöscht, da es ja noch eine zyklische Referenz gibt. Oder würdest du je referenzierendem Typ einen eigenen Referencecounter machen (also für Referenzen von Bestellungen auf die Adresse und einen anderen von Kunden auf die Adresse)? Wäre ungewöhnlich und würde auch nichts bringen, da ja auch Zyklen mit Objekten gleichen Typs möglich sind (de facto keine Seltenheit) - in dem Beispiel würds auch nix bringen 2. heute (bzw. immer schon - d.h. ich denke die von dir geschilderte Art hat sich nie durchgesetzt) ist die DB das wohin Dinge persistiert werden. Im RAM halte ich nur die Dinge die ich aktuell benötige. Fürs Persistieren verwende ich ein ORM Framework oder eine OODB. new() zu überladen macht keinen Sinn, da ich ja zum Zeitpunkt wo ich ein neues Businessobjekt benötige noch gar nicht weiss, ob ichs auch wirklich speichern möchte. Das Konzept von ObjectStore passt mMn auch nicht mit Transaktionen zusammen, da im GUI & somit RAM andere Arten von Transaktionen als in der DB laufen. Aber egal, vielleicht ists ja ein tolles Konzept, aber unbekannt. --Sebastian.Dietrich ✉ 01:27, 22. Nov. 2012 (CET)

1. ich würde na klar keinen primitiven „Referencecounter“ machen, sondern ein auf das problem speziell zugeschnittenen zähler oder ne liste oder was auch immer... da X „weiß“, dass es element einer ring-förmig verketteten liste ist (das ist wohl doch keine queue, glaub ich), braucht man hier ja gar keinen zähler, da man nur den ring „reparieren“ (also X3 suchen) muss... ich bin mir auch sicher, dass man solche lösungen immer und auch ziemlich einfach findet, wenn das software design nich zu chaotisch ist... 2. da konnte man am anfang eine sequenz von änderungen sagen, dass jetzt die transaktion beginnt, und am ende sagte man, dass es jetzt eben committed werden soll... ACID eben... oder fantasier ich mir das jetzt zusammen? ich kannst mir gar nicht anders vorstellen, wie das sonst gehn soll (wenn ich jedem objekt beibringen muss, sich selbst in irgendnem RDBMS zu speichern und zu laden, nervt das doch viel zu sehr... oda?)... sieht die en:WP ähnlich... aber egal... 3. warum gibt es denn keine echten studien, die einfach die CPU zeit zählen, die diese und jene lösung braucht... bisher hört es sich ja eher so an, als könne man bei programmieren durch den GC quicker&dirtier sein... --Heimschützenzentrum (?) 07:21, 22. Nov. 2012 (CET)

1. Dein Ansatz ist natürlich möglich, hat aber 2 Probleme: erstens musst du etwas immer und immer wieder neu implementieren, je nach Situation einmal ohne Zyklus, einmal mit Zyklus, einmal mit mehreren Zyklen einmal mit viele Klassen übergreifenden Zyklen, ... Zweitens hast du globales Wissen in X eingebaut, eine Änderung der Abhängigkeitsstruktur ausserhalb von X darfst du in X nicht vergessen auch zu berücksichtigen. Damit hast du 2 Prinzipien der Softwareentwicklung missachtet (Not-invented-here-Syndrom bzw. en:Reinventing_the_wheel und Single-Responsibility-Prinzip) und kommst in größeren Applikationen auf jeden Fall in des Teufels Küche (Wartungshölle)... 2. ACID ist schön und gut, aber Transaktionen sollten in der DB kurz sein - nicht z.B. über Minuten gehen, während der User einen Wizard befüllt. Ja natürlich musst du jedes Objekt, dass du speichern möchtest auch speichern. Das geht zumeist mit Techniken ausserhalb der entsprechenden Objekte (z.B. via DAO/DTO Pattern). Mit OODBs bzw. ORMs ist das auch ziemlich trivial (es sei denn deine DB-Struktur passt gar nicht zur Objektstruktur. 3. die primäre Aufgabe eines GCs ist es ja nicht die Applikation schneller zu machen (dann gäbe es Studien), sondern die Umsetzung einfacher (quicker) und korrekter (weniger dirty) zu machen. Keinen Code zum Freigeben von Objekten zu schreiben ist immer schneller und korrekter und führt zu weniger und auch zu lesbarerem und wartbarerem Code. --Sebastian.Dietrich ✉ 09:42, 22. Nov. 2012 (CET)

1. sobald X auf ein anderes X zeigt, muss man sich mit den entstehenden strukturen auseinandersetzen... ich sehe nich, wie das prinzipien der Softwareentwicklung missachten könnte... auch pfeile in beiden richtungen zwischen 2 klassen sind nich verwerflich... 2. nun ja... wenn jmd z B n kundenkonto ändert, dann will man ja gar nicht, dass es jemand auch nur liest, weil es ja offenbar veraltet ist... man bräuchte aber unter umständen auch bei objectstore transiente objekte, die zeitaufwändig befüllt und dann später in ein persistentes objekt gekippt werden... 3. ich sehe bisher eher, dass die edits auf CPU Belastung und nicht auf Korrektheit oder Entwicklungszeit hinaus wollen... dann sollten wir wohl die CPU Frage abschließend mit „störend bis höher aber wegen oft genug auftretender lastarmer zeiten egal“ beantworteen und das mit der Korrektheit oder Entwicklungszeit sollte aber noch mit quellen belegt werden (das ist nämlich nicht so trivial, find ich...)... 4. im abschnitt „Leistungsfähigkeit“ wird insinuiert, dass GC irgendeiner OS-basierten speicherverwaltung gegenüber stünde... das müsste dann aber auf jeden fall raus... --Heimschützenzentrum (?) 11:03, 22. Nov. 2012 (CET)

1. Dein Vorschlag für die Umsetzung einer Speicherbereinigung ohne Verwendung einer Garbage Collection ist problematisch. Nicht die Verwendung von zyklischen Referenzen. 2. Ist in der Praxis nicht so - nur weil ein Bankbetreuer gerade ein Kundenkonto sich am GUI anschaut und es potentiell ändert müssen ja Abbuchungen etc. weiterhin funktionieren. Pessimistisches Locking wird nur selten verwendet. 3. Verstehe nicht warum du das nicht siehst - hab doch ein einfaches Beispiel genannt, wo du eine ziemlich komplexe Speicherbereinigung benötigst, die verdammt viel Entwicklungszeit kosten und viele Bugs enthalten. Mit einem fertigen GCs hast 0 Entwicklerzeit und keine Bugs. Nachdem diese Algorithmen entweder bei jedem delete laufen, oder so wie GCs ein Management der zu löschenden Objekte implementieren, vermute ich dass so eine manuelle Speicherbereinigung in Summe gleichviel oder sogar mehr CPU Zeit benötigt als ein fertiger GC. 4. done --Sebastian.Dietrich ✉ 22:51, 22. Nov. 2012 (CET)

1. „verwend

ung von GC“ ist sicherlich kein prinzip... man könnte sich etwa vorstellen, dass bereits zur compile zeit die entsprechenden verfahren automatisch generiert werden... so wundere ich mich z B seit Jahren, dass es nich längst richtige Hochsprachen gibt (irgendwas regelbasiertes...)... irgendwie scheint es immernoch imperativ zu sein, wie damals zu assembler zeiten... 2. die granularität wär da ja die frage... speicherseiten-weise wär ziemlich blöd... :-) dann müsste man wirklich gesonderte sperrverfahren basteln... 3. das mit der CPU zeit ist so trivial nicht... das mit der entwicklungszeit hört sich erstmal plausibel an, obwohl (wie schon gesagt) die lebensdauer eines objektes nicht so trivial festgestellt werden kann, wie es für n GC nötig wäre (also in einem OODBMS)... 4. supi... --Heimschützenzentrum (?) 23:43, 22. Nov. 2012 (CET)

u.u. sind die zugriffsmuster eines GC deutlich günstiger für den CPU-cache als die einer manuellen freigabe. zudem ist allokation bei einem modernen GC sehr billig, weil nur ein einziger pointer umgesetzt wird. -- ∂ 16:55, 20. Nov. 2012 (CET)

braucht ne freigabe nich immer n eintrag in ner liste? der billigen allokation steht jedoch n riesen aufwand bei der kompaktifizierung/freigabe gegenüber... wir bräuchten für den artikel also studien, die die klassen der programme herausarbeiten, die unter GC eher leiden... --Heimschützenzentrum (?) 19:19, 20. Nov. 2012 (CET)

Das wäre super interessant! Shaddim (Diskussion) 20:05, 24. Nov. 2012 (CET)

Unter GC leiden vermutlich am ehesten solche Programme, die keine Referenzzyklen aufweisen (weil die sind auch bei klassischem delete mit höheren Aufwänden verbunden), 100% CPU benötigen (weil dann die GC nicht in CPU-schwache Zeiten ausgelagert werden kann) und immer Objekte gleicher Größe anlegen/freigeben (weil dann die Kompaktifizierung nix bringt). Wenn man sich das so anschaut leiden anscheinend vor allem Benchmark-Programme unter GC. --Sebastian.Dietrich ✉ 09:32, 25. Nov. 2012 (CET)

ist in der wirklichkeit jede klasse teil eines zykels? nö, oda? wenn man das so sich ansieht, leiden eben nicht nur benchmarks unter GC... stimmt's? aber GC ist grad bei vielen trotz allem ganz toll beliebt... :-) --Heimschützenzentrum (?) 09:48, 25. Nov. 2012 (CET)

Ja stimmt - also Programme, die Objekte haben, die in keinen Zyklen landen (d.h. de facto alle Programme) UND auch wissen welche das sind (da sind wir schon deutlich unter 100%) UND auch dafür die richtige Stelle wissen wo die Objekte nicht mehr benötigt werden (da schauts schon gaaanz schlecht aus) & sie mit delete genau dort löschen - diese Programme würden unter GC leiden. Es sei denn sie verbrauchen nicht 100% CPU und (weil dann leiden sie ja nicht unter einem parallel laufenden Thread) (jetzt sind wir vermutlich bei 0,001% angelangt). Und auch wenn sie 100% CPU verbrauchen leiden sie unter der GC u.U. weniger als sie unter Speicherdefragmentierung leiden. Also ja - es gibt sicher Programme die performancemäßtig unter GC leiden - aber verschwindend wenige.

Aber egal - wenn es Studien dazu gibt, welche Programme performancemäßig unter GC leiden und welche performancemäßig von GC profitieren - nur her damit. --Sebastian.Dietrich ✉ 12:13, 25. Nov. 2012 (CET)

1. also zunächst sollte ordentliches SW design schon zu einem programm führen, dass weiß, wann n objekt am ende ist... 2. wenn nur 10% der objekte kompliziert delete-t werden müssen, dann ist es ja schonmal besser, als wenn da n GC schon zum tausendsten mal sinnlos dran rumschnüffelt... 3. also in dieser einen studie, die im artikel erwähnt wurde, steht irgendwie was von nem faktor 3 (Java/C)... das ist wohl mit Fragmentierung und schlechter Lokalität kaum wieder reinzubekommen... kicher --Heimschützenzentrum (?) 20:03, 25. Nov. 2012 (CET)

wie gesagt wenns wo Studien gibt, die _insgesamt_ belegen, welche Programme unter GC leiden, dann rein damit. Solange stehen die Vorteile gegen die Nachteile - ich persönlich bin fest davon überzeugt dass GC auch von der Performance her in Real-Life Applikationen besser abschneidet als herkömmliche Speicherbereinigung - du bist persönlich fest davon überzeugt, dass das Gegenteil der Fall ist. Der Artikel ist diesbezüglich neutral, alle sind glücklich :-) --Sebastian.Dietrich ✉ 22:30, 25. Nov. 2012 (CET)

ich dachte hier in Fig. 8 stünde, dass in C++ das progi 23sec braucht und in Java mit superduperextra GC tuning dauert es immernoch 89sec... oder ist Java immer lahmer als C++? ich dachte java wird quasi schon in maschinensprache übersetzt... *hach* da es aber keinen GC für C++ gibt (boehm ist mir zu komisch, weil es ja auch einfach nur datenkram sein könnte, was der aber fürn pointer hält), scheidet GC allein schon deswegen völlig aus... der artikel lässt derzeit diesen faktor 3, der mit der entscheidung für GC einhergeht, irgendwie nicht erkennen (ich hab heut noch das gejaule im ohr, dass ja mit java alles sooooo viel langsamer ist als mit dem guten alten „ho(r)st“... desweiteren wurde dort wohl öfters kaffee vermisst...)... --Heimschützenzentrum (?) 22:52, 25. Nov. 2012 (CET)

zufälligerweise passend, hier taucht der faktor drei auch auf: Conclusions [...] We believe these results will be useful both for practitioners and researchers. Practitioners can use these results to guide their choice of explicitly-managed languages like C or C++, or garbage-collected languages like Java or C#. If their applications will be deployed on systems with at least three times as much RAM as needed, then garbage collection should provide reasonable performance. However, if the deployed systems will have less RAM, or if their applications will have to compete with other processes for memory, then practitioners should expect garbage collection to exact a substantial performance cost. This cost will be especially pronounced for applications whose performance is tied to their efficient use of memory, such as in-memory databases and search engines. Matthew Hertz, Emery D. Berger, Quantifying the performance of garbage collection vs. explicit memory management Shaddim (Diskussion) 23:58, 25. Nov. 2012 (CET)

Bitte bitte bitte nicht mehr _Benchmarks_ zu GC ist langsamer/schneller als explizites Löschen. Wie oben bereits diskuttiert gibt es sicherlich Situationen, wo GC langsamer ist und andererseits Situationen, wo GC schneller ist. Bei typischen Benchmarks (hoher CPU Load, viele gleichgroße Objekte, keine Referenzzyklen) können GCs ihre Stärken nicht ausspielen. Es wundert mich sogar, dass dieser Benchmark bei genügend RAM zeigt, dass GCs sogar schneller sein können als explizites Löschen "In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management." Was wir brauchen sind Aussagen zu _echten Applikationen_ und nicht theoretische Situationen - dieser Artikel hier hilft uns nicht weiter. --Sebastian.Dietrich ✉ 09:36, 26. Nov. 2012 (CET)

um die 3-fache cpu zeit und höheren speicherbedarf kommt man so oder so nicht drum rum (ziemlich egal was für ne art programm man laufen lässt...)... ob es nun nur in der stromrechnung stört oder aber auch die bearbeitungszeiten vervielfältigt und bei nebenläufigkeit alles nur noch mehr behindert, ist ja egal... dazu kommt das gefühl, n ineffizienten haufen code gebastelt zu haben, über den die user dauernd jammern werden... und wenn die es dann auch noch tun, wird es nicht besser (weil man ja weiß, dass es auch besser geht...)... --Heimschützenzentrum (?) 09:55, 26. Nov. 2012 (CET)

Ja in real-life Applikationen erspart man sich ohne GC ein paar CPU Zyklen, und ein bißchen Speicher. Dafür hat man mehr Aufwand, deutlich mehr Bugs und schlechteres Design. Darum sterben auch die Programmiersprachen ohne GC langsam aber sicher aus. --Sebastian.Dietrich ✉

ein paar... alles klar wie klärchen... für mich ist hier nun auch das EOD erreicht... das endet immer gleich, wenn wir „diskutieren“... *staun* :-) --Heimschützenzentrum (?) 16:35, 26. Nov. 2012 (CET)

Dem muss ich ebenfalls widersprechen, ganz im Gegenteil: einerseits sehe ich die Fehleinschätzung sich auflösen das man den Programmieren zwar das verwalten der Ressource "Speicher" nicht zutrauen kann (und man es ihm abnehmen muss), aber die Erwartung hat andere Computerressourcen (Sockets, Threads, Handles, Graphikarten, etc) kann er Verwantwortungsbewusst allokieren und deallokieren -> Irrtum, Speicher ist letztendl. nur eine Ressource wie jede andere. Zweitens sieht man aufgrund der weiter aufwachsenden von-neumann-memory wall und dem wichtiger werdenden distributed computing immer grösseren Bedarf an bestmöglichem Datentransfer und memoryperformance, nur explizites memorymanagment & hardware-aware computing (alignment, cache-sizes) erlauben diese (siehe zB GPU-computing), GC ist da im Weg. Und als drittes, es gibt alternativen sozusagen zwischen den extremen free, malloc und dem Vollautomatismus GC -> Regions (D. Gay and A. Aiken. Memory management with explicit regions. In Proceedings of the 1998 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 313 – 323, Montreal, Canada, June 1998.), welche wohl noch signifikantes Performance potential bieten. Shaddim (Diskussion) 18:10, 26. Nov. 2012 (CET)

Ich denke die Diskussion hier führt zu nichts mehr - wir reden von Benchmarks, Gefühlen, Meinungen. Der Artikel ist zumindes derzeit mMn nicht wirklich POV, der Edit-War ist schon lang keiner mehr. EOD --Sebastian.Dietrich ✉ 16:28, 26. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:17, 7. Feb. 2013 (CET)

Einleitung (schonwieda)

Hallo denke eigentlich eine Einleitung sollte so kanpp wie möglcih NUR das elementare umfassen, jedoch lasse ich mich auch eines besseren belehren. ;)

Moment bin ich noch der Meinung diese Variante: "Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Minimierung des Speicheranspruches eines Prozesses bzw. einer Software. Hierzu werden nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch identifiziert um dann freigeben oder wiederverwendet werden zu können." alles relevante aussagt.

Diese Variante: "Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik im idealen Fall die Minimierung des Speicheranspruches eines Prozesses, die sowohl während der Software-Entwicklung als auch während der Laufzeit ohne Aufwand stattfindet. Dabei bieten sich in der Praxis die Freigabe oder Wiederverwendung nicht länger benötigter Speicherbereiche an, die aber schon dem Prozess zugeteilt wurden. Auch die Beseitigung externer Fragmentierung bietet sich an. Bezüglich der Zeit- und Speicher-Komplexität gibt es mehr oder weniger deutliche Abweichungen vom Ideal." ist 50% länger.

Spezifische Kritik an Variante 2: es wird das komplexe Konzept "Fragmentierung" erwähnt obwohl dies GC nur am Rand berührt. Bietet sich wem oder was an? Bei der Formulierung "Ohne Aufwand" ist unklar auf wenn sie sich bezieht (Programmierer? CPU?) und was für eine Art von Aufwand dies sein soll ist unklar. Aufwand für den Programmierer ist in Formulierung 1 mit "automatisch" erschlagung. "Idealer Fall", mir leider unklar, auch im nicht-idealen Fall versucht eine GC den Speicheraufwand zu minimieren, bezieht sich das auf ein theoretisches Minimum welches praktisch nicht erreicht wird? Dann wäre dies aber doppelt da dies schon im letzten Satz "Abweichung vom ideal" angedeutet wird. "Komplexität" meint Aufwand? Shaddim (Diskussion) 23:18, 26. Nov. 2012 (CET)

da oben ist schon n abschnitt zum thema „einleitung“... hast ihn gelesen? z B steht da, dass eine Minimierung im allgemeinen Fall nicht unbedingt gelingt... die Minimierung ist also das Ideal... Kompaktifizierung (=deFragmentierung) ist eine zentrale Aufgabe des GC... steht alles schon oben eigentlich... Komplexität#Komplexit.C3.A4t_in_der_Informatik... --Heimschützenzentrum (?) 23:25, 26. Nov. 2012 (CET)

Ok verstehe, den Punkt sehe ich ein und versuche ihn einzuarbeiten:

"Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Minimierung des Speicherbedarfs eines Prozesses bzw. einer Software. Hierbei wird versucht nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren um diese dann freigeben, zusammenzulegen oder wiederverwenden zu können; dies gelingt häufig gut wenn auch niemals Perfekt."

oder komplizierter

"Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Minimierung des Speicherbedarfs eines Prozesses bzw. einer Software. Hierbei wird versucht nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren um diese dann freigeben, zusammenzulegen oder wiederverwenden zu können. Da bei nicht-trivialen Programmen die Speicherbereinigungssituationen beliebig komplex sein können, erzielen Automatische Speicherbereiniger mit einem begrenzen, realistischen Aufwand typischerweise nur Gute und keine perfekte Bereinigungen der Speicherräume." gruesse Shaddim (Diskussion) 00:05, 27. Nov. 2012 (CET)

ehm? es geht hier nicht darum, dass jeder mal die einleitung schreiben darf... ist die einleitung derzeit inhaltlich falsch? dann lohnt sich wohl ne neue formulierung... syntaxfehler? auch nich... ich verstehe gar nich, wieso ich über ne neue formulierung nachdenken soll... außerdem ist der neue vorschlag so langatmig und gekünstelt... erst isses die „minimierung“ und dann plötzlich doch nich („nur gute“)... außerdem sind auch mit GC fette speicherlecks denkbar... die einleitung soll aber knapp den artikel umreißen: WP:Einleitung --Heimschützenzentrum (?) 07:16, 27. Nov. 2012 (CET)

Wie du richtig sagst (und ich ebenfalls meine) soll eine Einleitung das wesentliche (und nicht mehr) allgemeinverst. knapp umreissen. Der momentan im Artikel vorhanden Zustand erfüllt die bedingungen "Allgmeineverstl." und "knapp" nicht (siehe auch schon die Diskussion oben). Vor allem sind die Bezüge unklar und teilweise die Beschreibung zu "unscharf" (zB Komplexität). D.h. wir sollten weiter an einer besseren Lösung zusammmenarbeiten. gruesse Shaddim (Diskussion) 09:17, 27. Nov. 2012 (CET)

Minimierung ist schon der korrekt Term, es bezeichnet ja nur die Suche nach dem Minimum/Optimum & garantiert nicht das es gefunden wird. Man könnte auch das schwächere "Reduktion" nehmen, was ich persönl. aber zu schwach fände. Shaddim (Diskussion) 09:21, 27. Nov. 2012 (CET) PS: oder wie wärs mit em etwas allg. "Optimierung"?

nachgefeilt:

"Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Optimierung des Speicherbedarfs einer Software bzw. eines Prozesses. Hierbei wird versucht zur Laufzeit nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren um diese dann weiterverwenden zu können; manchmal wird auch versucht verwendete aber zerstückelte Speicherbereiche zusammenzulegen. Auch wenn nicht-triviale Programme beliebig komplexe und unvorhersehbare Speicherverwendungsmuster über die Laufzeit haben können, können Automatische Speicherbereiniger mit einem begrenzen, vernünftigem Aufwand typischerweise eine gute, wenn auch keine perfekte Bereinigung erzielen." (wichtig: +laufzeit) Shaddim (Diskussion) 09:17, 27. Nov. 2012 (CET)

1. zur bedeutung von „Minimierung“: WP ist keine Quelle gemäß WP:Q... :-) Aber selbst die Definition trifft nicht, weil eben ein GC das Optimum weder suchen noch erreichen muss, um als GC zu gelten (die bisherigen GC algorithmen eignen sich hierzu einfach gar nicht... besonders die konservativen nicht...)... außerdem bedeutet „Minimierung“ mMn, dass etwas minimiert wird (also dass das Minimum erreicht wird), was ja nun gar keine erfüllbare Forderung an den reale GC sein kann... 2. derzeit fasst die einleitung folgende wesentliche aspekte zusammen: (a) Zweck (b) Methode (c) Nachteile (d) Vorteile... das gleiche gilt auch für den „nachgefeilten“ vorschlag (bis auf die nachteile bei der zeit-komplexität... warum eigentlich?), so dass ich keinen grund für eine änderung erkennen kann (eher dagegen, weil es irgendwie weniger kompakt wirkt...)... --Heimschützenzentrum (?) 11:00, 27. Nov. 2012 (CET)

1. kannst du mal konkret erklären, was an der jetzigen einleitung verbesserungswürdig sein soll? 2. das wort „komplexität“ ist doch nicht „unscharf“... 3. und dass GC auch zur „laufzeit“ stattfinden kann, steht doch auch schon drin... ich verstehe echt nich, was die änderung verbessern soll... 4. und bitte nicht beiträge inhaltlich verändern, auf die ich schon geantwortet hab... dange... :-) --Heimschützenzentrum (?) 11:32, 27. Nov. 2012 (CET)

Die Kritikpunkte (s.o.) gelten immer noch: Der Einleitungssatz ist nicht OMA tauglich - der Vorschlag von Shaddim ist da deutlich besser. Ich verstehe den Einleitungssatz, aber ein Informatiker ohne Wissen zu GC versteht ihn nicht (siehe die Punkte oben, die sind alle mißverständlich und brauchen eine weiterführende Erklärung). --Sebastian.Dietrich ✉ 12:46, 27. Nov. 2012 (CET)

Dem kann ich nur zustimmen. Die Einleitung ist schlichtweg falsch - um es mal seeehr diplomatisch zu formulieren.

"Minimierung des Speicheranspruchs [...] ohne Aufwand"?! Aus welcher Phantasiewelt stammt das?

GC ist eine Form der (halb-)automatischen Speicherverwaltung die mit zusätzlichem Aufwand daherkommt. Von "Minimierung" des Verbrauchs kann ebenfalls keine Rede sein. -- Plankton314 (Diskussion) 13:27, 27. Nov. 2012 (CET)

1. im _idealen_ fall hat die GC, die in der einleitung genannten ziele: sparsamer umgang mit speicher und CPU... es ist dabei ganz egal, wie es in irgendeinem real existierenden fall aussieht, den sich irgendwelche laien vorstellen... 2. das OMA argument war da oben schon keins... 3. die unverschämten angriffe hier lassen mich eher vermuten, dass die diskutanten (?...informatiker...?) mich (dipl-inf) belästigen wollen (hinweis zur glaubhaftmachung: [6] / [7]; bei user:Plankton314 gabs auch schon mehrfach edits, die zumindest leichtfertig waren...)... 4. ohne konkrete nachvollziehbare argumentation hat diese disk hier keinen sinn... wär das was für WP:3M? --Heimschützenzentrum (?) 18:42, 27. Nov. 2012 (CET)

Die GC ist keine abstrakte Theorie, für die es nur näherungsweise Lösungen gibt. Darum sind die praktischen Realisierungen relevant.

OmA ist speziell in der Einleitung gefordert. Es tut mir leid, aber der sparsame Umgang mit Speicher und CPU ist definitiv kein primäres Ziel der GC.

Diese Behauptungen sind TF und müssen/werden aus der Einleitung verschwinden. Zumal es für diese wilden Behauptungen auch keine Quelle gibt. -- Plankton314 (Diskussion) 19:11, 27. Nov. 2012 (CET)

1. lies erstmal den ganzen artikel (natürlich gibt es implementationen, die vom ideal mehr oder weniger abweichen...)... 2. doch, genau das ist ziel des GC... 3. dass die einleitung für laien irgendwie doch verständlich ist, erkennt man daran, dass hier dauernd von leuten, die schon ihre meinung irgendwie gebildet haben, haltlos widersprochen wird... --Heimschützenzentrum (?) 19:18, 27. Nov. 2012 (CET)

GC ist in erster Linie

1. eine Form der automatischen Speicherverwaltung
2. eine Technik Fehler der manuellen Speicherverwaltung zu vermeiden
3. und erleichtert noch einen Haufen Sache in der Entwicklung.

Wenn da nun zufällig mehr oder weniger Speicher oder Rechenleistung anfällt, ist das schön - aber eben nur ein Nebeneffekt.

Im "GC Handbook" - das auch in der Literatur angegeben ist - steht es sinngemäß so drin. Falls du das nicht "zufällig" daheim rumliegen hast, schau auf deren Homepage in der FAQ oder im Preface vorbei: gchandbook.org -- Plankton314 (Diskussion) 20:09, 27. Nov. 2012 (CET)

1. steht ja schon drin... minimierung des speicheranspruchs... 2. korrektheit muss nicht explizit gefordert werden... 3. aufwand bei der entwicklung ist erwähnt... 4. die übrigen in der jetzigen einleitung erwähnten punkte, sind ebenfalls wesentlich und werden in den folgenden abschnitten präzisiert und mit quellen gestützt... 5. ich sehe also immernoch nicht, wieso genau welche formulierung in der jetzigen einleitung falsch (und darauf wollen wir uns bitte zuerst einmal konzentrieren... falls sie zu lang ist, können wir das ja später diskutieren...) sein könnte... --Heimschützenzentrum (?) 21:08, 27. Nov. 2012 (CET)

Sammlung der Kritikpunkte - bitte nicht (wieder) mit Allgemeinplätzen darauf antworten. Es sind immer noch dieselben wie damals...

• Fehlende OMA Tauglichkeit, Sätze sind zu kompliziert & missverständlich für jemanden der gar nicht weiss was GC ist (und auch für Leute, die sich gut damit auskennen)
• "bezeichnet im idealen Fall die Minimierung des Speicheranspruches" - grammatikalisch bezieht sich der "ideale Fall" auf "bezeichnet" und nicht auf "Minimierung des Speicheranspruches" --> muss zumindest auf "bezeichnet die Minimierung des Peicheranspruches im idealen Fall" umformuliert werden
• "Minimierund des Speicheranspruches eines Prozesses" - ist nicht Aufgabe der GC, sondern Konsequenz der GC. Die GC minimiert die unnötig im Speicher gehaltenen Objekte, deren Entfernung & Defragmentierung minimiert den Speicheranspruch des Prozesse
• "... die Minimierung des Speicheranspruches eines Prozesses, die ... während der Softwarentwicklung" - grammatikalisch bezieht sich das "die" auf die Minimierung des Speicheranspruches. Diese findet aber sicher nicht während der Softwareentwicklung statt.
• "ohne Aufwand stattfindet" - unter Aufwand kann man Entwicklungsaufwand oder auch CPU-Aufwand verstehen, GC ist weder im Entwicklungsaufwand (irgendwer hat ja den GC entwickelt) noch beim CPU-Aufwand bei 0
• "bieten sich in der Praxis die Freigabe oder Wiederverwendung nicht länger benötigter Speicherbereiche an" - klingt so als ob GC noch weitere Möglichkeiten hätte mit nicht länger benötigten Speicherbereichen umzugehen
• "Auch die Beseitigung externer Fragmentierung bietet sich an" - ein reiner Speicher-Defragmentierer ist kein GC, hier gehört das "auch" durch "zusätzlich" ersetzt
• "Beseitigung externer Fragmentierung" - da gehört zumindest das Wort "Speicherfragmentierung" rein, weil Fragmentierung selbst ist zu global
• "Zeit-Komplexität" "Speicher-Komplexität" - Theoriefindung, diese Worte existieren nicht & ich wüsste nicht was ich mir darunter vorstellen kann
• "Abweichungen vom Ideal" - welches Ideal? Dass die Zeit weniger komplex ist?

--Sebastian.Dietrich 23:37, 1. Nov. 2009 (CET)

du willst mich ohne Zweifel veralbern... deine punkte sind alle unfug... in aller kürze:

• konkret? vllt wenigstens 1 bsp? oder kommen die bei den anderen punkten?
• ist doch in ordnung... zuerst betrachten wir eben den idealen fall... dass es in wirklichkeit gar keinen idealen GC gibt, kommt dann ja am ende der einleitung...
• die folge der tätigkeit des GC ist die minimierung... von „aufgabe“ steht da doch gar nix... was soll dassn werden?
• doch... wenn man keine free/delete anweisungen coden muss, entfällt dieser aufwand bei der Softwareentwicklung schoneinmal (als direkte folge des GC einsatzes)... schreibst du doch selbst dauernd...
• ja, jedweder aufwand... der entwicklungsaufwand für den GC selbst hat ja nichts mit seiner späteren verwendung zu tun... und sowas wird auch durch die einleitung gar nicht angedeutet... „software-entwicklung“ bezieht sich na klar auf den „prozess“, auf den sich die minimierung bezieht...
• nö, wieso sollte es so klingen?
• zum hundertsten mal: doch!
• nein, „externe Fragmentierung“ ist ein feststehender fachbegriff der zur sicherheit (WP:OMA) auch verlinkt ist...
• nein, kompexitätstheorie ist n wichtiger teil der informatik... jeder dipl-inf weiß was gemeint ist und für die anderen ist es auch schon extra verlinkt... man könnte das noch spezieller verlinken... aber wozu?
• ach was! das meinst du doch nich ernst! das ideal, das wir im ersten satz beschreiben...

meine güte... das hat man dann davon... --Heimschützenzentrum (?) 23:28, 27. Nov. 2012 (CET)

hmmm, entweder gibt's hier massive sprachliche missverständnisse oder... jedenfalls sehe ich leider ebenfalls keinen der nun mehrfach vorgebrachten Kritikpunkt an der momentan Einleitungs-Fassung ausgeräumt. Die Bezuege sind unklar bis falsch, Fachterminie sind TF oder nicht eingeführt oder falsch verwendet (Komplexität... immer noch), nicht OMA-tauglich genug. falls kein Konsens gefunden werden dann muss eine Mehrheitsentscheidung her. gruesse Shaddim (Diskussion) 01:43, 28. Nov. 2012 (CET)

platzkomplexität, zeitkomplexität... wo ist da TF? oder wollen wir uns an dem bindestrich stören? oder wollen wir „speicher“ durch „platz“ auswechseln? wer „ideal“ nicht mit dem „idealen Fall“ ein paar sätze vorher (dem einzigen ideal, von dem die rede ist) zusammenbringen kann, der will eben nich anders... war sonst noch was? ich muss doch weiterhin die fachkunde oder ernsthaftigkeit der kritiker der jetzigen einleitung bezweifeln... nur weil 3 „informatiker“ eine abneigung gegen die verwendung von informatik-wörtern in einem informatik-artikel haben, ist das kein grund für einen edit... --Heimschützenzentrum (?) 07:11, 28. Nov. 2012 (CET)

Das ist Theoeretische-Informatik-Terminologie für abstrakte Algorithmen. Hier geht es 1. um reale Programme, 2. um eine OMA-taugliche möglcihst allgmeinsprachliche erklärte Einführung, 3. und, das ist das hauptproblem allg. in dieser Einleitung, die Bezeüge sind unklar, bezg sich diese Komplexität auf die Laufzeitkomplexität des GC selsbt oder des Programms oder über diese komische Platz- zeitformulierugn auf ne mischung von beiden? Shaddim (Diskussion) 11:09, 28. Nov. 2012 (CET)

1. reale programme lassen sich bei ordentlichem sw design selbstredend auf abstrakte algorithmen zurückführen... 2. komplexität passt dort auch in der „allgmeinsprachliche“n bedeutung... 3. wer sollte denn unterscheiden wollen/können zwischen der lahmheit des GC oder des programms insgesamt? und wozu? diese angeblichen mängel kommen mir alle so an den haaren herbeigezogen vor... besonders wenn ich das wort vermeidung nicht verwenden darf, aber der gleiche der es mir verbieten wollte, es dann an gleicher stelle wieder einfügt... und jetzt noch das... 4. kann man nicht mal einen kritikpunkt herausgreifen (den wichtigsten am besten) und den dann vernünftig begründen und nicht nur einfach immer „komisch“ und „schlichtweg“ schreiben (das sind ja immer nur so hohle behauptungen...)... --Heimschützenzentrum (?) 12:06, 28. Nov. 2012 (CET)

Okay, ich versuch mal kurz die paar Punkte rauszuheben, die mMn. in der Einleitung (für mich) missverständlich sind:

• "GC bezeichnet [...] die Minimierung des Speicheranspruchs": Klingt für mich, als ob man durch GC den verwendeten Speicherbedarf senken könnte. Das Programm verbraucht - bis auf Kleinigkeiten - den gleich Speicher.
• "ohne Aufwand": Denke ich zuerst an Rechenzeit/Komplexität.

Am meisten stört mich der fehlende Hinweis, dass es eine Form der dynamischen (halb-)automatischen Speicherverwaltung ist. Der Rest ist erstmal zweitrangig/Nebeneffekt.

Weiterhin würde ich sinngemäß die Formulierung aus dem GC-Handbook (dito) übernehmen. Was soll das überhaupt? In der Einleitung steht eine bis jetzt unbelegt Aussage, die sich auch nicht mit der angegebenen Literatur deckt. -- Plankton314 (Diskussion) 12:39, 28. Nov. 2012 (CET)

1. ohne GC hätte das Programm viel größere Ansprüche... insb. gilt das für fehlende Kompaktifizierung... 2. „"ohne Aufwand": Denke ich zuerst an Rechenzeit/Komplexität.“: ja und? ist doch ok... im idealen fall eben... erhöhte rechenzeit ist doch keine forderung an einen GC, sondern nur eine nebenwirkung, die wiederum so gering wie möglich sein soll... 3. zunächst einmal gehört der allokator streng genommen nich zum GC... also ne automatische Speicherverwaltung besteht aus dem GC und dem auf ihn abgestimmten Allokator... 4. die jetzige Formulierung müsste aufgrund ihrer Korrektheit sinngemäß mit der aus dem GC-Handbuch übereinstimmen... und ja (schon beantwortet) sie stimmt soweit zutreffend überein... 5. die jetzige formulierung ist also nach wie vor nicht ernsthaft angefochten... was sollen die dauernden, haltlosen wiederholungen? --Heimschützenzentrum (?) 13:58, 28. Nov. 2012 (CET)

Zu 1) Es gilt im Allgemeinen nicht, dass ein Programm ohne GC mehr Speicher benötigen würde. Darum ist das m. E. falsch. (Irgendwelche Spezialfälle, die noch dazu vom verwendeten Speichermodell und -management abhängen gehören in keinem Fall in die Einleitung.)

Zu 2) Eine GC kann zwangsläufig die benötigte Rechenzeit bzw. Komplexität nicht verringern. Allein schon durch den Verwaltungsaufwand. Das ist m. E. somit ebenfalls falsch.

Die aktuelle Formulierung ist falsch und hat auch nicht den gleichen Sinn wie in der angegebenen Literatur. Das wurde jetzt mehrfach auf verschiedene Art und Weise ausgeführt. Auch ist es primär eine Speicherverwaltung(stechnik) und keine Optimierung oder sonstwas.

Ich sehe im Detail genau die gleichen Probleme, die Benutzer:Sebastian.Dietrich alle aufgelistet hat.

 Kontra Die Einleitung ist nicht allgemeinverständlich oder allgemeingültig. Somit fliegt sie fliegt raus und wird durch eine sinngemäß der aus dem GC-Handbook ersetzt. -- Plankton314 (Diskussion) 14:36, 28. Nov. 2012 (CET)

1. es steht ja auch nicht in der einleitung, dass jedes programm ohne GC mehr speicher braucht als mit... das argument geht doch völlig an der einleitung vorbei... aber ganz klar ist, dass es programme gibt, die ohne GC (also mit einer speicherverwaltung, die nur aus einem allokator besteht) viel mehr speicher bräuchten, so dass dort eben ein einsparpotential besteht... die einleitung ist ja gerade völlig allgemein gehalten und geht zunächst gar nicht auf spezialfälle ein... 2. schonwieder falsch: es gibt programme, die mit einem reinen allokator irgendwann swap-space bemühen müssen und schließlich gar nicht mehr genug speicher haben (es gibt bekanntlich keine turingmaschine in der wirklichkeit...)... und nochmal: im idealfall erzeugt ein GC eben weder aufwand für den programmierer noch sonstwo... aufwand_erzeugung_ ist kein leistungsmerkmal des GC... 3. ich denke die diskussion ist völlig zerfahren und werde mal bei WP:3M nachfragen, falls da doch etwas falsches in der einleitung steht, was ich aufgrund der komischen diskussion nicht erkennen kann... --Heimschützenzentrum (?) 16:05, 28. Nov. 2012 (CET)

Warum verstehen die anderen wohl die Einleitung immer falsch. Kann ja wohl nur an den anderen liegen und nicht daran, dass die Einleitung verschrubelt ist und nur unter Mißachtung der deutschen Grammatik richtig verstanden werden kann. Solange Heimschützenzentrum keinen Beweis erkennen kann dass die Einleitung falsch ist, muss sie doch so bleiben wie jetzt --Sebastian.Dietrich ✉ 16:28, 28. Nov. 2012 (CET)

was ist das denn fürn argument? es sind doch nur 3, die bereits mehrfach komisch durch impulsives verhalten aufgefallen sind... alle anderen user ([8][9]) stören sich offenbar nicht an der einleitung... die gucken nich mal auf die disk... komisch, oder? :-) und ja: das ist hier keine malgruppe, wo jeder mal die einleitung reihum verhunzen darf... --Heimschützenzentrum (?) 07:45, 29. Nov. 2012 (CET)

Jaja schon klar - die schweigende Mehrheit ist natürlich für die Beibehaltung der Einleitung. Es war ja auch damals die schweigende Mehrheit für deine ursprüngliche Änderung der Einleitung ([10]) die du nach 2 Stunden und 3 Minuten "Diskussion" darüber am 1. November 2009 eingestellt hast. Mein Einspruch wenige Stunden danach steht immer noch und wurde jetzt von anderen bestätigt. Fazit: Verhunzen darf die Einleitung natürlich nur Heimschützenzentrum. --Sebastian.Dietrich ✉ 08:54, 29. Nov. 2012 (CET)

1. och nö... :-) 2. die uralte einleitung ging ja nun überhaupt gar nich mehr... 3. du warst warscheinlich mal wieder gebiast wie hulle, weil du GC aus beruflichen/monetären gründen so schön findest (bis heute... s. o.)... --Heimschützenzentrum (?) 09:03, 29. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:17, 7. Feb. 2013 (CET)

Vorschläge für die Neugestaltung der Einleitung

Zur aktuellen Einleitung gibt es eine Reihe von Kritikpunkten (siehe Diskussion:Garbage_Collection#Einleitung und Diskussion:Garbage_Collection#Einleitung_(schonwieda)) Bitte um eure Vorschläge zur Neugestalltung...

Aktuelle Einleitung

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik im idealen Fall die Minimierung des Speicheranspruches eines Prozesses, die sowohl während der Software-Entwicklung als auch während der Laufzeit ohne Aufwand stattfindet. Dabei bieten sich in der Praxis die Freigabe oder Wiederverwendung nicht länger benötigter Speicherbereiche an, die aber schon dem Prozess zugeteilt wurden. Auch die Beseitigung externer Fragmentierung bietet sich an. Bezüglich der Zeit- und Speicher-Komplexität gibt es mehr oder weniger deutliche Abweichungen vom Ideal.

•  Kontra Nicht allgemeinverständlich, verschrubelt und leicht misszuverstehen. Detelliertere Aufzählung der Kritikpunkte siehe oben --Sebastian.Dietrich ✉ 16:28, 28. Nov. 2012 (CET)
•  Kontra dito -- Plankton314 (Diskussion) 17:17, 28. Nov. 2012 (CET)
•  Pro ist nichts falsches dran, steht schon drin und die dauernden beschwerden sind allesamt unbegründet... --Heimschützenzentrum (?) 17:31, 28. Nov. 2012 (CET)
•  Kontra in dieser Form leider unverständlich bis irreführend.Shaddim (Diskussion) 18:01, 28. Nov. 2012 (CET)
•  Neutral. Ich verstehe nicht sofort, was mit ohne Aufwand stattfindet gemeint ist. Zudem Vorschläge:

  -die aber schon dem Prozess zugeteilt wurden "die zuvor dem Prozess zugeteilt waren"?

  -"bietet sich an" wird in zwei Sätzen wiederholt. Alternative: "Die GC setzt in der Praxis die Freigabe oder Wiederverwendung ... um"

  -"Bezüglich der Zeit- und Speicher-Komplexität gibt es mehr oder weniger deutliche Abweichungen vom Ideal. Mir gefällt Shaddims Formulierung unten besser (ungefähr so: "Automatische Speicherbereiniger können mit begrenzten Aufwand eine gute, wenn auch keine perfekte Bereinigung (Optimierung?) erzielen."). Halblaie Jesus Presley (Diskussion) 13:25, 29. Nov. 2012 (CET)

1. „ohne Aufwand stattfindet“ meint eben, „automatisch zur Laufzeit/Entwicklungszeit“ und „ohne zur Laufzeit alles andere zu behindern“... für den „idealen GC“ gilt dies sicherlich... missverständlich isses eigentlich nicht, find ich... 2. „zugeteilt waren“ hört sich so an, als wären sie es jetzt nich mehr, was aber falsch wäre... 3. ja, das war früher mal 1 satz, aber der war gewissen leuten zu lang, und da hab ich 2 sätze draus gemacht... :-) 4. das hört sich mir zu optimistisch an, da wir bei aktuellen GCs einen faktor 3 haben, was ich für widerlich (also un-gut) halte... *kicher* --Heimschützenzentrum (?) 13:37, 29. Nov. 2012 (CET)

Vorschlag von Shaddim

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Optimierung des Speicherbedarfs einer Software bzw. eines Prozesses. Hierbei wird versucht, zur Laufzeit nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren, um diese dann weiterverwenden zu können; manchmal wird auch versucht, verwendete aber zerstückelte Speicherbereiche zusammenzulegen. Auch wenn nicht-triviale Programme beliebig komplexe und unvorhersehbare Speicherverwendungsmuster über die Laufzeit haben können, können Automatische Speicherbereiniger mit einem begrenzten, vernünftigem Aufwand typischerweise eine gute, wenn auch keine perfekte Bereinigung erzielen.

•  Pro Gut verständlich, alleine den letzten Satz würde ich streichen bzw. anders formulieren "perfekte Bereinigung" im Sinne von "allen nicht mehr benötigten Garbage finden" können GCs schon --Sebastian.Dietrich ✉ 16:28, 28. Nov. 2012 (CET)
•  Kontra Falsche Definition, es ist keine Optimierung. Der Rest ist interessant zu wissen, gehört aber mMn. nicht in die Einleitung. -- Plankton314 (Diskussion) 17:19, 28. Nov. 2012 (CET)
  • Optimierung Unter einem Optimum (lateinisch optimum, Neutrum von optimus ‚Bester‘, ‚Hervorragendster‘, Superlativ von bonus ‚gut‘) versteht man das best erreichbare Resultat im Sinne eines Kompromisses zwischen verschiedenen Parametern oder Eigenschaften unter dem Aspekt einer Anwendung, einer Nutzung oder eines Zieles. Im Gegensatz dazu steht das Ideal, womit das beste Denkbare bezeichnet wird. Die Suche nach dem Optimum unter gegebenen Voraus- und Zielsetzungen nennt man Optimierung. -> Versuch des erreichens eines Ideals (ohne es zu erreichen) aufgrund von Randbedingungen. In unserme Fall aufgrund des gegrenzten Wissens den der GC hat bzw. der Randbedingung des begrenzten Aufwandes der durch den Garbage Collector betrieben werden kann. Ergo, die Optimierung fürht zu einem guten Ergebnis aber nicht zum perfekten/idealen Ergebnis. Das typische Szenarie bei Optimierungen (egal ob mathematische oder technische). gruss Shaddim (Diskussion) 18:11, 28. Nov. 2012 (CET)
•  Kontra im Allgemeinen kann der GC das Optimum nicht immer erreichen, so dass auch keine Optimierung stattfindet... unenzyklopädischer ausdruck... --Heimschützenzentrum (?) 17:31, 28. Nov. 2012 (CET)
•  Neutral ;P Shaddim (Diskussion) 18:01, 28. Nov. 2012 (CET)

Anpassung auf Basis der Kritik (-umstrittene Optimierung):

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Reduktion des Speicherbedarfs einer Software bzw. eines Prozesses. Hierbei wird versucht, zur Laufzeit nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren, um diese dann weiterverwenden zu können; manchmal wird auch versucht, verwendete aber zerstückelte Speicherbereiche zusammenzulegen (Defragmentierung). Auch für Programme welche zeitlich unvorhersehbare Speicherverwendungsmuster haben (Nichtdeterminismus), können Automatische Speicherbereiniger mit einem begrenzten, vernünftigem Aufwand typischerweise eine gute, wenn auch keine perfekte Bereinigung erzielen.

•  Kontra 1. externe Fragmentierung (EF) ist das richtige stichwort (defragmentierung ist hier völlig falsch... das hatte user:MrBurns schonmal falsch verstanden...)... 2. EF definiert sich aber durch freie bereiche zwischen belegten bereichen (das kommt aus „zerstückelt“ nich richtig raus, find ich...)... 3. Nichtdeterminismus ist viel zu POV, da es schließlich weltanschauliche fragen berührt und zudem sowieso egal ist, da eh niemand etwas vorhersagen kann... --Heimschützenzentrum (?) 11:20, 29. Nov. 2012 (CET)

(Externe) Fragmentierung ist das Problem, dass in dem halbsatz beschriebene Vorgehen ist die Lösung ("zusammenlegen"), die Defragmentierung. Sehe kein Problem. gruesse Shaddim (Diskussion) 12:00, 29. Nov. 2012 (CET)

mit einer VNA (also jeder übliche computer etc) und nem echtzeit-OS (oder kein OS, mikrokontroller) kann ich problemlos ein sich determinstish verhaltendes Programm schreiben. Dies ist kein metaphysisches-abstraktes Eigenschaft sondern ein real-existierende. Shaddim (Diskussion) 12:04, 29. Nov. 2012 (CET)

klick mal erstmal auf den von dir verlinkten artikel und dann reden wir weiter... lol --Heimschützenzentrum (?) 12:44, 29. Nov. 2012 (CET)

tja, das "Defragmentierung" auf "(Dateisystem-)Defragmentierung" verlinkt ist ein Problem der Verlinkung, nicht des allg. Informationstechn.-Konzepts "Defragmentierung". gruesse Shaddim (Diskussion) 13:57, 29. Nov. 2012 (CET)

vllt isses einfach nich der richtige begriff gewesen? --Heimschützenzentrum (?) 15:16, 29. Nov. 2012 (CET)

•  Kontra Finde ich immer noch viel zu umständlich formuliert. Auch die Nennung von Software/Prozess geht in beiden fällen mMn. am Ziel vorbei. Unter wiederverwenden verstehe ich ebenfalls zusammenlegen, redundant.

Und der letzte Satz erschließt sich mir leider garnicht. Falls du den bzgl. unserer gestrigen Diskussion über Determinismus eingefügt hast, haben wir uns falsch verstanden. -- Plankton314 (Diskussion) 11:29, 29. Nov. 2012 (CET)

Ok, die Idee ist die: reale Sohtware hat nicht triviale Speicherzugriffsmuster, bei explizitem Specihermanagment wird das wissen über die muster mitgegeben. Bei GC wird das Wissen darüber nicht explizit mitgegebn, deshalb muss sich die GC das Wissen über Logging und analyse verschaffen. Dies geschieht getaktet ("anhalten der Welt -> aufräumen -> weiter"). D.h. kann nicht beliebig lange dauern -> tradeoff aus optimalität und aufwand (häufigkeit und dauer in dem "anhalten der Welt zustand") anderseits ist damit der ablauf nicht mehr determinsitisch da der programmierer der software vorher nicht wissen kann wie die GC vorgehen wird -> verlust der echtzeitfähigkeit Shaddim (Diskussion) 12:00, 29. Nov. 2012 (CET)

•  Kontra, mit Tendenz zu neutral. In der Einleitung das weiterführende Konzept Determinismus zu erwähnen, ist unnötig verwirrend. Statt weiterzuverwenden fände ich freizugeben griffiger (sofern faktisch richtig). Bitte korrekte Zeichensetzung und Gross/Kleinschreibung auch im Vorschlag beachten. Halblaie: Jesus Presley (Diskussion) 13:05, 29. Nov. 2012 (CET)

2. Iteration auf Basis des Feedbacks:

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Reduktion des Speicherbedarfs einer Software bzw. eines Prozesses. Hierbei wird versucht zur Laufzeit nicht länger benötigte Speicherbereiche (engl. Garbage, für „Müll“) automatisch zu identifizieren, um diese dann freizugeben; manchmal wird auch versucht, verwendete aber zerstückelte Speicherbereiche (Fragmentierung) zusammenzulegen. 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 gewisser zusätzlicher Speicher- und Laufzeitoverhead und der Verlust der Echtzeitfähigkeit des deterministischen Laufzeitverhaltens.

Shaddim (Diskussion) 14:34, 29. Nov. 2012 (CET)

•  Kontra 1. die echtzeit„fähigkeit“ ist ja im allgemeinen nicht immer verloren, wenn die echtzeitbedingungen entspannt genug sind... 2. was soll daran besser sein als an der jetzigen einleitung? 3. beispiele für vorteile gehören nich in die einleitung... 4. „manchmal“? 5. „zerstückelte“? --Heimschützenzentrum (?) 15:16, 29. Nov. 2012 (CET)

zugeschärft, wieder determinismus. Elementare vor- und nachteile (Kerneigenschaften des Konzepts!) gehören sehr wohl in die einleitung. Zerstückelt ist intuitiv klar und nah genug an schärferen fachterminie -> OK. Die Motivation von GC sit nur "manchmal" defragmentierung -> scheint mir angemssen. gruss Shaddim (Diskussion) 15:47, 29. Nov. 2012 (CET)

1. sofern der GC deterministisch arbeitet, kann er doch keinen nicht-determinismus ins spiel bringen... *staun* 2. gibts überhaupt noch GCs ohne kompaktifizierung? 3. was ist an dem wort eigentlich so schlimm, dass es raus muss? *lol* --Heimschützenzentrum (?) 16:48, 29. Nov. 2012 (CET)

GC ist aus Sicht des Programms und Programmiers ist nicht vorhersehbar, der Programmierer kann nicht angeben es soll eine GC mit den und den Eigenschaften laufen, er weiss nicht was für eine GC laufen wird noch garantiert eine GC irgednwelche Laufzeit constraints. Auch wenn der Garbage collector in sich deterministisch funktioniert, auf die Software hat er einen nicht-deterministischen Einfluss. Dies kommt durch die "Parallelität" des GC, der entkoppelt und nicht-synchron zum Programm läuft und aufgrund eigener metriken irgednwann einen bereinigungslauf anwirft. Dieser Zeitpunkt besitzt immer zufallsfaktoren und ist nicht mit dem Programm synchronisiert. D.H. auch wenn 2 programmläufe taktgenau gleich ablaufen kann eine leicht versetzt GC dazu führen das einmal ein alloc fehlschlägt und einmal erfolgreich ist -> ein nicht-deterministische Funktionsverhalten. Das nicht deterministische laufzeitverhalten bezieht sich daruaf das ein laufender (oder zufälligerweise gerade nicht laufender) GC-Run die geschwindigkeit der programmausführung nicht-vorhersehbar beeinflussen kann. Shaddim (Diskussion) 17:16, 29. Nov. 2012 (CET)

das gilt aber doch auch für alle anderen teile des programms, die der programmierer nicht selbst getippt hat (und vielleicht auch für noch weitere...)... und nebenläufigkeit führt eben immer zu solchen syndromen... dennoch kommt nicht-determinismus erst durch zufällige benutzerinteraktion oder ähnliches (ein echter zufallszahlengenerator z. B.) ins spiel, weil der GC eben nich anspringt, wenn ein zufälliges ereignis eintritt... ich glaub, ihr verrennt euch (auch) da völlig... --Heimschützenzentrum (?) 17:50, 29. Nov. 2012 (CET)

Niemand sagt das GC die einzigste Quelle von nicht-determinismus ist, nur eine weitere derer man sich bewusst sein muss. Sagne wir ich will ein deterministische Steuerungsprogramm haben das harte echtzeitanforderungn erfüllen muss, dies ist möglich und kommt auch vor. Dann kann ich eben keine GC verwenden da selsbt wenn ich alles richtig mache, die GC mir meine harte Echtzeiteigenschaft zerstören kann ("weiche Echtzeitfähigkeit" könnte man erreichen). Dies ist eine der Gründe warum im Java Disclaimer explizit die Verwendung mit Atomkraftwerken verboten ist. Shaddim (Diskussion) 18:08, 29. Nov. 2012 (CET)

1. nicht-determinismus meint, dass aus dem gleichen zustand nicht unbedingt wieder der gleiche folgezustand hervorgeht... angenommen das programm und der GC und das OS sind in einem bestimmten Zustand, dann geht (deterministische algorithmen vorausgesetz) immer der gleiche folgezustand hervor... dass in einem multitasking system das endergebnis ein anderes sein kann, liegt jedoch daran, dass der zustand des systems ungeheuerlich umfangreich ist (caches, tastaturtreiber, benutzer an der tastatur, lesefehler beim swappen, ...)... 2. wat is n adomkraftwerk? --Heimschützenzentrum (?) 18:36, 29. Nov. 2012 (CET)

Eigentlich eine gute Bemerkung und Beobachtung, die "Nebenläufigkeit" des Garbage collectors ordnet GC eigentlich direkt bei den "parallelen Informationstechniken", mit allen bekannten Problemen, ein. D.h man könnte auch sagen "Da GC immer nebenläufig zum Programm sind, unterliegt deren Verwendung den bekannten Risiken und Eigenschafen aller parallelen Programmiertechniken". Shaddim (Diskussion) 18:17, 29. Nov. 2012 (CET)

das ist wieder so lang (besonders angesichts der bedeutung...)... --Heimschützenzentrum (?) 18:36, 29. Nov. 2012 (CET)

Bezüglich der Aussage, dass GC _nicht_ mit Echtzeitsystemen zusammenpasst möchte ich nur auf Real-Time Java hinweisen, mit dem es sehr wohl möglich ist weiche und harte Echtzeitanforderungen umzusetzen, ohne auf einen GC zu verzichten. Der GC arbeitet dann nur anders und garantiert nicht mehr, dass OutOfMemoryExceptions nur dann kommen wenn wirklich kein Memory mehr frei ist (sondern auch dann, wenn der GC innerhalb der Echtzeitanforderungen nicht mehr Speicher freigeben kann als benötigt wird). --Sebastian.Dietrich ✉ 10:46, 30. Nov. 2012 (CET)

•  Pro Gefällt mir. Wenns faktisch korrekt ist, Daumen hoch. Übrigens denke ich, ihr habt eigentlich schon alles besprochen. Letztlich glaube ich, dass alle Varianten durch Überarbeitung sehr informativ und verständlich sind. Gebt doch die aktuellsten Varianten zur Abstimmung frei - in der englischen WP gibt's dafür Proposals / Request for Comments. Weiß nicht, wie das auf de:WP gehandhabt wird. Hoffe, das ist jetzt nicht zu gönnerhaft von mir. 3/5-Laie Jesus Presley (Diskussion)

PS: Habe mir erlaubt, zwei Kommata einzusetzen. Weiterhin bin ich dafür, (engl. Garbage, für „Müll“) zu streichen. Wird im ersten Satz erwähnt, kann man ohne Abitur ableiten :). Jesus Presley (Diskussion) 19:24, 29. Nov. 2012 (CET)

Vorschlag von Plankton314

Garbage Collection ist eine Form der (halb-)automatischen Speicherverwaltung. Sie ist Teil des Laufzeitsystems - ggf. unterstützt durch den Compiler, das Betriebssystem oder die Hardware - und versucht [automatisch] nicht mehr verwendeteerreichbare Speicherbereiche eines Programms freizugeben oder wiederzuverwenden.

Moderne Garbage Collectors haben [praktisch] keinen negativen Einfluss auf die Laufzeit. In bestimmten Umgebungen kann sie sogar effizienter sein, als die manuelle Speicherverwaltung.

Typische Fehler, die bei der manuellen Freigabe auftreten, können damit vermieden werden (z. B. Speicherlecks, doppelte Freigaben, hängende Zeiger). Läuft der Garbage Collector im Hintergrund, ist der Programmablauf jedoch nicht mehr determiniert deterministisch. Dadurch ist dem Programm - speziell bei Objekten - nicht mehr bekannt, wann diese zerstört werden.

IMO sollten alle weiteren Erläuterungen erhalten bleiben, aber in nachfolgende Abschnitte ausgelagert und raus aus der Einleitung (gerade bzgl. Laufzeit, Fragmentierung, usw.).

Ich bin (wen wunderts) immer noch für meine Einleitung, da mir die anderen einfach zu umständlich bzw. an der Sache vorbei erscheinen. Wie gesagt, das oben ist ein Vorschlag und kann ja noch modifiziert werden. -- Plankton314 (Diskussion) 11:29, 29. Nov. 2012 (CET)

•  Kontra GC ist nicht eine Form sondern ein Teil einer Speicherverwaltungs-Methodik... kompaktifizierung fehlt... zu ausführlich... falsch: im allgemeinn gilt gerade nicht, dass der GC _keinen_ schädlichen einfluss hat... --Heimschützenzentrum (?) 17:31, 28. Nov. 2012 (CET)

•  Pro Das mit keinen negativen Einfluss auf die Laufzeit gehört aber nicht in die Einleitung, ist ausserdem umstritten. --Sebastian.Dietrich ✉ 17:56, 28. Nov. 2012 (CET)

Ach ja...

• "Form" oder "Teil der Methodik": das wird ja nicht so 1:1 in Stein gemeisselt
• Kompatifizierung: sicher kein Primärziel
• zu ausführlich: Ich zähle sechs Sätze. Das ist noch kurz für eine typische Artikeleinleitung.
• Schädlicher Einfluss: da steht "moderne" und ich habe inzwischen auch "i. A." durch "praktisch" ersetzt. Mal ehrlich, das sind doch alles irrelevante Kleinigkeiten, die durch leichte Umformulierung korrigiert werden können. -- Plankton314 (Diskussion) 17:50, 28. Nov. 2012 (CET)

punkt4 hat sich ja nun durch eine nachträgliche veränderung verschoben von falsche phraseologie zu POV (dafür fehlt uns doch gerade die quelle... steht doch oben irgendwo schon...)... und 5. WP:Einleitung fordert eine Zusammenfassung und da sind vor-+nachteile eben dabei, weil es so wichtig ist (besonders wenn man schon die vorteile aufzählt...)... --Heimschützenzentrum (?) 17:51, 28. Nov. 2012 (CET)

worauf stützt sich denn die these „Kompatifizierung: sicher kein Primärziel“? die Kompaktifizierung ist wohl ebenso komplex wie die suche nach toten objekten... benötigt kenntnis über die klassenreferenzen... also verspricht man sich davon wohl einiges... für mich ist Kompatifizierung der einzige grund über GC einsatz überhaupt nachzudenken... --Heimschützenzentrum (?) 17:55, 28. Nov. 2012 (CET)

 Neutral, wegen dieses Satzes "Moderne Garbage Collectors haben [praktisch] keinen negativen Einfluss auf die Laufzeit. In bestimmten Umgebungen kann sie sogar effizienter sein, als die manuelle Speicherverwaltung." der TF bzw. zu umstritten ist. Sonst wäre ich  Pro. Zu dem Satz: Denke man sollte im Gegenteil eher andeuten das GC niemals perfekt sein kann durch die sporadische Ausführung, also immer einen speicheroverhead hat + einen mehr oder minder grossen (oder vernachlässigbaren) rechenaufwandsoverhead. Sehr gut die Benennung des nicht-Determinismus. Shaddim (Diskussion) 18:01, 28. Nov. 2012 (CET)

wann ist denn ein Programmablauf, der von unvorhersagbaren Ereignissen und Nebenläufigkeit bestimmt ist, determiniert? manno! das ist doch nich euer ernst... --Heimschützenzentrum (?) 18:11, 28. Nov. 2012 (CET)

das ist ein typo (hoffe ich) Shaddim (Diskussion) 18:48, 28. Nov. 2012 (CET)

hä? wo? welches programm hat über kenntnis über irgendetwas? das ist doch auch murks... --Heimschützenzentrum (?) 19:51, 28. Nov. 2012 (CET)

hoffe dies ist gemeint gewesen: ist der Programmablauf jedoch nicht mehr deterministisch Shaddim (Diskussion) 21:31, 28. Nov. 2012 (CET)

In meinem u. g. Beispiel hatte ich eigentlich sogar die Determiniertheit im Sinn. Aber im Sinne des Programmflusses und der Allgemeingültigkeit ist wohl Determinismus eher angebracht. -- Plankton314 (Diskussion) 21:48, 28. Nov. 2012 (CET)

• Zu Undeterminiertheit: Nein, das ist kein Typo. Mit einer GC im Hintergrund ist ein Programm nicht mehr determiniert. Ich weiß nicht, was für transzendente Programme hier gemeint sind, die unvorhersagbaren Ereignissen unterworfen sind - und Nebenläufigkeit führt auch nicht automatisch zu Undeterminiertheit.

Die GC macht etwas im Hintergrund auf Objekten des Programmes ohne es darüber zu benachrichtigen. Dann ist der Programmablauf nicht mehr determiniert.

Beispiel: Das Programm wird von dem GC nicht benachrichtigt, wann genau die nicht mehr verwendeten Objekte wirklich zerstört und freigegeben wurden. Oder andersherum: Es ist nicht mehr bekannt, wann genau bspw. ein Destructor aufgerufen wird - oder wie lange ein Objekt im Hintergrund ggf. noch Daten senden kann.

• Zu dem von Benutzer:Shaddim bemängelten Satz

1. Steht es so in der GC-Handbook-FAQ. Ich bin mir gerade nicht mehr sicher, aber ich glaube im "GC Handbook (2011)" ebenfalls.
2. Gibt es - nach meinem Kenntnisstand - unzählige Benchmarks (v. a. Java, C++/##) die zeigen, dass eine "normale" Anwendung nicht unter GC leidet. Mit normal ist gemeint, dass keine zu spezialisierte oder exzessive Speicherallokation und -freigabe bzw. Objekterzeugung oder -zerstörung vorliegt.

Hab mir schon gedacht, dass dieser Punkt auf "Unwohlsein" stößt. Ich persönlich halte es in der Praxis für zutreffend - nach eigenem Wissen und Erfahrung - und würde es deshalb gern drinbehalten. Im Zweifelsfall recherchiere ich es nochmal.

-- Plankton314 (Diskussion) 20:40, 28. Nov. 2012 (CET)

In dieser indifferenten Form ohne auch nur Overhead anzudeuten mit mir nicht tragbar. Ich halte die ganze Overhead- und Effizienzdiskussion eigentlich auch für zu vertrackt für die Einleitung und würde dringend weglassen vorschlagen. Shaddim (Diskussion) 21:27, 28. Nov. 2012 (CET)

Explizites Memorymanagment verhindert zumindest keinen einen deterministische Ablauf (ala deterministische Neumann architektur) oder Echtzeittauglichkeit. Dies wird durch die sporadische und unvorhersehbare GC aushebelt. Transzendente Programmm? Unvorhersagbaren Ereignisse sind doch üblich in Software, Hardwareevents, User-interaktion... unvorhersehbare latenzen von netzwerkverbindungen. Shaddim (Diskussion) 21:39, 28. Nov. 2012 (CET)

1. es ist unsinn in der einleitung darauf hin zu weisen, dass das programm nicht informiert wird, dass ein bereits völlig aufgegebenes objekt endgültig zerstört wird... außerdem muss es nich jeder GC so halten (bei java gabs mal sowas wie softRefs... von da ist der schritt zu einem „dealloc-event“ auch nich mehr weit...)... außerdem sind äußere ereignisse meist unvorhersehbar, so dass der programmablauf meist unverhersagbar ist... 2. overhead ist ein wesentlicher aspekt und gehört in die einleitung... --Heimschützenzentrum (?) 21:44, 28. Nov. 2012 (CET)

Möchte meine Kritik noch weiter konkretisieren: "Moderne Garbage Collectors haben [praktisch] keinen negativen Einfluss auf die Laufzeit. In bestimmten Umgebungen kann sie sogar effizienter sein, als die manuelle Speicherverwaltung." In diesem Satz steckt auch zu viel OMA-untaugliches implizites Vorwissen: "modern" -> "war früher anders" -> wie anders? nicht einschätzbar, wenn unwichtig dann weglassen. Für einen neulinge ist die Einordung von "praktisch" unmöglich. Wie verbreitet oder relevant sind diese "Umgebungen" (Kontexte?) -> subjektiv und nicht einschätzbar für den unbedarften leser. Wegelassen oder im besten falle auf eigenschaften eingehen die elementar jede GC betreffen unabhängig des Algos, Implementierung und Kontext. Das könnten aus meiner Sicht die Aspektese sein: eine GC betreibt zur Laufzeit eine Analyse (Aufwand undefinierter Höhe, typischerweise bewusst begrenzt) um fehelndes explizite gegebenes Wissen selbst zu gewinnen, diese analyse wird getaktete druchgeführt welche nicht beliebig oft sein kein um den aufwand zu begrenzen -> ergo ein kompromiss aus Perfektion und Aufwand. Shaddim (Diskussion) 10:17, 29. Nov. 2012 (CET)

"Läuft der Garbage Collector im Hintergrund, ist der Programmablauf jedoch nicht mehr determiniert ist. Dadurch ist dem Programm - speziell bei Objekten - nicht mehr bekannt, wann diese zerstört werden." -> verstehe nun was du damit meinst, verstehe dies als Sonderfall (unbekannte verzögerung bei programmende) oder Beispiel des Nicht-determinismus im Allgemeinen. (zB unbekannte verzögerung beim freigeben von speicher WÄHREND das programm weiterläuft -> vielleicht oder vielleicht auch nicht Out-of-memory beim nächsten allokieren -> nichtdeterministisch) Shaddim (Diskussion) 12:17, 29. Nov. 2012 (CET)

"speziell objekte" ist unnötig. Vorschlag: "Läuft ein Garbage Collector im Hintergrund, ist der Programmablauf nicht mehr deterministisch und Reproduzierbar. Da nicht mehr absehbar ist wann genau eine Ressource wieder verfügbar wird, können sukkzessive Ausführungen des gleichen Programms jedesmal unterschiedl. Laufzeitverhalten haben." Shaddim (Diskussion) 12:23, 29. Nov. 2012 (CET)

•  Kontra Zu knapp, dennoch (dadurch?) nicht wirklich WP:OMA. Bei mir entsteht Verwirrung über den Unterschied zw. halbautomatischer und manueller Speicherfreigabe. Grammatisch unelegant. Bestehende Einleitung ist m.E. besser. Halblaie: Jesus Presley (Diskussion) 12:52, 29. Nov. 2012 (CET)

Das hatten wir schon. Die aktuelle Einleitung ist dem Konsens nach falsch. Die Speicherfreigabe ist automatisch, nur die Verwaltung halbautomatisch, weil die Anforderung manuell erfolgt.

Außerdem geht Korrektheit vor grammatikalischen Schönheitsoperationen. -- Plankton314 (Diskussion) 13:56, 29. Nov. 2012 (CET)

•  Neutral (Edit). Könnte ich mir nach mehrfachem Durchlesen doch vorstellen. Was sich Laien unter objektezerstörenden Programmen vorstellen, weiß ich nicht :). Aber man kommt recht nah an das Adjektiv deterministisch heran. Ach, Moment...: Dadurch ist dem Programm - speziell bei Objekten - nicht mehr bekannt, wann diese zerstört werden: Ohne "speziell bei Objekten" funktioniert der Satz nicht mehr. Jesus Presley (Diskussion) 19:42, 29. Nov. 2012 (CET)

•  Kontra Nicht allgemeinverständlich. Laufzeitsystem, Compiler, deterministisch, Zerstörung (Hilfe! Macht das meinen Computer kaputt?) [...] Das mag fachlich richtig sein, ich müsste erst aber die ganzen Blaulinks nachschlagen, um die Zusammenhänge annähernd zu verstehen. Im Gegensatz dazu kann ich mir unter Shaddims Vorschlag durchaus was vorstellen. -- 95.113.173.239 21:34, 29. Nov. 2012 (CET)

Dieser Artikel ist kein Lehrbuch sondern behandelt ein Thema der Softwaretechnik. Grundwissen kann vorausgesetzt werden. -- Plankton314 (Diskussion) 21:41, 29. Nov. 2012 (CET)

jetzt setzen wir also doch Grundwissen voraus? lol --Heimschützenzentrum (?) 22:23, 29. Nov. 2012 (CET)

Es ist offensichtlich durchaus möglich ist, das Ding allgemeinverständlich zu beschreiben. Daher halte ich das für keine ausreichende Begründung. Wikipedia ist kein Fachlexikon für Softwaretechnik, sondern soll von allen genutzt werden können. Das gehört zu einer Universalenzyklopädie dazu, komplizierte Sachverhalte möglichst einfach zu umschreiben. Mir ist natürlich klar, dass das nicht immer einfach ist, bin mir aber sicher, dass ihr mit etwas Abstimmung eine für alle Seiten verständliche und akzeptable Lösung finden könnt. -- 95.113.173.239 00:25, 30. Nov. 2012 (CET)

Kompromiss

@Shaddim: Wir haben in unsere (überarbeiteten) Einleitungen ja inzwischen fast das gleiche drinstehen (bzw. ich würde die zweite Hälfte deiner Einleitung auch gern übernehmen).

PS: Thema Determiniertheit: Ich denke, hier ist die nebenläufige GC abzugrenzen, also Details die eher in den weiteren Artikel gehören.

Ich schlage vor, wir konzentrieren uns auf den einzigen verbleibenden Unterschied: die grundsätzliche Definition (erster Satz).

Ist GC in erster Linie

1. "die automatische Reduktion des Speicherbedarfs einer Software bzw. eines Prozesses" (hilft also den Speicherbedarf zu senken)
2. "[eine] automatischen Speicherverwaltung" (hilft also erstmal Entwickler und Betriebssystem (oder wer auch immer den Speicher hergegeben hat))

-- Plankton314 (Diskussion) 22:55, 29. Nov. 2012 (CET)

Hallo Plankton314, ja lass uns eine gemeinsame Lösung bauen. Denke eine Einleitung die sagt was GC tut ist etwas besser verständlicher. Im zweiten Schritt sollt man dann nennen wie man sie einordnen kann. Vorschlag, wie wäre es so:

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik die automatische Reduktion des Speicherbedarfs einer Software bzw. eines Prozesses. Bei dieser Art der automatischen Speicherverwaltung wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben. Manche Automatische Speicherbereinigungen versuchen darüberhinaus auch noch verwendete aber zerstückelte Speicherbereiche (Fragmentierung) zusammenzulegen. [...]

gruesse Shaddim (Diskussion) 10:26, 30. Nov. 2012 (CET)

 Pro Super Vorschlag. Kleine Änderungsvorschläge:

• Warum nicht Speicherverwaltung und Reduktion in einem Satz - z.B. "... bezeichnet in der Softwaretechnik eine automatische Speicherverwaltung zur Reduktion des Speicherbedarfs einer Software... Dabei wird zur Laufzeit..."
• Es gibt GCs / Algorithmen mit Defragmentierung und welche ohne, daher sollte im letzten Satz nicht "manchmal" stehen, sondern "...freizugeben; darüberhinaus können GCs auch verwendete aber zertsückelte ..." --Sebastian.Dietrich ✉ 10:36, 30. Nov. 2012 (CET)

wäre ebenfalls eine sinnvolle Möglichkeit. Rückmledung bzgl. des irreführenden "manchmals" aufgegriffen. Shaddim (Diskussion) 11:09, 30. Nov. 2012 (CET)

Ich trau mich ja inzwischen schon fast nicht mehr zu fragen, weil es sich in letzter Zeit immer darum gedreht hat, aber...: Inwiefern hilft ein Garbage Collector beim Reduzieren des Speicherbedarfs? Okay, er hilft (etwas) bei Speicherlecks. Aber inwiefern kann man sagen, dass dadurch der benötigte Speicher eines Programms weniger wird?

Ansonsten bin ich mit den Vorschlägen einverstanden. -- Plankton314 (Diskussion) 11:58, 30. Nov. 2012 (CET)

Ja das ist sicherlich noch ein wenig verwirrend & sollte umformuliert werden. GC hilft dabei nicht mehr benötigten Speicher freizugeben, und somit den Speicherbedarf zu reduzieren (weil Speicherbedarf eines Programmes = benötigter und auch reservierter aber nicht benötigter Speicher) --Sebastian.Dietrich ✉ 12:19, 30. Nov. 2012 (CET)

tja, seufz, irgednwie alles missverständlich im richtigen (oder falschen) licht. ;P ...eigentlich wäre ich für "Minimierung" ... eine automatische Minimierung. Da gab es jedoch die Diskussion ob Minimierung das erreichen des Minimums impliziert oder nicht. Shaddim (Diskussion) 12:26, 30. Nov. 2012 (CET)

Grundsätzlich bedeutet Minimieren nicht, dass ein Minimum erreicht wird, denn dazu müsste (fast sicher) eines existieren.

Fügen wir doch einfach ein "versucht" ein, vllt. sind dann alle glücklich:

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik eine automatische Speicherverwaltung die versucht den Speicherbedarf eines Programms zu minimieren. Dabei wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben. Manche Automatische Speicherbereinigungen versuchen darüberhinaus auch noch verwendete aber zerstückelte Speicherbereiche (Fragmentierung) zusammenzulegen. [...]

-- Plankton314 (Diskussion) 12:45, 30. Nov. 2012 (CET)

jemand zu hause? bei endlich vielen speicherabschnitten von „fast sicher“ zu reden, kommt mir etwas komisch vor... können wir nich einfach schreiben, dass der ideale GC den speicherbedarf minimiert? --Heimschützenzentrum (?) 13:41, 30. Nov. 2012 (CET)

nein, auch ein nicht-idealer GC minimiert den speicherbedarf, er erreicht/erzielt nur nicht das Minimum. Shaddim (Diskussion) 13:55, 30. Nov. 2012 (CET)

komisch... ist das wort minimieren nicht vllt doch missverständlich (minimum ist ja auch nicht einfach nur etwas, das kleiner ist als etwas anderes, sondern das kleinste...)? fast ganz schön oft? hum? --Heimschützenzentrum (?) 14:10, 30. Nov. 2012 (CET)

Das war leider etwas unglücklich von mir ausgedrückt. Naja, lassen wir das... -- Plankton314 (Diskussion) 18:33, 30. Nov. 2012 (CET)

Nein das stimmt schon so: das "Minimum" ist das kleinste, das Optimum. Die Minimierung ist der Vorgang des Versuches dieses Minimum zu erreichen, was aber nicht gelingen muss. Auch wenn es nicht gelingt ist trotzdem eine Minimierung passiert, nur eben keine perfekte. Shaddim (Diskussion) 21:44, 30. Nov. 2012 (CET)

 Pro Gute Version, volle Unterstützung. Shaddim (Diskussion) 13:59, 30. Nov. 2012 (CET)

Ich denke das "versucht" reicht nicht, da es um "Speicherbedarf minimieren" geht - und zweiteres ist missverständlich. Wie wärs mit folgender Verkürzung: --Sebastian.Dietrich ✉ 14:25, 30. Nov. 2012 (CET)

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik eine automatische Speicherverwaltung die, zur Laufzeit nicht länger referenzierte Speicherbereiche automatisch identifiziert und freigibt. Manche Automatische Speicherbereinigungen versuchen darüberhinaus auch noch verwendete aber zerstückelte Speicherbereiche (Fragmentierung) zusammenzulegen. [...]

Eigentlich ist jetzt das erste "versucht" nicht mehr nötig, da sie das ja tut (--> corr) --Sebastian.Dietrich ✉ 14:29, 30. Nov. 2012 (CET)

dass nur eine echte teilmenge der „nicht länger benötigte[n] Speicherbereiche“ von GC betroffen ist, wollen wir verschweigen, weil GC so schön ist, wenn man mal von dem ganzen zusätzlichen aufwand absieht? oder wie? soll es ne schöne werbebrochûre für n kostenpflichtigen GC kursus werden? --Heimschützenzentrum (?) 16:52, 30. Nov. 2012 (CET)

Ein GC gibt selbstverständlich bei Bedarf alle nicht länger benötigten Speicherbereiche frei. --Sebastian.Dietrich ✉ 21:57, 30. Nov. 2012 (CET)

nich schon wieder! satz von rice? wir denken uns einfach mal eine schleife, die nicht trivial erkennbar niemals abbricht und munter ergebnisse in einem vector sammelt: kann ein GC diesen vector aufräumen? nein! das programm endet durch speichermangel... --Heimschützenzentrum (?) 22:13, 30. Nov. 2012 (CET)

I-Typferlreiterei. Ersetze "nicht benötigte" durch "nicht referenzierte". --Sebastian.Dietrich ✉ 22:36, 30. Nov. 2012 (CET)

jetzt haben wir GC auf konservative GCs eingeschränkt, was auch ne zumutung ist... solche hämmer sind in der jetzigen einleitung jedenfalls nich... --Heimschützenzentrum (?) 22:54, 30. Nov. 2012 (CET)

Ok ok - du hast recht (obwohl du vermutlich nicht-konservativ meintest) - konservative GCs geben "nicht zuverlässig alle nicht-referenzierten Objekte" frei. D.h. nur nicht-konservative GCs geben bei Bedarf alle nicht länger benötigten Speicherbereiche frei. Die Einleitung stimmt aber trotzdem, da dort nichts von "alle" steht. --Sebastian.Dietrich ✉ 23:26, 30. Nov. 2012 (CET)

fortsetzung: s. unten... --Heimschützenzentrum (?) 09:01, 1. Dez. 2012 (CET)

Hmm, denke ein hinweis auf den approximativen Charakter (nicht-perfekt) über "versucht" oder "minimierung" ist notwendig. Die Formulierung darüber beinhaltet diesen notwendigen hinweis. Shaddim (Diskussion) 17:20, 30. Nov. 2012 (CET)

 Pro für beide. Nehmt was ihr wollt. Wir sollten aber nach dieser ewig langen Diskussion nicht vergessen die anderweitigen Beschlüsse/Erkenntnisse/usw. in den verbleibenden Artikel einzuarbeiten. -- Plankton314 (Diskussion) 18:33, 30. Nov. 2012 (CET)

besonders aber mein dickes  Kontra sollte nicht vergessen werden... --Heimschützenzentrum (?) 21:14, 30. Nov. 2012 (CET)

Begründung? --Sebastian.Dietrich ✉ 21:57, 30. Nov. 2012 (CET)

1. es ist einfach falsch... 2. keine änderung ohne guten grund... die „eigene“ formulierung drinstehen haben zu wollen, ist kein guter grund... --Heimschützenzentrum (?) 22:13, 30. Nov. 2012 (CET)

1. was ist falsch? 2. ist hier irrelevant - siehe oben. --Sebastian.Dietrich ✉ 22:29, 30. Nov. 2012 (CET)

1. s. o... 2. immernoch falsch... 3. auch nachdem du den „kompromiss“ „nachgebessert“ hast... --Heimschützenzentrum (?) 22:54, 30. Nov. 2012 (CET)

Geh bitte sag mir deine Kritikpunkte nochmals. Oben sehe ich nur, dass du das "Minimieren" kritisierst. Das gibts aber in meinem Vorschlag nicht mehr. --Sebastian.Dietrich ✉ 23:30, 30. Nov. 2012 (CET)

der „kompromiss“ schränkt den artikel auf eigentlich veraltete _konservative_GCs_ ein, denn: „nicht referenziert“ hat ja noch nichts mit „nicht von ganz bestimmt aktiven objekten erreichbar“ zu tun... die einleitung soll den artikel aber zusammenfassen und nicht einen kleinen ausschnitt zeigen... außerdem muss GC ja gar nicht unbedingt überhaupt den referenzgraphen analysieren, weil es ja vllt noch andere wege gibt... --Heimschützenzentrum (?) 07:26, 1. Dez. 2012 (CET)

Du verwechselst schon wieder konservative GCs mit nicht-konservativen. Hab dich aber trotzdem verstanden. GC versucht also lt. Dir einfach nur irgendwie Speicher freizugeben, weder "nicht benötigt" darf vorkommen (weil "benötigt" zu schwammig ist), noch "nicht referenziert" (weil "referenziert" zu speziell ist). Für dich wäre also ein gültiger GC auch z.B. ein Swapping Mechanismus (schmeisst benötigten/refrenzierten Speicher raus und lädt ihn bei Bedarf wieder rein)? --Sebastian.Dietrich ✉ 08:42, 1. Dez. 2012 (CET)

1. nein, ich meine _konservative_ GCs (die def. im artikel ist tendenziell falsch, denn: auch ein bloßer referenz-zykel _referenziert_...)... 2. „benötigt“ ist eine eigenschaft, die man nicht so leicht feststellen kann (und in einigen fällen eben nicht einmal ein mensch... 3. swapping verringert doch nicht den anspruch eines prozesses, denn: ein load und die seite ist schon wieder da... 4. für mich minimiert ein idealer GC den anspruch und ein realer GC weicht vom ideal eben ab... 5. ist da etwa irgendetwas strittig? --Heimschützenzentrum (?) 09:01, 1. Dez. 2012 (CET)

Letzter Stand

Version Plankton314 12:45, 30. Nov. 2012 (CET)

Die Garbage Collection (kurz GC, vom englischen garbage collection, wörtlich: „Müllabfuhr“, auch Automatische Speicherbereinigung oder Freispeichersammlung genannt) bezeichnet in der Softwaretechnik eine automatische Speicherverwaltung die versucht den Speicherbedarf eines Programms zu minimieren. Dabei wird zur Laufzeit versucht, nicht länger benötigte Speicherbereiche automatisch zu identifizieren, um diese dann freizugeben. Manche Automatische Speicherbereinigungen versuchen darüberhinaus auch noch verwendete aber zerstückelte Speicherbereiche (Fragmentierung) zusammenzulegen. [...]

Ich möchte nocheinmal für diese Variante werben weil ich denke sie am ehesten das Potential für ein Agreement aller Beteiligten hat, auch weil sie im Unterschied zur letzten Variante den approximativen Charakter der GC deutlich genug nennt. Vorteile die in dieser Version sehe: "Benötigter Speicher" ist intuitiver klarer als "referenzierter". Das Konstrukt "versucht [...] zu minimieren" -> bildet den approximativen Charakter ab, damit ist auch die von Heimschützenzentrum bemängelte potentielle Schwierigkeit eingebracht/angedeutet, das es unklar zu entscheiden sein kann was den zur Laufzeit "benötigter" Speicher ist. Shaddim (Diskussion) 12:16, 1. Dez. 2012 (CET)

Das mit "benötigter Speicher" stimmt ja im Grunde auch. Genau das wird versucht.

Ob dazu über die Referenzen gegangen wird o. ä., steht weiter unten im Artikel. Ich denke, wenn man ohne Vorwissen daherkommt, stellt das den Sinn klarer raus.

Nach dieser endlosen Diskussion, übernehme ich das jetzt als endgültigen Stand in die Einleitung. -- Plankton314 (Diskussion) 12:27, 1. Dez. 2012 (CET)

Wiedermal  Pro weil besser als davor. Was mich stört sind 1) die vielen "versucht" weils holprig zu lesen ist und missverständlich. Wir haben festgestellt, das diese "Versuche" nicht immer gelingen (wenn z.B. kein Garbage da ist) und der GC auch nicht immer allen Garbage finden kann (da nicht eindeutig ist, was Garbage ist), aber wo bitte noch steht in der WP in einer Einleitung "versucht" wenn etwas nicht in allen Fällen gelingt? Niemand geht davon aus, dass bei der Müllabfuhr jeder Dreck beseitigt wird, dennoch steht dort z.B. nicht "Mit Müllabfuhr oder schweizerisch Kehrichtabfuhr bezeichnet man generell den Versuch der Beseitigung von Abfall durch Spezialfahrzeuge in städtischer oder kommunaler Regie." und 2) das "deterministisch" (weils eine unnötige Verwendung eines noch dazu falschen Fachbegriffes ist) - warum nicht "vorhersagbar" --Sebastian.Dietrich ✉ 17:13, 2. Dez. 2012 (CET)

Ja, das in jedem Satz "versucht" drin vorkommt, stört mich auch ein bißchen. Mal überlegen, wie man das geschickter formulieren könnte. -- Plankton314 (Diskussion) 18:20, 2. Dez. 2012 (CET)

 Kontra² 1. man sollte schon klar machen, welches die idealen eigenschaften sind und wie und wie gut man die real erreicht... *rotfl* 2. das wort „deterministisch“ will ich im ganzen artikel nicht sehn... 3. die zeitkomplexität ist ohne zweifel höher, was sich aber vielleicht nicht negativ auf die gesamte laufzeit (z B wegen pausen) auswirkt... aber die CPU zyklen sind wohl zumeist erhöht (faktor 3 *grins*)... --Heimschützenzentrum (?) 18:00, 2. Dez. 2012 (CET)

1) ja, aber nicht unbedingt in der Einleitung (steht ja auch nicht beiMüllabfuhr und anderswo in der WP) 2) +1 3) ja verbraucht mehr CPU Zyklen (Faktor X würd ich sagen, 3 ist sicher in vielen Fällen viel zu niedrig, in anderen zu hoch) aber eben nicht Laufzeit. Darum nix für die Einleitung sondern Garbage_Collection#Leistungsfähigkeit... --Sebastian.Dietrich ✉

Zu 2: Das Wort nicht-deterministisch ist da korrekt, auch wenn das Programm deterministisch arbeitet und auch die Garbage Collection (bei letzterer bin ich mir nicht sicher, ob sie das tut, aber das ist egal). Wie kann das sein? Der Determinismus hat verschiedene Bezugssysteme. Das Programm arbeitet in sich deterministisch. Die Garbage Collection aber innerhalb des Gesamtsystems. Aus Sicht des Programms können zur selben Ablauf-Zeit unterschiedliche Dinge passieren - mal ist der Speicher weg, mal nicht - weil das System einen anderen Zustand hat. Noch praktischer formuliert: Wenn noch viel Hauptspeicher frei ist, gibt es für die GC keinen triftigen Grund, schnell viel Speicher leerzuräumen. Wenn es eng wird halt schon. --Eike (Diskussion) 22:08, 4. Dez. 2012 (CET)

ist determinismus (Algorithmus) (dahin wird weiter unter verlinkt) nicht doch irgendwie anders definiert? der garbage collector ist ja teil des programms also im selben bezugssytem... außerdem wäre dann ja jedes reale programm nicht-deterministisch, weil jederzeit außerhalb seines bezugssytems das programm beendet werden kann (z. B. durch Blitzschlag) oder auch nicht (z. B. weil der Blitz gar nicht oder ganz woanders einschlug)... *rotfl* aber schön, dass sich jetzt auch ein admin, der ich ja nun noch weniger wahrscheinlich bin, auf die seite der änderungs-willigen schlägt... jetzt müssen die beamten mir doch einfach gläuben... --Heimschützenzentrum (?) 23:20, 4. Dez. 2012 (CET)

Nein, die Determinismus-Definition passt schon. Das Bezugssystem des Programms kann nur das Programm selbst sein - mehr hat der Entwickler nicht in der Hand. Das Bezugssystem des Garbage Collectors sollte das Gesamtsystem sein, sonst kann er nicht sinnvoll Speicher verwalten - er muss wissen, wann's eng wird. (Ansonsten programmier einfach mal gegen einen Garbage Collector, dann weißt du schnell, was gemeint ist. Nimm Weak References.) --Eike (Diskussion) 08:01, 5. Dez. 2012 (CET)

1. hier scheint es komische vorstellungen vom GC zu geben... der GC ist in wirklichkeit einfach nur n thread der neben der eigentlichen nutzlast im selben prozess läuft... dabei ist die übliche speicherverwaltung des betriebssystems nicht umgangen worden... 2. und nochmal: reale speicherverwaltung (und besonders bereits schon realer programmablauf) brächte dann immer nicht-determinismus in jeden noch so deterministischen, aber real ausgeführten algorithmus, so dass der hinweis bloß verzerrend wirkt, und so dass der hinweis auf deterministische algorithmen weiter unten völlig falsch ist... 3. ich muss mich sehr über die komischen vorstellungen in der WP (jetzt auch noch über theoretische informatik) wundern... 4. gleich in die einleitung die postulierung eines nicht-deterministischen systems, in dem wir leben sollen, reinzumogeln, geht wegen WP:NPOV auch nich... 5. was ist hier bloß los??? :-) --Heimschützenzentrum (?) 08:26, 5. Dez. 2012 (CET)

Bin inhaltlich voll bei dir - aber bitte bitte hör endlich mit deinen Anschuldigungen in egal welche Richtung auf - das macht dein und unser Leben in der WP nicht besser. @Bezugssystem des GC ist nicht das Gesamtsystem, sondern der aktuell dem GC freigegebene Speicher (in Java zwischen Xms und Xmx). Dort kann kein anderer Teil des Betriebssystems rein, also liegt das Bezugssystem 100% in der Macht des GCs. Das ist dasselbe Bezugssystem wie das des Programmes (und wird nichtmal zwischen Programmen geshared). Nachdem GCs selbst deterministisch arbeiten (zumindest gibts keinen Grund es nicht zu tun), führt alleine die Verwendung eines GCs nicht zu nicht-deterministischen Programmen. Einzig das Zeitverhalten scheint nicht-deterministisch zu sein (da sich GC so wie alle Programme die CPU teilen). Dafür muss man das Bezugssystem für GC und alle Programme auf das Gesamtsystem erweitern & wiederum ist alles deterministisch. --Sebastian.Dietrich ✉ 08:44, 5. Dez. 2012 (CET)

Du kannst auch das Bezugssystem auf das Universum erweitern... Nein, Spaß beiseite: Als Programmierer kannst du mit einer Garbage Collection an manchen Stellen nicht vorhersagen, welchen Weg dein Programm gehen wird. Und das Gesamtsystem hast du nicht in der Hand. Aber wenn das ernsthaft umstritten ist, muss wohl doch die Quelle her. (WP:TF/WP:Q) --Eike (Diskussion) 08:53, 5. Dez. 2012 (CET)

In der Praxis hast natürlich recht, in der Theorie aber denke ich nicht. D.h. Konsens: Wir brauchen eine Quelle, die belegt, dass GC zu nicht-Determinismus führt. Solange wir die nicht haben bleibts draussen. --Sebastian.Dietrich ✉ 09:03, 5. Dez. 2012 (CET)

Du hast jetzt "nicht vorhersagbar" daraus gemacht - was genau das ist, was ich mir gerade zu beweisen vorgenommen hatte. Wir sind uns also einig, dass der Programmablauf durch die Garbage Collection unter Umständen nicht vorhersagbar ist? Kann es sein, dass dann nur der Link in der Einleitung falsch gesetzt war? Determinismus war verlinkt, aber Determinismus (Algorithmus) sollte verlinkt sein? --Eike (Diskussion) 10:14, 5. Dez. 2012 (CET)

Das scheint mir doch auch so. -- Plankton314 (Diskussion) 10:20, 5. Dez. 2012 (CET)

Ja so ist es. Aber: Jeder Programmablauf ist auch ohne GC in der Praxis zeitlich nicht vorhersagbar (wegen Ressourcenteilung der CPU). Schreib einen einfachen Benchmark in C und du wirst sehen, dass er manchmal ein paar ms länger oder kürzer braucht. Sobald mehrere Threads laufen ists noch schwieriger (noch mehr Ressourcenteilung). GC lauft in einem Thread. In der Theorie sind sie aber alle deterministisch (Determinismus (Algorithmus)) solange keine Zufälligkeiten reinkommen. Determinismus ist genau definiert, "nicht vorhersagbar" kommt auf das Wissen an. Von mir aus kann der Halbsatz gerne ganz weg (weil das Zeitverhalten eines GCs nicht soooo wichtig ist, dass es in die Einleitung gehört) - für Determinismus (Algorithmus) brauchts aber auf jeden Fall Belege. --Sebastian.Dietrich ✉ 10:29, 5. Dez. 2012 (CET)

Ich denke, da muss man genauer hinschauen.

Der zeitliche Ablauf ist bei einem deterministischen Programm vorhersagbar, in dem Sinne, dass die Schritte die aufeinanderfolgen vorhergesagt werden können.

Es ist korrekt, dass die Zeitpunkte beim Multitasking nicht vorhergesagt werden können. Determinismus bezieht sich hier jedoch nicht auf die Zeitpunkte sondern die Programmzustände.

Der wichtige Punkt daran ist m. E. (und darum steht es auch in der Einleitung), dass nicht vorhergesagt werden kann, wann mit einem Objekt verbundene Ressourcen wieder freigegeben werden. Z. B. ist es einem Java-Programm nicht bekannt, wann eine Datei die über ein Datei-Objekt geöffnet wurde geschlossen wird, falls nicht explizit close() aufgerufen wird.

Ich möchte in diesem Zusammenhang nochmals auf den Abschnitt Garbage_Collection#Nicht-deterministisches_Laufzeitverhalten_und_Finalisierung hinweisen, wo dieser Zusammenhang erklärt ist (oder zumindest versucht wird zu erklären).

Und wie ich bereits unzählige Male geschrieben habe, ist das nicht-deterministische Laufzeitverhalten in der angegebenen Literatur beschrieben. Weiterhin kann es in verschiedenen Lehrbüchern zu GC nachgelesen werden. -- Plankton314 (Diskussion) 10:37, 5. Dez. 2012 (CET)

(BK) Es geht mir nicht um zeitlich nicht vorhersagbar. Unter Umständen ist es inhaltlich nicht vorhersehbar. Nimm an, du hast große Datenmengen und kannst die nicht alle in den Hauptspeicher zwingen. Dann nimmst du bei .NET WeakReference (ich weiß nicht, inwieweit das auch in anderen Sprachen existiert), und fragst, wenn du die Daten brauchst, ob sie noch vorhanden sind oder ob du sie neu (Datenbank, Festplatte oder was auch immer) besorgen musst. Du weißt vorher nicht, welchen Weg das Programm gehen wird, weil du nicht wissen kannst, ob die Garbage Collection zugeschlagen hat oder nicht.

Ich hatte genau so einen Fall in einem Unit-Test, der mal rot und mal grün war. Deshalb "überrascht" mich die Diskussion ein wenig.

--Eike (Diskussion) 10:39, 5. Dez. 2012 (CET)

Das ist jetzt schwierig, weil es mMn. ein Sonderfall ist: schwache Referenzen werden vom GC (i.d.R.) beim Aufräumen nicht berücksichtigt. Im englischen Artikel wird das auch beschrieben. -- Plankton314 (Diskussion) 10:44, 5. Dez. 2012 (CET)

Der Sinn der WeakReferences ist es, dass sie abgeräumt werden können (aber nicht müssen). Außerhalb solcher Fälle sehe ich keinen Nicht-Determinismus. Wenn ein Programm alle Referenzen, die es braucht, festhält, und alle, die es freigegeben hat, nie wieder berührt, dürfte das Ergebnis deterministisch sein. Gegenbeispiele sind willkommen.

Aber unabhängig davon beweist das Beispiel IMHO, dass man den Ablauf des Programms unter Nutzung einer Garbage Collection nicht in jeden Fall vorhersagen kann.

--Eike (Diskussion) 10:50, 5. Dez. 2012 (CET)

Siehe oben beschriebenes Datei-Beispiel. Oder soll ich es ausführlicher beschreiben? -- Plankton314 (Diskussion) 10:55, 5. Dez. 2012 (CET)

Du hast Recht, das ist das bessere Beispiel. Ist bei mir wegen des BK ganz untergegangen, der Beitrag. --Eike (Diskussion) 11:12, 5. Dez. 2012 (CET)

ehm? ob eine datei „geschlossen“ ist oder nicht spielt ja wohl sowas von keine rolle... wichtig ist allenfalls, dass nicht ein prozess/thread einen ge-dirty-ten buffer hat, während n anderer prozess/thread versucht die datei an derselben stelle zu lesen... das durcheinander, das dadurch entsteht kann, liegt aber weder an GC noch an nem close zu ner unbekannten zeit, sondern allenfalls an nem ungeeigneten sperrprotokoll... --Heimschützenzentrum (?) 12:19, 5. Dez. 2012 (CET)

Ehrlich gesagt glaube ich nicht, dass es lohnt, hier weiter mit dir zu diskutieren. Wenn eine Datei noch nicht geschlossen ist, kann sie häufig von einem anderen oder demselben Programm nicht geöffnet werden. Und es kann passieren, dass die Daten noch nicht vollständig rausgeschrieben sind. --Eike (Diskussion) 12:26, 5. Dez. 2012 (CET)

1. häufig? :-) 2. offene datei und r/w lock sind unterschiedliche paar schuhe... und wer das lösen von sperren vom GC erledigen lässt, soll sich >100km von mir entfernt aufhalten, falls er/sie noch andere komische ideen bekommt... GC kümmert sich nicht allgemein um alle betriebsmittel (das stand da mal vor etwa 40 monaten...)... 3. dirty „read“, ist auch n ganz normaler designfehler, der nicht auf GC-sprachen beschränkt ist... 4. und was soll das bitte alles mit determinismus zu tun haben? was ihr hier aufzählt sind alles nur designfehler, die mit und ohne GC auftreten können... --Heimschützenzentrum (?) 12:40, 5. Dez. 2012 (CET)

Und warum "soll sich >100km [...] entfernt aufhalten", "wer das lösen von sperren vom GC erledigen lässt"? Richtig - weil Garbage Collection nicht deterministisch ist. Und ob du das jetzt verstehen willst oder nicht, zwischen uns ist dazu hier EOD. --Eike (Diskussion) 12:58, 5. Dez. 2012 (CET)

na klar ist GC deterministisch... bloß zumeist ungeeignet... besonders ungeeignet zur verwaltung von sperren... wenn ich meine ausbildungseinrichtung ärgern will, sag ich lieber, dass Prof. Müll die eine oder andere vorlesung von ner assistentin lesen lies, oder dass die cand.-ing.s ganz ganz schlimm Herpes hatten... *ihhhhgittigittigitt* von mir aus brauchen wir darüber nich zu diskutieren... --Heimschützenzentrum (?) 13:13, 5. Dez. 2012 (CET)

ich muss mich sehr über user:Plankton314 und user:eike_sauer wundern... offenbar verwechseln beide „au backe! ist das schwierig“ mit „das ist nicht-deterministisch“... schön ist aber wieder einmal zu sehen, dass user:Sebastian.Dietrich für eine version ist, die näher an meinem vorschlag ist... wo wir gerade dabei sind: wäre „komplexität“ (HK:13) nicht vielleicht doch WP:OMA-konformer als „overhead“ (HK:20)... nur mal son gedanke... :-) --Heimschützenzentrum (?) 10:39, 5. Dez. 2012 (CET)

[ ] Danke für deinen inhaltlich wertvollen Beitrag. --Eike (Diskussion) 10:48, 5. Dez. 2012 (CET)

ehm? etwa nicht? war doch inhaltlich... ich mein: sieht doch sehr nach verwechslung aus, nachdem gewisse personen aus der theoretischen informatik raus und in die .NET-welt mit ihren bunten roten und grünen flecken am blidschirm voll rein sind... nur sone privat-theorie zur genese... --Heimschützenzentrum (?) 11:20, 5. Dez. 2012 (CET)

Sowohl die Begriffe "Overhead" als auch "Komplexität" wären hier im Informatik-Sinne auszulegen.

Der verwendete Begriff "Verwaltungsoverhead" beschreibt, dass die GC eben irgendetwas [bei der Speicherverwaltung und neben dem Programm] zusätzlich machen muss. Ob das jetzt zusätzlichen Speicher, Laufzeit oder beides kostet lässt sich nicht allgemein sagen. Das hängt von vielen anderen Faktoren ab.

Die Komplexität ändert sich dadurch nicht zwangsläufig - ich würde sogar so weit gehen und sagen, dass sie sich in keinem Fall nennenswert ändert. -- Plankton314 (Diskussion) 10:55, 5. Dez. 2012 (CET)

Wenn man herkömmliches C++ mit C# vergleicht, würde ich behaupten, dass trotz zusätzlichen Overheads die Komplexität für den Programmierer sinkt. Also... OMA-tauglich ausdrücken ist was Feines, aber es muss schon inhaltlich passen. --Eike (Diskussion) 11:14, 5. Dez. 2012 (CET)

Mit "Komplexität" bezog ich mich auf die Zeitkomplexität. Im Sinne von Programmieraufwand hast du natürlich recht. -- Plankton314 (Diskussion) 11:55, 5. Dez. 2012 (CET)

na dann... ...hast du na klar immernoch unrecht... --Heimschützenzentrum (?) 12:19, 5. Dez. 2012 (CET)

1. zur komplexität: compact: schonmal linear in der größe des speicherabschnitts (dazu kommt noch eine suche nach einem freien platz...)... GC-free: son eingefärbter graph hört sich irgendwie komplizierter an, als n 0-bit in ner block-liste zu suchen/toggle-n... 2. aber mir kann es ja egal sein, weil: ich bin für die änderungen komplett nicht verantwortlich... --Heimschützenzentrum (?) 11:20, 5. Dez. 2012 (CET)

Haben wirs?

Können wir das jetzt erl.en? -- Plankton314 (Diskussion) 14:45, 5. Dez. 2012 (CET)

ihr habt's... ...ziemlich kaputt gekriegt... :-) wie wär's mit nem revert auf mitte november? --Heimschützenzentrum (?) 18:49, 5. Dez. 2012 (CET)

Das mit dem Determinismus scheint mir abgehakt, falls Sebastian keine Einsprüche mehr hat. Odre meinst du jetzt die Diskussion über die gesamte Einleitung? --Eike (Diskussion) 21:45, 5. Dez. 2012 (CET)

Ich verstehs immer noch nicht. Nehmen wir nur das File Beispiel: File wird geöffnet und erst bei finalize() (was man ja nicht machen soll) geschlossen --> File wird irgendwann geschlossen (dann wenn der GC läuft) oder auch nie explizit (wenn vorher ein System.exit() kommt). File wird im selben Thread irgendwann später wieder geöffnet --> geht manchmal durch, manchmal nicht - das Programm ist also nicht vorhersagbar / deterministisch.

Frage: Wurde das Programm durch den GC nicht vorhersagbar / deterministisch? Nein, sondern deshalb, weil der GC nebenläufig lief. Das Beispiel oben kann man auch ohne GC einfach mit 2 Threads ohne GC nachstellen (Thread 1 öffent und started Thread 2 zum Schliessen. Thread 1 öffnet wieder --> geht manchmal durch, manchmal nicht).

Sobald externe Ressourcen (i.e. Ressourcen die nicht 100% in der Kontrolle des Prozesses sind) involviert sind kann jedes Programm (ohne GC und ohne Multithreading) nicht vorhersagbar / deterministisch werden. z.B: öffne File geht nur dann durch, wenn File vorhaden. Oder wenn for x=1 to 1Mio länger als 1ms dauert dann mach das, ansonsten mach was anderes

Fazit: Zugriff auf mit anderen Programmen geteilte Ressourcen (Files, CPU, ...) machen ein Programm nicht vorhersagbar / deterministisch. Multithreading ist nur deshalb nicht vorhersagbar / deterministisch, weil es auf so eine Ressource (CPU) ankommt. GC nur dann wenn Multithreaded --> Nicht-Determinismus nix für die Einleitung in GC, da keine Eigenschaft der GC sondern nur weil Multithreading durch CPU bestimmt ist. Kann gerne weiter unten erwähnt werden aber eben nix für Einleitung. --Sebastian.Dietrich ✉ 09:06, 6. Dez. 2012 (CET)

Nein, dem kann ich mich nicht anschließen.

In der Praxis trifft diese Argumentation manchmal zu, allgemeingültig ist sie jedoch nicht. Es ist nicht nötig, dass der GC in einem parallelen Thread läuft um den Programmfluss nicht-deterministisch zu machen. Es genügt, wenn der GC synchron bei jedem Freigeben aufgerufen wird und dann bspw. je nach freiem Speicher entscheidet. Das hat dann nichts mit dritten (gemeinsam genutzten) Ressourcen zu tun.

Determinismus im Zusammenhang mit dem GC ist - wie es auch im Artikel steht - ein großes Thema bei Echtzeit-Anwendungen.

Und es ändert nichts daran, dass es dazu durch die Verwendung des GC kommt. Ob durch Multithreading oder etwas anderes, ist eine Detail-/Implementationsfrage.

Ein weiterer wichtiger Punkt ist auch, dass damit RAII verletzt/nicht mehr möglich wird. Und ein Grund dies in der Einleitung zu erwähnen, ist die Verletzung genau diesen Idioms. -- Plankton314 (Diskussion) 10:49, 6. Dez. 2012 (CET)

Stimme Plankton314 zu, der Nicht-determinimus steckt schon tief im Grundkonzept von GC und sollte deswegen als Kerneigenschaft in der Einleitung erwähnt werden. Garbage collektion ist konzeptuell bewusst vom eigentlichen Programm ent- und ausgekoppelt, die Implementierungen (typischerweise nebenläufig) folgen dann nur dieser Idee. Shaddim (Diskussion) 12:08, 6. Dez. 2012 (CET)

*rotfl* ihr habt nicht-deterministisch falsch verstanden... lest doch mal den mittlerweile verlinkten artikel... --Heimschützenzentrum (?) 12:51, 6. Dez. 2012 (CET)

Welchen meinst du? -- Plankton314 (Diskussion) 13:23, 6. Dez. 2012 (CET)

na den über determinismus bei algorithmen natürlich... manno! --Heimschützenzentrum (?) 15:52, 6. Dez. 2012 (CET)

Okay, und jetzt? -- Plankton314 (Diskussion) 16:05, 6. Dez. 2012 (CET)

nichts gemerkt? dann lies noch meinen beitrag von heute hier um 15:52 (CET)... vielleicht hilfts ja... --Heimschützenzentrum (?) 16:16, 6. Dez. 2012 (CET)

Sorry, hilft auch nichts. -- Plankton314 (Diskussion) 16:21, 6. Dez. 2012 (CET)

dito *rotfl* jetzt ist alles eindeutig?! :-) --Heimschützenzentrum (?) 12:51, 6. Dez. 2012 (CET)

Wennst sagst "Es genügt, wenn der GC synchron bei jedem Freigeben aufgerufen wird und dann bspw. je nach freiem Speicher entscheidet." dann trifft das genauso auf jedes malloc oder new() zu. D.h. es gibt keine deterministischen Programme. --Sebastian.Dietrich ✉ 13:56, 6. Dez. 2012 (CET)

Ha! Das wäre theoretisch sogar möglich, wenn die Allokationsfunktion (z. B. malloc() oder new) über den GC Speicher holen. Das ist vllt. nicht bei den erwähnten Funktionen üblich, aber wenn ein GC läuft, wird AFAIK auch über den der Speicher reserviert. Dann wäre es möglich, dass der GC die Allokation nach hinten verschiebt, bis darauf zugegriffen wird oder er sonstwie Zeit findet. Hab irgendwo im Rahmen dieser Diskussion auch die Erwähnung dieser Möglichkeit gelesen. Ob das in der Praxis irgendwo implementiert ist, weiß ich nicht.

Die Speicherfunktionen der Standard-C-Bibliothek tun dies jedoch nicht.

Beudetet aber, dass theoretisch sowohl die Allokation als auch die Freigabe zu einem unbekannten Zeitpunkt geschehen könnten. -- Plankton314 (Diskussion) 14:05, 6. Dez. 2012 (CET)

(BK) Nein. Es geht hier nicht um die Möglichkeit, dass einfach nicht genug Speicher vorhanden ist. Die trifft ja jedes Programm. Es geht darum, dass eine (nicht nebenläufige) GC bei einem Aufruf entscheiden könnte, nach ihrem Gusto Speicher - anderen als den angeforderten! - freizugeben oder es bleiben zu lassen. Die GC würde dann weiterhin das Verhalten nicht-deterministisch machen, obwohl sie nicht nebenläufig ist. malloc oder new hingegen behandeln immer ausschließlich den geforderten Speicher-Block. (Es ist doch das Wesen der GC, sich selbständig um andere Speicherbereiche zu kümmern, ohne gefragt worden zu sein!) --Eike (Diskussion) 14:08, 6. Dez. 2012 (CET)

Oder so... :) Kann ich nur zustimmen, so hab ich die Frage erst jetzt beim durchlesen verstanden. -- Plankton314 (Diskussion) 14:12, 6. Dez. 2012 (CET)

GC synchron oder nebenläufig oder läufigpresto oder gusto oder nötig mag ja ganz interessant sein... aber: was soll das bitteschön mit determinismus zu tun haben? unstrittig ist doch, dass „nur definierte und reproduzierbare Zustände“ auftreten können, wenn ein ganzer Haufen deterministischer Algorithmen zusammen, sich einander beeinflussend und gleichzeitig ausgeführt wird... wie sollte also die Eigenschaft „deterministisch“ verloren gehen? weil es in der .NET-Java-4000€h^-1-Praxis ganz doll schwer realisierbar ist, die gleiche Ausgangssituation herzustellen? *kicher* das kann doch nicht wahr sein!? --Heimschützenzentrum (?) 15:52, 6. Dez. 2012 (CET)

Genau das ist die Frage:

1) Ist ein GC selbst deterministisch - oder muss er zwingenderweise nicht-deterministisch programmiert sein, dass er funktioniert?

2) Wenn er selbst deterministisch ist, wie kann er dann das (deterministische) Programm indeterministisch machen? Wenn durch Nebenläufigkeit, dann gilt das für alle nebenläufigen Programme. Wenn nicht durch Nebenläufigkeit, wie dann?

Eike meint ein GC ist deterministisch und kann auch wen er nicht nebenläufig ist das deterministische Programm indeterministisch machen. Wie soll das bitte gehen? --Sebastian.Dietrich ✉ 16:17, 6. Dez. 2012 (CET)

Weil dein Programm nicht weiß, was und vor allem wann der GC was macht - egal ob der deterministisch ist oder nicht. -- Plankton314 (Diskussion) 16:25, 6. Dez. 2012 (CET)

? was soll das denn mit „deterministisch“ zu tun haben? der Begriff „deterministischer Algorithmus” hat doch nichts mit Wissen zu tun, sondern damit: „nur definierte und reproduzierbare Zustände“... --Heimschützenzentrum (?) 16:48, 6. Dez. 2012 (CET)

Stell Dir vor du rufst die Methode getDate() auf, die dir das aktuelle Datum zurückliefert (vielleicht sogar noch in der aktuellen Zeitzone etc. Macht die das Programm indeterministisch? Anderes Beispiel: Stell die die Methode getEinkaufswagen() vor, die dir alle Artikel in deinem Einkaufswagen aus der DB lädt. Sie verwendet aber einen Cache. Cache ist am Anfang leer und kann auch später wieder leer sein (wenn z.B. deine Web-Session abgelaufen ist). Macht das das Programm indeterministisch? --Sebastian.Dietrich ✉ 17:01, 6. Dez. 2012 (CET)

Sind "alle Zwischenergebnisse innerhalb des Algorithmus immer gleich"? Offensichtlich nicht. --Eike (Diskussion) 17:11, 6. Dez. 2012 (CET)

Was willst damit sagen? Der Aufruf von getDate() oder getEinkaufswagen() macht ein Programm indeterministisch? Dann sind de facto alle Programme dieser Welt indeterministisch oder? --Sebastian.Dietrich ✉ 17:15, 6. Dez. 2012 (CET)

Bei getEinkaufswagen() würde ich ja sagen. Ich hätte jetzt gesagt, dass zumindest ein nicht vorhersagbarer Code-Pfad durchlaufen werden muss, dewegen kommt's mir bei getDate() auch komisch vor.

Aber würdest du mir zustimmen, dass das Verhalten von Garbage Collection dazu führt, dass Programme unsere Definition von Indeterminismus erfüllen?

--Eike (Diskussion) 17:28, 6. Dez. 2012 (CET)

Das Ende

Liebe verbleibende zwei Ungläubige,

Es wurde nun

• unzählige Male erklärt und Beispiele präsentiert,
• außerdem mehrfach auf ein gutes Lehrbuch verwiesen, indem sich ausführliche Erklärungen finden,
• von verschiedensten Seite die Argumentation bestätigt.

Wenn euch das Wissen fehlt oder es euch immer noch unverständlich ist, lest es bitte nach. Entweder hier oder besser in der Literatur.

Ich beende hiermit meinerseits diese längste Diskussion EVER.

Wenn ihr noch weitere Wochen die immergleichen Punkte durchkauen wollte, entfernt meinetwegen den Baustein. Von meiner Seite gibt es nichts mehr hinzuzufügen, was nicht bereits mehrfach wiederholt hier steht.

Erledigt-- Plankton314 (Diskussion) 16:44, 6. Dez. 2012 (CET)

kannst du mal aus dem verdächtigen buch zitieren? oder muss man es selbst kaufen? :-) --Heimschützenzentrum (?) 16:48, 6. Dez. 2012 (CET)

Verstehe nicht, warum du die Diskussion abbrichst. Wir sind inzwischen schon zu folgendem gemeinsamen Ergebnis gekommen:

1. GC selbst ist deterministisch
2. Nebenläufigkeit alleine macht ein deterministisches Programm nicht indeterministisch

--> es muss also eine andere Eigenschaft des GCs sein, der das Programm indeterministisch macht. Ihr seid uns da eine Erklärung schuldig. --Sebastian.Dietrich ✉ 17:01, 6. Dez. 2012 (CET)

Nein, zu dem Ergebnis sind wir nicht gekommen. Unter sind ja auch mehrere Quellen aufgelistet, die belegen, dass GC häufig nicht-deterministisch ist, unter anderem bei Standard-Java- und -.NET-Implementierungen. --Eike (Diskussion) 17:43, 6. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:17, 7. Feb. 2013 (CET)

Nicht deterministisches Verhalten der Programmumgebung

Eike hat ohne auf irgendwelche Diskussionsergebnisse Rücksicht zu nehmen wiedermal die Einleitung geändert in "... nicht deterministisches Verhalten der Programmumgebung": [11]. Die Quelle wurde wohlüberlegt unvollständig zitiert - es steht dort nirgendwo was von einem nicht-deterministisches Verhalten der Programm-Umgebung.

Meine Richtigstellung des Zitats wurde zurückgenommen mit dem dämlichen Hinweis, ich hätte sie nicht gelesen. [12] Ja sicher - Zitate kürzen und behaupten der andere hätte sie nicht gelesen. Das nächste Mal gibts Vandalismusmeldung.

Aber jetzt zu dem Punkt: Das Zitat lautet: Garbage Collection [...] typically brings a high degree of indeterminism to the execution environment. The indeterminism of garbage collection has two aspects: the garbage collector causes pauses that are hard to predict while the automatic detection of free memory makes predictions on the memory demand of an application difficult.

1) Wo bitte liest man hier was von nicht-deterministischem Verhalten im Sinne von Determinismus (Algorithmus) = "auf eine Anweisung im Algorithmus folgt unter den gleichen Voraussetzungen immer die gleiche Anweisung"? --> zumindest der Link passt nicht

2) Wo bitte steht was von "Programmumgebung"? Was bitte ist die Programmumgebung? Andere Programme in der Umgebung, das Betriebssystem, der Computer? Programmumgebung ist was anderes als "execution environment".

Ich bessere jetzt die Einleitung gemäß der Quelle aus. Kein "deterministisch", weil die Quelle nicht von deterministisch in irgendeinem in der WP definierten Sinn spricht. Die Quelle spricht von "predictions" = vorhersagbar. Und kein Schwachsinn zu Progrmmumgebung. Die Quelle spricht von Zeitverhalten und Speicheranforderungen.

Bitte um Diskussion & keinen Edit-War. --Sebastian.Dietrich ✉ 09:23, 10. Dez. 2012 (CET)

1. sehr gut ist, dass jetzt (08:37UTC) der dämliche verweis auf deterministische Algorithmen (iSd theoretischen Informatik) in der Einleitung weg ist... 2. weiter unten taucht er wieder auf... *lol* 3. „Nicht-Vorhersagbarkeit“ hört sich auch wieder etwa merkwürdig an, denn: der vorhersagealgorithmus ist der computer mit seinen ganzen algorithmen... also wo soll da bitte der unverhersehbare zufall sein? --Heimschützenzentrum (?) 09:40, 10. Dez. 2012 (CET)

Zu 1) Determinismus bedeutet, dass du bei gleicher Eingabe auch die gleichen Zustände durchläufst - immer und exakt. So vage Formulierungen wie "Voraussetzungen" und "Anweisungen" sind vllt. eine nette umgangssprachliche Beschreibung, führen aber leicht zu Missverständnissen.

Zu 2) Da muss man zugeben, dass das etwas unscharf ist. -- Plankton314 (Diskussion) 10:58, 10. Dez. 2012 (CET)

Ich hab's in "Ausführungsumgebung" geändert. Natürlich ist das die Umgebung, in der das Programm ausgeführt wird, aber wenn's der Wahrheitsfindung dient... Ansonsten habe ich aufgegeben, Sebastian den Determinismus zu erklären. Das haben wir ja schon über vermutlich dutzende KB immer und immer und immer wieder versucht. --Eike (Diskussion) 11:11, 10. Dez. 2012 (CET)

Ja, ich gebs nach dieser letzten Erwiderung jetzt auch auf. Macht keinen Sinn nochmal alles zum x-ten Mal zu wiederholen. -- Plankton314 (Diskussion) 11:19, 10. Dez. 2012 (CET)

1. welchen determinismus begriff meinst du gerade? 2. einrückung? --Heimschützenzentrum (?) 11:22, 10. Dez. 2012 (CET)

1. der begriff aus der theoretischen Informatik passt hier einfach nicht, weil keiner der algorithmen auch nur die möglichkeit hat, wie eine nicht-deterministische Turing-Maschine zu sein... 2. und ja: auch im realen computer durchläuft das bündel von algorithmen (betriebssystem, programm mit GC thread, usw. usf.) bei gleicher eingabe immer die gleichen zustände... wie sollte es auch anders sein? man muss na klar die eingabe weit genug fassen: also die eingabe in das gesamtsystem resp. in die „ausführungsumgebung“... --Heimschützenzentrum (?) 11:08, 10. Dez. 2012 (CET)

@ Sebastian.Dietrich: Ich glaube immer noch, dass du Determiniertheit (gleiches Ergebnis) mit Determinismus (zusätzlich noch gleiche interne Zustände) verwechselst? -- Plankton314 (Diskussion) 11:17, 10. Dez. 2012 (CET)

nein, das problem ist, dass alle beteiligten algorithmen deterministische algorithmen iSd theoretischen Informatik sind... das wort in der quelle muss also anders definiert sein... und mir wird schon etwas übel, wenn ich an mögliche „definitionen“ auch nur denke... --Heimschützenzentrum (?) 11:25, 10. Dez. 2012 (CET)

zu user:Eike sauer's disk beitrag: „sollte ich noch "hochgradig nicht-deterministisch" reinschreiben? steht ja so in der quelle...“ (oder was soll das sein?):

och nö... da steht kein wort davon, dass „deterministische Algorithmen (iSd theoretischen Informatik)“ gemeint ist... außerdem ist fachübersetzung (die quelle enthält nämlich das wort „deterministisch“ weit und breit nirgends...) so eine sache für sich, wie uns hier (vermutlich) gerade sehr schön gezeigt wird von jemandem bei dem der „unit test“ rot&grün blinkt (warum auch immmer... erinnert etwas an den film mit dem raumschiff, das in ner mondstation notlandet...)... --Heimschützenzentrum (?) 11:08, 10. Dez. 2012 (CET)

besonders wo ich gerade das mit dem „high degree“ sehe, fällt mir gerade auf, dass der autor wohl gerade mit dieser these seine brötchen verdient... ich habe daher umso mehr den verdacht, dass da ein tolles wort durch marketing strategen gebraucht werden soll, um irgendwelche hohen marketing-erfolge zu erzielen... vielleicht sollten wir auf „Determinismus (Marketing)“ verweisen, damit der arme Turing nich noch anfängt zu rotieren? --Heimschützenzentrum (?) 11:22, 10. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:17, 7. Feb. 2013 (CET)

Neu-Strukturierung

Bis der Artikel in „Plankton314's Gedanken zur Zeit“ umbenannt worden ist, wollen wir bitte ganz klar zwischen „Garbage Collection“ und dem trennen, was gewisse Java-Programmierer/-Entwickler darunter zu verstehen glauben: 1. Man kann nicht davon ausgehen, dass ein realer Rechner eine nicht-deterministische Turing-Maschine ist (und das meint man aber, wenn man auf den nämlichen Determinismus Artikel verweist)... 2. Finalisierung hat auch nur entfernt mit GC zu tun und es ist/war auch discouraged, finalize überhaupt zu verwenden... 3. Desweiteren ist es sogar falsch zu behaupten, dass „das Programm“ losgelöst vom GC existiere (beide bilden zusammen mit den anderen Threads und Prozessen eine Einheit), und auch dass „das Programm“ über die Aktivitäten des GC keine Informationen haben könne (Beispiel: finalize könnte dem Programm irgendwas in eine Liste eintragen... bloß wozu? „Das Programm“ braucht sich doch nich mehr um das, was es eh nicht mehr braucht, zu kümmern...), und auch dass die Allokation eine Aufgabe der GC sei (was sich bereits aus dem Begriff ergibt...)...

Der Artikel liest sich jetzt etwas, als sei er von sehr sehr Java-Praxis-nahen Kiddies im WP:WAR-Rausch getippt worden...

Vorschlag: Die Einleitung wird wieder hergestellt (in der Form vom August oder so) und die ganzen kranken Entwicklungen werden in einem eigenen Abschnitt ordentlich dargestellt (also nicht blindwütig aus ner Werbebroschûre abgetippt...)... --Heimschützenzentrum (?) 15:40, 10. Dez. 2012 (CET)

Zu 1) Auf welche Formulierung beziehst du dich?

Zu 2) Warum wohl?

Zu 3) Wenn du konkrete Passagen nennst, die diese Aussage haben, können wir was dagegen unternehmen.

Zu deinem Vorschlag: Du schlägst bei jeder Änderung vor, auf den Stand von letztem Jahr zu revertieren. -- Plankton314 (Diskussion) 16:53, 10. Dez. 2012 (CET)

*seufz* das ist doch Schikane... aber was solls: 1. auf jede Formulierung, die auf determinismus (Algorithmus) verweist... 2. warum steht dann dauernd was von Finalisierungs-Nebenwirkungen da, wenn die doch praktisch nicht genutzt wird? schon in der Einleitung offenbar... 3. in der Einleitung: das „Verhalten der Ausführungsumgebung“ kann man nicht von dem „des Programms“ losgelöst betrachten... im Abschnitt „Determinismus“: „das Programm selbst keine Information darüber, wann Speicherbereiche wirklich freigegeben“... und wieder in der Einleitung: „bezeichnet [...] eine automatische Speicherverwaltung“... 4. das ist nunmal eie stabile Version... --Heimschützenzentrum (?) 17:03, 10. Dez. 2012 (CET)

Zu 1) Das lese/verstehe ich anders.

Zu 2) Woher nimmst du dieses Wissen?

Zu 3) Warum sollte es losgelöst sein? -- Plankton314 (Diskussion) 17:15, 10. Dez. 2012 (CET)

das scheint mir keine diskussion zu werden (es wird z B eindeutig der Begriff „deterministisch“ auf Determinismus (Algorithmus) verlinkt, obwohl es hier nicht um „(nicht-)deterministische Algorithmen“ iSd theoretischen Informatik geht...), so dass ich darauf nicht inhaltlich gar nicht weiter antworte... --Heimschützenzentrum (?) 17:54, 10. Dez. 2012 (CET)

Keine Ahnung, wo du hier einen nicht-deterministischen Algorithmus siehst??! -- Plankton314 (Diskussion) 18:53, 10. Dez. 2012 (CET)

ja eben! darum geht es doch seit tagen! es kann im artikel nirgends um „nicht-deterministische Algorithmen“ gehen! ihr interpretiert/übersetzt die quelle alle falsch! so! --Heimschützenzentrum (?) 19:36, 10. Dez. 2012 (CET)

Es wird - so weit ich das sehe - an keiner Stelle behauptet, dass von der GC verwendete Algorithmen nicht-deterministisch sein könnten.

Hmm, obwohl... Wenn ich darüber nachdenke, dann wäre das ebenfalls eine Möglichkeit. Mal schauen, ob sowas mal vorgeschlagen wurde oder sogar verwendet wird.-- Plankton314 (Diskussion) 20:38, 10. Dez. 2012 (CET)

1. also ist eine „Ausführungsumgebung“ kein Algorithmus? wenn nein: was ist es dann? 2. „Garbage Collection [...] typically brings a high degree of indeterminism to the execution environment.“: GC ist kein Algorithmus? wenn nein: was ist es dann? oder: wie kann ein deterministischer Algorithmus deterministische Algorithmen nicht-deterministisch machen? --Heimschützenzentrum (?) 21:03, 10. Dez. 2012 (CET)

Ich schenk dir was, Homer. Ich schenk dir: Wenn du ein Computersystem betrachtest und alle Eingaben kennst, könnte der Ablauf des Gesamtsystems und damit des fraglichen Programms komplett determiniert sein. (Ich halte das nicht für unbedingt wahr, aber es ist ja ein Geschenk.) Das Problem ist: Kein Anwendungsprogrammierer kennt die Ausführungsumgebung der Rechner, auf denen sein Programm in Zukunft laufen wird. Und: Die sind frecherweise unterschiedlich. --Eike (Diskussion) 21:22, 10. Dez. 2012 (CET)

dann ist also der startzustand des betrachteten systems nicht immer gleich? dann verstehe ich den link auf determinismus (Algorithmus) nicht... und was das überhaupt speziell mit GC zu tun haben soll, verstehe ich auch nicht... das ist dann ja so banal, dass man es gar nicht erwähnen muss: bei unzureichend viel speicher/cpu-leistung benehmen sich viele programme anders als sonst... da kann man doch nicht sone kanone aus der theologischen informagie auffahren... kommt mir albern vor... mir würds ja schon reichen, wenn der link jetzt ganz rausflöge... --Heimschützenzentrum (?) 21:29, 10. Dez. 2012 (CET)

Es geht nicht um unzureichende Leistung. Und das solltest du auch wissen - ich hab es schon häufig erwähnt. Es geht darum, dass die Systeme innerhalb des erwarteten Rahmens sind (keine Blitze, keine Out-of-Memory-Exceptions). Und dass der Programmablauf(!) bei gleicher Eingabe(!) unterschiedlich sein kann. Was ich dir seit der ersten Nachricht zum Thema sage: Als Programm-Entwickler kann ich nur das Programm betrachten - den Rest kann ich nicht kennen! - und muss mit diesen Informationen vorhersagen können, was es tut. Bei einem Standard-C++-Programm kann ich das! Für beliebige Systeme innerhalb der Spezifikation. Deshalb ist es eine Besonderheit, wenn eine Ausführungsumgebung so beschaffen ist, dass ich das nicht in jedem Fall kann. (Natürlich bin ich dann bestrebt, mein Programm trotzdem so zu schreiben, dass immer etwas Vernünftiges rauskommt. Das ist aber ein anderes Thema.) --Eike (Diskussion) 21:33, 10. Dez. 2012 (CET) PS: Wenn du immer das komplette System betrachten möchtest, wo sollte dann jemals Indeterminismus herkommen? Müsste man dafür Schrödigers Katze befragen?

Danke dass du das Zitat wieder reduziert hast, nur damit das rauskommt was dir passt. So kann man toll arbeite. --Sebastian.Dietrich ✉ 22:05, 10. Dez. 2012 (CET)

Glückwunsch! Du hast eine VM gewonnen! -- Plankton314 (Diskussion) 22:15, 10. Dez. 2012 (CET)

Danke für den Gewinn (ich hab dank dir auch gewonnen) --Sebastian.Dietrich ✉ 22:20, 10. Dez. 2012 (CET)

Das sehe ich noch immer anders... -- Plankton314 (Diskussion) 22:25, 10. Dez. 2012 (CET)

1. also soll der Artikel vermitteln, dass es möglich ist, dass „das Programm“ von der einen „Ausführungsumgebung“ so und der anderen „Ausführungsumgebung“ anders ausgeführt wird? das wäre ja so, als ob AMD anders dividiert als Intel... sowas war ja schon ne Meldung in der Tagespresse wert, glaub ich... 2. aber: Das bedeutet dann noch nicht, dass „das Programm“ kein deterministischer Algorithmus i. S. d. theoretischen Informatik ist... ich finde nicht, dass die Definition von „deterministischer Algorithmus“ das hergibt, weil da ja nicht ein Teil-Algorithmus betrachtet wird, sondern immer die ganze Turingmaschine mit der Gesamtheit ihrer Algorithmen und Zustände... diese Trennung von Ausführungsumgebung und Algorithmus kommt mir irgendwie unzulässig vor... also müsste der Verweis auf die theoretische Informatik raus und es müsste erläutert werden, was mit „nicht-deterministisch“ gemeint ist... 3. eine nichtdeterministische Turingmaschine gibt es in der Praxis wohl genau deswegen gar nicht... sie wird nur für theoretische Betrachtungen verwendet... steht jedenfalls so im Artikel... auch von daher wäre es komisch, wenn es durch Java gelungen sein sollte, eine NTM zu basteln... *lol* es muss sich also um ein Missverständnis handeln... --Heimschützenzentrum (?) 22:26, 10. Dez. 2012 (CET)

Der Turing-Maschine fehlt es an der Ausführungsumgebung, die sich wiederum ihrer Umgebung anpasst. Und es wird übrigens weder von einem nicht-deterministischen Algorithmus des Programms gesprochen (wär ja auch Unsinn, der Algorithmus kann nicht durch die Ausführungsumgebung beeinflusst werden, der ist ja abstrakt), noch von einer nichtdeterministischen Turingmaschine. Der exakte Ablauf des Programm ist nicht-vorhersagber = nicht-deterministisch. --Eike (Diskussion) 22:37, 10. Dez. 2012 (CET)

so langsam kommen wir der Sache näher, glaub ich... der verweis von „nicht-deterministisches Verhalten“ auf „Determinismus (Algorithmus)“ ist also wie zu verstehen? das soll also nicht bedeuten, dass GC zu nichtdeterministischen Algorithmen und Wollmilchsäuen und NTM führt? --Heimschützenzentrum (?) 22:40, 10. Dez. 2012 (CET)

(Poa, wär das schön! :X ) Ne, das Wort Algorithmus käme mir da nicht passend vor. Aber steht ja so auch nicht im Artikel, soweit ich gesehen habe.

Ok, ich sehe jetzt ein Problem - nicht mit der Tatsache, dass GC den Programmablauf nicht-deterministisch macht -, aber wenn man sich streng an den Text des verlinkten Artikel hält. Ich würde gerne Folgendes verlinken:

Ein deterministisches Programm ist ein Programm, bei dem nur definierte und reproduzierbare Zustände auftreten. Für die gleiche Eingabe folgt auch immer die gleiche Ausgabe und zusätzlich wird die gleiche Folge an Zuständen durchlaufen. Zu jedem Zeitpunkt ist der nachfolgende Abarbeitungsschritt des Programm eindeutig festgelegt. Das bedeutet auch, dass alle Zwischenergebnisse innerhalb des Programm immer gleich sind.

Der Link ist m. E. so zu verstehen, dass es das passendste ist, was wir haben.

--Eike (Diskussion) 22:45, 10. Dez. 2012 (CET)

aber wenn es so _nicht_ ist, dann ist es automatisch ein „nichtdeterministischer Algorithmus“... und das kann es nicht sein... also muss „nicht-deterministisch“ im GC Artikel was anderes bedeuten als im „Det (Algo)“ Artikel... --Heimschützenzentrum (?) 22:56, 10. Dez. 2012 (CET)

Nein, ich denke, es muss kein „nichtdeterministischer Algorithmus“ sein. Aber geh doch spaßeshalber mal mehr auf meinen Beitrag ein: Ein deterministisches Programm ist ein Programm, bei dem nur definierte und reproduzierbare Zustände auftreten. Für die gleiche Eingabe folgt auch immer die gleiche Ausgabe und zusätzlich wird die gleiche Folge an Zuständen durchlaufen. Zu jedem Zeitpunkt ist der nachfolgende Abarbeitungsschritt des Programm eindeutig festgelegt. Das bedeutet auch, dass alle Zwischenergebnisse innerhalb des Programm immer gleich sind. Würdest du mir zustimmen, dass ein Programm mit Finalizern mit einer handelsüblichen GC kein deterministisches Programm in diesem Sinne ist? --Eike (Diskussion) 08:06, 11. Dez. 2012 (CET)

1. jeder Algorithmus ist entweder deterministisch oder nicht-deterministisch... 2. die schwammigen begriffe („handelsüblichen”, „deterministisches Programm”) stören jetzt wieder etwas... 3. nein, da würde ich nicht zustimmen, weil: 3a. siehe unten (heute 07:32CET)... 3b. eine klapprige Ausführungsumgebung ist ersteinmal ein Designfehler... 3c. die Ausführungsumgebung muss zusammen mit den ausgeführten Programmen gesehen werden... 3d. ein Algorithmus, der (implizit) einen nicht-deterministischen Algorithmus nutzt, _kann_ dann auch selbst nicht-deterministisch sein... 3e. ich sehe aber nicht, wie n GC nicht deterministisch sein könnte... 3f. ganz sicher ist jedoch, dass Finalisierung zu sporadischen Fehlern führen kann... --Heimschützenzentrum (?) 08:33, 11. Dez. 2012 (CET)

Danke, dann dürfte das ja geklärt sein. "Designfehler" ist kein Argument, Finalisierer sind Bestandteil von GC, und weil wir unter Fachleuten sind, schreiben wir nicht "klapprig" und "sporadisch", sondern "nicht-deterministisch". --Eike (Diskussion) 08:39, 11. Dez. 2012 (CET)

och nö... 1. Finalisierer sind nicht notwendig Bestandteil von GC... 2. nur weil ein Programm sporadisch fehlerhaft abläuft, ist es doch nicht ein nicht-deterministischer Algorithmus, weil da nämlich im Falle von deterministischen Algorithmen ein ganz bestimmter Startzustand vorliegt, der zu dem Fehler führt... Die Ausführungsumgebung eines Algorithmus' ist von selbigem nicht trennbar, da sie Teil seiner Definition ist („+” ist „+”, „·” ist „·”, GC ist alle 5 Sekunden, etc. pp.)... 3. und jetzt reicht's mir so richtig endgültig... :-) ich distanziere mich von dem Inhalt des Artikels vollständig... zum Glück muss ich mich mit sowas nicht mehr abgeben (son Theater gibt's nämlich auch ohne GC...)... --Heimschützenzentrum (?) 08:58, 11. Dez. 2012 (CET)

M. E. ist das Lemma "Determinismus (Algorithmus)" fehl am Platze, es sollte eher "Det. (Th. Inf.)" oder so heißen.

In dem Versuch, nochmal Klarheit zu schaffen (wir haben ja jetzt nochmal drei Tage Zeit :-D ): Der Nichtdeterminismus bezieht sich einzig und allein auf die [mögliche] Auswirkung eines GC auf das ausgeführte Programm und seine Zustände - und nicht darüber hinaus, etwa den GC selbst oder den gesamten Computer. -- Plankton314 (Diskussion) 22:58, 10. Dez. 2012 (CET)

aber wo soll denn der randomisierte Algorithmus herkommen? kann man denn den GC-bezogenen Nichtdeterminismus mal irgendwie anders umschreiben? --Heimschützenzentrum (?) 23:04, 10. Dez. 2012 (CET)

Daher, dass der GC mal früher und mal später zuschlägt und Objekte freigibt - was ein Änderung des (Programm-)Zustands entspricht. Und diese Änderung ist nicht vorhersagbar, weil sie vom GC "außerhalb" des eigentlichen Programms kommt (auch wenn es technisch betrachtet der gleich Thread/Prozess/Computer/usw. ist). Und diese Aussage gilt auch nur isoliert betrachtet für das Programm. -- Plankton314 (Diskussion) 23:42, 10. Dez. 2012 (CET)

1. wie kann eine „Freigabe“ von ohnehin ungenutztem Speicher irgendwie den (Programm-)Zustand ändern? eigentlich gar nicht... es liegt also allenfalls an der Finalisierung... hier vermischt sich also eine merkwürdige/kranke/abgelehnte/unnutzbare Entwicklung mit dem eigentlichen Thema des Artikels... 2. aber auch Finalisierung und auch deren Startzeit sind deterministisch... eine geänderte Ausführungsumgebung kann zu geänderten Finalisierungs-Startzeiten führen und kann also zu geänderten (Programm-)Zuständen führen... es ist also quasi so, als ob jemand behauptet, dass ein Taschenrechner nicht-deterministisch sei, weil man schließlich seine CPU austauschen könnte, so dass plus zu minus wird (und umgekehrt)... irgendwie scheint mir das nicht der Definition im verlinkten Determinismus Artikel zu entsprechen... 3. Wir sollten also unbedingt aufhören, zu behaupten, Java Programme könnten allein durch GC nicht-deterministische Algorithmen iSd der theoretischen Informatik sein. Vielmehr sollten wir am Ende daraufhinweisen, dass Finalisierung Raum für Designfehler schafft (statt „hängendem Zeiger“ eben „race condition“, wobei letzteres eigentlich nichts neues bei Nebenläufigkeit ist...)... --Heimschützenzentrum (?) 07:32, 11. Dez. 2012 (CET)

Genau meine Punkte.

• GC ist selbst deterministisch (das sehen wir denke ich inzwischen alle so (siehe 22:58) oder?)
• Die Freigabe von ohnedies ungenutztem Speicher kann den Programmzustand nicht ändern. WeakReferences arbeiten per design mit potentiell nicht mehr erreichbaren Objekten. Dort eingebaute Designfehler wie z.B. davon ausgehen, dass das Objekt immer erreichbar ist, ist ein Fehler des Programmes und nicht des GCs. Hier sind wir wohl unterschiedlicher Meinung.
• Finializer kommt zu unterschiedlichen Zeiten (no na net), diese Zeiten sind deterministisch (d.h. 1:1 derselbe Computer im selben Zustand führt beim selben Programm zum exakt gleichen Zeitpunkt gestartet zur exakt gleichzeitigen Ausführung der Finalizer). Hier sind wir wohl unterschiedlicher Meinung
• Im Finalizer kann ich nicht-deterministischen Code schreiben. Der Finalizer (nicht dessen Aufruf) aber ist Teil des Programmes - dort eingebaute Designfehler wie race conditions sind Fehler des Programmes nicht des GCs. Hier sind wir wohl auch unterschiedlicher Meinung. --Sebastian.Dietrich ✉ 09:28, 11. Dez. 2012 (CET)

Zu 1: Ich denke, das spielt für unsere Frage keine Rolle, weil das Bezugssystem, die "Eingabe" des GC, ein anderes ist als das des Programms.

Zu 2: Es geht bei Determinismus/Nicht-Determinismus nicht darum, dass die Ausgabe des Programms vorhersagbar ist, sondern alle Zwischenzustände in einer festgelegten Reihenfolge. Schon ein if (obj.IsAlive()) ..., das mal so, mal so abbiegt, verlertzt den detrminismus. Natürlich sorgt der sorgsame Programmierer dafür, dass am Ende trotzdem das richtige rauskommt. Das macht das Programmergebnis vorhersagbar - nicht aber den exakten Ablauf, wie es dazu kommt. Nicht-Determinismus steht nicht für falsche Ergebnisse oder für Abstürze!

Zu 3: Wenn du den Computer als Gesamtsystem betrachtest, mag der komplette Ablauf determiniert sein. Als Anwendungsentwickler kannst du das aber nicht betrachten, da ein Programm meist auf verschiedenen Systemen läuft.

Zu 4: Exakt. Der Finalizer ist Teil des Programms - dessen Aufruf aber nicht.

--Eike (Diskussion) 10:32, 11. Dez. 2012 (CET)

Eike hat es auf den Punkt gebracht.

Wie oft möchtest du noch unter Beweis stellen, dass du nicht weißt, was mit Nichtdeterminismus gemeint ist?

Es das hat auch nichts mit Fehler/Abstürzen/RCs/usw. zu tun.

Und gibt es dir nicht zu denken, dass hier mittlerweile mehrere Informatiker vorbeigeschaut haben und du der einzige mit einer "unterschiedlichen Meinung" bist? -- Plankton314 (Diskussion) 10:53, 11. Dez. 2012 (CET)

1) Unterlasse deine persönlichen Angriffe (sag ich dir jetzt ein letztes Mal) 2) lege mir nichts in den Mund, was ich nie gesagt habe 3) gehe nicht davon aus, das die schweigende Mehrheit deiner Meinung ist 4) 1+1 ist immer noch 2. --Sebastian.Dietrich ✉ 12:03, 11. Dez. 2012 (CET)

Zu den Punkten von Eike: 1) Denke das spielt sehr wohl eine Rolle, da zwei von uns der Meinung sind, dass ein deterministisches Programm ein anderes nicht indeterministisch machen kann. Also ist ein GC selbst deterministisch oder nicht? Plankton314 ist anscheinend dieser Meinung (s.o.) 2) Ja klar ist nicht das Endergebnis wichtig, sondern jeder Zwischenschritt (hat wer von uns jemals was anderes behauptet?). Ein if (x==y) ... macht ein Programm indeterministisch, wenn "unter gleichen Voraussetzungen" was unterschiedliches rauskommen kann. Oder? Wie aber kann ein if (x==y) ... oder if (obj.IsAlive()) ... "unter gleichen Voraussetzungen" was unterschiedliches liefern? Gar nicht - nur wennst die Voraussetzungen änderst. Dann ist aber Determinismus das falsche Wort. 3) Wunderbar - also "Wenn du den Computer als Gesamtsystem betrachtest, mag der komplette Ablauf determiniert sein." - da sind wir ja einer Meinung. GC führt also nicht zu Indeterminismus. Oder wie doch jetzt wenn doch lt. dir "der komplette Ablauf determiniert ist"? Oder gilt Indeterminismus nur bei verteilten Applikationen? Oder nur bei verteilten GCs? 4) "Der Finalizer ist Teil des Programms - dessen Aufruf aber nicht." Toll dass du das auch so siehst. Wie aber kann ein deterministischer Finalizer indeterministisch werden? Also "unter gleichen Voraussetzungen" andere Zustände einnehmen?

Klar, das Verhalten des Programmes (inkl. seiner einzelnen Zustände etc.) ist in der Praxis nicht vorhersagbar. Dennoch ist es determiniert gemäß Determinismus (Algorithmus) "unter gleichen Voraussetzungen dieselbe Abfolge". Leute es geht nur um das Wort "deterministisch" um nix anderes. Ein Computer ist wie eine Turing Maschine und alles was darauf läuft ist deterministisch. In der Praxis nicht vorhersagbar, aber deterministisch. --Sebastian.Dietrich ✉ 12:03, 11. Dez. 2012 (CET) --Sebastian.Dietrich ✉ 12:03, 11. Dez. 2012 (CET)

Damit schränkt es sich denke ich auf einen Punkt ein: Die "gleichen Voraussetzungen" sind meines Erachtens alle Ausgangsdaten und Eingaben innerhalb des Programms. Du versteht darunter alle Ausgangsdaten und Eingaben des Gesamtsystems Computer. --Eike (Diskussion) 12:09, 11. Dez. 2012 (CET)

Ja genau. Der Gesamtzustand des Gesamtsystems. Insbesondere natürlich der Zustand des GCs (den ich persönlich als Entwickler sehr wohl mitberücksichtige (genauso wie auch die Klassenbibliothek etc.)). --Sebastian.Dietrich ✉ 12:12, 11. Dez. 2012 (CET)

Ein Punkt am Rande: Es ist mir unbegreiflich, warum wir handgeschätzte hunderte KB brauchen, um rauszufinden, dass der Knackpunkt genau das ist, was ich in meinem allerersten Beitrag zum Thema hier geschrieben habe. Inhaltliche Antwort folgt später. --Eike (Diskussion) 12:18, 11. Dez. 2012 (CET)

Geh so ist das halt mit Diskussionen zu Dingen, die den Teilnehmern wirklich am Herzen liegen. Nie einen Club 2 gesehen? :-) --Sebastian.Dietrich ✉ 12:28, 11. Dez. 2012 (CET)

Ne, ich bin "Preusse"! Hört sich aber ein bisschen an wie Explosiv – Der heiße Stuhl. Konnte ich auch nicht leiden. --Eike (Diskussion) 12:31, 11. Dez. 2012 (CET)

Anderen Leuten zu sagen, was sie zu tun haben ist wohl deine große Stärke??

Wie Eike bereits unzählige Male dargestellt hat, ist der Gesamtzustand des Systems dem Programm selbst nicht bekannt. Deine Behauptung, dass du den Zustand des GCs berücksichtigen würdest, ist einfach unmöglich.

Du kannst hier gerne noch lange darüber diskutieren, welche mißverstandenen Annahmen du von Determinismus hast. Die Tatsache, dass GC einen nichtdeterministischen Einfluss auf den Programmfluss haben kann, ist klar belegt und wird sich auch in der einen oder anderen Weise im Artikel widerspiegeln.

Welche exakte Formulierung hier verwendet wird, ist für mich zweitrangig. -- Plankton314 (Diskussion) 12:34, 11. Dez. 2012 (CET)

Jetzt reg dich endlich ab. --Sebastian.Dietrich ✉ 14:15, 11. Dez. 2012 (CET)

Hast du da oben ernsthaft das Wort determiniert hervorgehoben? Um genau das geht es die ganze Zeit nicht. -- Plankton314 (Diskussion) 12:38, 11. Dez. 2012 (CET)

Verschreiber. Habs geändert. --Sebastian.Dietrich ✉ 14:15, 11. Dez. 2012 (CET)

(BK) Es ist ein bisschen schwierig, da eine Quelle zu finden. IMHO, weil die Autoren einfach voraussetzen, dass die gleichen Voraussetzungen nur für den Betrachtungsgegenstand gelten und nicht für die Welt drumrum. Aber ich hab was gefunden:

"Determinismus bedeutet in diesem Kontext, dass in jeder Konfiguration eindeutig festgelegt ist (determiniert ist), was im nächsten Schritt passieren wird. Daher bestimmen ein Programm (oder ein EA) A und seine Eingabe x vollständig und eindeutig die Berechnung von A auf x." (Hervorhebung von mir.) "Theoretische Informatik: Formale Sprachen, Berechenbarkeit, Komplexitätstheorie, Algorithmik, Kommunikation und Kryptographie (Leitfäden der Informatik)"

--Eike (Diskussion) 12:39, 11. Dez. 2012 (CET)

Meinetwegen ist die Formulierung "potentiell" oder "unter Umständen" vollkommen hinreichend. Weiter unten können die Umstände genauer beschrieben werden.

Möglicherweise sind weitere Eingrenzungen Spezialfälle oder aber nicht allgemeingültig.

Andersherum formuliert: Also besser "Bottom-Up", in der Einleitung die detaillierteren Aussagen aus dem weiteren Artikel zusammenfassen (wenn die denn vollständig sind). Das ist ja im Grunde das Wesen der Einleitung. -- Plankton314 (Diskussion) 12:49, 11. Dez. 2012 (CET)

Nein es geht um "nicht-deterministisches Verhalten der Ausführungsumgebung und damit unter Umständen auch des Programms selbst" - nicht um potentiell oder unter Umständen, sondern um das "nicht-deterministische". Gerne statt dessen "nicht im Detail vorhersagbare" aber "deterministisch" mit Link auf Determinismus (Algorithmus) ist falsch. --Sebastian.Dietrich ✉ 14:15, 11. Dez. 2012 (CET)

Es ist nichtdeterministisch und nicht irgendeine unscharfe Umschreibung. Das wurde durch deine eigenen Angaben belegt.

Scheint auch sinnlos, weiter gegen deine festgefahrene Meinung anzureden. Es ist jedoch nicht hinzunehmen, dass formal korrekte Fachausdrücke durch vage Umschreibungen ersetzt werden, nur weil du sie nicht verstehst. -- Plankton314 (Diskussion) 14:29, 11. Dez. 2012 (CET)

Nichtsda - ich habe nur zugestimmt, dass "Laufzeitverhalten" nicht-deterministisch genannt wird (und zwar ohne Link auf Determinismus (Algorithmus)). Umgangssprachlich ist das Laufzeitverhalten ja auch nicht deterministisch = nicht vorhersagbar. Theoretisch (und wir reden vom Theoretische Informatik "Deterministisch") ist aber alles deterministisch, solange es sich nicht um einen Randomisierter_Algorithmus handelt. --Sebastian.Dietrich ✉ 14:42, 11. Dez. 2012 (CET)

@Eike - diese Definition von Determinismus ist auch nicht wirklich anders als die von Determinismus (Algorithmus). Der erste Satz spricht von "in jeder Konfiguration eindeutig festgelegt ist (determiniert ist), was im nächsten Schritt passieren wird". Was ist denn diese "Konfiguration" anderes als das Gesamtsystem? Die Konfiguration beeinflusst das Programm, wird sie von aussen geändert auch zur Laufzeit. Darum muss die Konfiguration bei jedem einzelnen Programmschritt immer berücksichtigt werden, ansonsten kann nicht festgelegt sein, was im nächsten Schritt passiert. --Sebastian.Dietrich ✉ 14:15, 11. Dez. 2012 (CET)

Wir müssen nicht raten was gemeint ist, es steht ja ausdrücklich da: "ein Programm (oder ein EA) A und seine Eingabe x". --Eike (Diskussion) 14:22, 11. Dez. 2012 (CET)

Du meinst der Autor hat "Programm und seine Eingaben" mit "Konfiguration" gemeint? Das würde bedeuten, dass alle Programme indeterministisch wären, die auf Ressourcen ausserhalb des Programmes (DBs, Files, ...) zugreifen. D.h. in der Praxis gäbe es nur indeterministische Programme. Und du müsstest den Artikel Determinismus (Algorithmus) komplett umschreiben. --Sebastian.Dietrich ✉ 14:42, 11. Dez. 2012 (CET)

Files sind auch Eingaben des Programms. Die GC nicht. --Eike (Diskussion) 14:44, 11. Dez. 2012 (CET)

Wenn Files, dann auch RAM (ist doch völlig egal wie was physikalisch repräsentiert ist). Wenn das Betriebssystem die Files beeinflusst, dann bleibt das Programm also deterministisch. Wenn GC das RAM beeinflusst, dann muss dafür dasselbe gelten.--Sebastian.Dietrich ✉ 14:50, 11. Dez. 2012 (CET)

Ich klinke mich jetzt aus - so wichtig ist mir die Korrektheit dieses Artikels auch nicht. Jeder von uns weiß dass er recht hat, und die anderen wohl zu blöde sind es auch nach vielen Stunden Diskussion zu kapieren. Haben sich mal wieder die mit mehr Ausdauer durchgesetzt, ohne die anderen überzeugen zu können. love it, change it or leave it. --Sebastian.Dietrich ✉ 14:50, 11. Dez. 2012 (CET)

Vielleicht legen wir ein oder zwei preussische Nächte ein, treten mal einen Schritt zurück und einigen uns auf den größten gemeinsamen Nenner, der allgemeingültig ist. -- Plankton314 (Diskussion) 15:04, 11. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:17, 7. Feb. 2013 (CET)

Einzelnachweise pro bzw. contra "GC ist deterministisch"

GC ist deterministisch

• Tuning Real Time Applications for Deterministic Garbage Collection

Ist ein gutes Pro-Argument. "Running on slower hardware with a different heap size and/or with more live data may break the deterministic behavior." --Eike (Diskussion) 17:34, 6. Dez. 2012 (CET)

Es geht um "Zeitverhalten" - das ist bei ALLEN Programme indeterministisch. Der Artikel belegt aber, dass man GC deterministisch machen kann --> GC ist (nichtmal was das Zeitverhalten anbelangt) automatisch indeterministisch --Sebastian.Dietrich ✉ 18:12, 6. Dez. 2012 (CET)

• Real-time Java, Part 4: Real-time garbage collection "Metronome is a deterministic garbage collector"

Ist ein gutes Pro-Argument. Offensichtlich ist die übliche Java-GC nicht-deterministisch: "Nondeterministic pauses in traditional garbage collection (GC) have inhibited Java™ technology from being a suitable environment for real-time (RT) development." Pausen sind vielleicht nicht das geeignetste Argument, die unterste Referenz ist klarer.

IBM: garbage collection is not without its costs -- among them [...] nondeterministic finalization.

--Eike (Diskussion) 17:35, 6. Dez. 2012 (CET)

Danke, ich habs gerade auch gelesen und überlegt, warum das alles unter Contra steht. --Plankton314 (Diskussion) 17:38, 6. Dez. 2012 (CET)

Nein das ist kein Argument - finalization ist eine Möglichkeit, die einige GCs bieten, aber keine Notwendigkeit. Einige Sprachen bietet sowas wie Random an - deshalb ist aber nicht alle Sprachen und die damit geschriebenen Programme indeterministisch. --Sebastian.Dietrich ✉

• Garbage Collection in Microsoft Dynamics AX 2012 " The GC is deterministic in the sense that objects are guaranteed to be disposed from the C++ memory space at the earliest possible moment after they are no longer needed."

Ist ein gutes Pro-Argument. Offensichtlich ist auch der Standard-.NET-GC nicht-deterministisch: "This is why the .NET garbage collection strategy is said to be non-deterministic." --Eike (Diskussion) 17:37, 6. Dez. 2012 (CET)

Genau - ein gutes Contra Argument, da es anscheinend sogar lt. dir deterministische GCs gibt. --Sebastian.Dietrich ✉ 18:12, 6. Dez. 2012 (CET)

Das hat ja auch niemand bezweifelt. Und es behauptet auch niemand, dass dadurch jedes Programm auf einmal nicht mehr deterministisch laufen würde. Es ist nur ein Problem, dass auftreten kann und RAII und Scoping verletzt.

Und wie Eike richtig schrieb ist eine nicht-deterministische GC der übliche Fall. -- Plankton314 (Diskussion) 18:16, 6. Dez. 2012 (CET)

• Constant-Time Root Scanning for Deterministic Garbage Collection

Ist ein gutes Pro-Argument: "The performance was compared to current implementations that use non-deterministic garbage collection."

etc... --Sebastian.Dietrich ✉ 17:15, 6. Dez. 2012 (CET)

Ich denke wir können festhalten, dass nicht-deterministische GC üblich sind. --Eike (Diskussion) 17:38, 6. Dez. 2012 (CET)

Super - genau das habe ich mir erhofft. Wir können also festhalten, dass es deterministische GCs gibt. Ergo ist Indeterminismus keine notwendige Eigenschaft von GCs. Ergo gehört die Einleitung geändert.Ergo ist die Einleitung inzwischen korrekt. --Sebastian.Dietrich ✉ 18:12, 6. Dez. 2012 (CET)

Sehe ich nicht so. Rein konzeptionell, die konsequente Auskoppelung des Speichermanagments aus dem Programm ist ein inhärent in-deterministischer Ansatz. Das man mit viel Aufwand eine diesem Grundkonzept widersprechende deterministic-GC bauen kann ist eigentlich nur von akademisch-theoretischer Bedeutung da alle praktisch relevanten Implementierungen non-deterministic sind.Shaddim (Diskussion) 18:17, 6. Dez. 2012 (CET)

Theoretisch sind sie nicht - da gibts reale Implementierungen für Echtzeitsysteme. Aber egal, du wirst doch zugeben, dass auch akademisch-theoretische Erkenntnisse der Wahrheit entsprechen. Oder? Ein Satz wie "Indeterminismus ist eine notwendige Eigenschaft von GCs" ist doch falsch oder? Die Aussage "Indeterminismus is keine notwendige Eigenschaft von GCs" ist somit richtig. --Sebastian.Dietrich ✉ 18:24, 6. Dez. 2012 (CET)

Ich würde es so formulieren: "Nicht-determinismus ist eine inhärente Eigenschaft des entkoppelten Speichermanagments, mit speziellen, aufwändigeren Implementierungen (die andere Nachteile besitzen und unüblich sind) kann determinismus jedoch erzielt werden." Shaddim (Diskussion) 18:29, 6. Dez. 2012 (CET)

:-) ja ok, wenn du das so siehst - solange du das nicht so in den Artikel schreibst. --Sebastian.Dietrich ✉ 18:43, 6. Dez. 2012 (CET)

Eine der wenigen real-existierenden hinweis für eine determinstische implementierung scheint die eigeneinschätzung von metronom zu sein. Jedoch gibt es darüber kontroversen darüber ob metronom "determinismus" erreicht oder nur "echt-zeitfahigkeit", mit dem ansatz fixer, kurzer Aufräum-Perioden. Auch der englische en:Garbage_collection_(computer_science)#Determinism artikel formuliert dies so: "While garbage collection is generally nondeterministic, it is possible to use it in hard real-time systems." Auch der Trouble-shooting artikel von Oracle zu metronom sagt das beim expliziten callen und im OOM fall die konventionelle Garbage collection aufgrufen wird. Shaddim (Diskussion) 19:05, 6. Dez. 2012 (CET)

Es gibt einige andere real existierende Impls: TimeSys RTSJ Reference Implementation, Java RTS Sun, IBM WebSphere Real Time, OVMJ, JamaicaVM, jRate, Aonix PERC, aJ100, JRockit, LJRT, FijiVM, ... Aber egal ob es real existierende oder nicht gibt - nicht-determinismus ist _keine_ inhärente Eigenschaft entkoppelten Speichermanagements, da (wie du selbst sagst) "mit speziellen, aufwändigeren Implementierungen ... kann determinismus jedoch erzielt werden". Dass Menschen auf der Erde leben ist keine inhärente Eigenschaft des Menschen - mit speziellen aufwändigen Projekten können Menschen auch im Weltall leben. --Sebastian.Dietrich ✉ 11:26, 7. Dez. 2012 (CET)

Hmm, würde schon argumentieren dass das Grundkonzept "Mensch" schon die inhärenten Fähigkeiten zum überleben auf der Erde mitbringt (zumindest statistisch, spezifische "implemntierungen" ausgenommen), im Gegensatz zum Weltraum... würde die nötigen Raumanzüge und Raumfähren als "workarounds/Hacks/extensions" zum Grundkonzept klassifizieren. ;) GC ist von seiner Grundideen ("inhärente Idee") völlig entkoppelt vom eigentlichen Programm, kann also beliebigen unbekannten einfluss nehmen. Dieses Grundsetup ist für mich schon nicht-deterministische, bestätigt darüber das die allermeisten Implemntierungen bestätigt nicht-determinstisch sind. PS: zu deinen implementierungen, die ich nun nur überfliegen konnte, die meistens beschrieben sich selsbt NUR als RT aber nicht als determnistisch, was eine höhere Anforderung sit. Shaddim (Diskussion) 11:51, 7. Dez. 2012 (CET)

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

Feierabend der Determinismus-Diskussion

Leute... Der Artikel bescheinigt GC jetzt "je nach Implementierung ein nicht-deterministisches Laufzeitverhalten". Bestreitet das jemand? Wenn nicht, brauchen wir glaub ich nicht weiter zu diskutieren. --Eike (Diskussion) 11:37, 7. Dez. 2012 (CET)

Der letzte Teil dieser Diskussion hat eigentlich nur noch klarer herausgestellt, dass GC meistens, d. h. bis auf Sonderfälle nicht deterministisch ist. Darum ist die Formulierung - wie in der englischsprachigen WP - anzupassen. -- Plankton314 (Diskussion) 11:40, 7. Dez. 2012 (CET)

Ich unterstütze das. Wobei man sich auch die Sonderfälle genauer ankucken könnte, aber... geschenkt. Wie weiter oben mal gesagt: Es ist das Wesen der Garbage Collection, dass der Anwendungsprogrammierer Kontrolle abgibt. --Eike (Diskussion) 11:48, 7. Dez. 2012 (CET)

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)

+1 für die Formulierung: "Es ist das Wesen der Garbage Collection, dass der Anwendungsprogrammierer (und auch das laufende Programm) Kontrolle abgibt." aktuelle Formulierung in der Einleitung akzeptabel. Shaddim (Diskussion) 11:53, 7. Dez. 2012 (CET)

nochmal: sowohl der link auf determinismus als auch auf determinismus (Algorithmus) ist und war/wäre falsch... darum darf das nicht im artikel bleiben... es mag sein, dass „determinismus“ durch leichtfertige übersetzungen durch fachfremde ein homonym geworden ist, aber das ist noch lange kein grund für den falschen link... --Heimschützenzentrum (?) 12:58, 7. Dez. 2012 (CET)

Ich verstehe deine Probleme mit beiden Determinismus Links nicht, scheinen mir beide den Kern des Konzepts "determinismus" abzubilden. Sind sie dir nicht spezifisch/scharf oder nicht Software bezogen genug? Shaddim (Diskussion) 13:42, 7. Dez. 2012 (CET)

jetzt gebt fein acht: das problem ist, dass der Begriff „deterministischer Algorithmus“ hier nicht passt, weil ein computer ein sehr deterministisches Ding ist... das was ihr hier offenbar meint, sind undefinierte Ergebnisse, die durch fehlerhafte Sperrprotokolle entstehen können, weil man eben _praktisch_ nicht den vorherigen Zustand wieder herstellen kann... aber: wenn man den gleichen Zustand (inklusive aller elektrönchen und photönchen, die dieselben Busfehler verursachen...) herstellen könnte, dann wäre auch das ergebnis wieder das gleiche... determinismus pur also... jetzt geht in euch, damit ich nicht noch mein rentnerdasein aufgeben muss, weil eure programm klappriger schrott sind... --Heimschützenzentrum (?) 15:48, 7. Dez. 2012 (CET)

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

Allokation

Was bisher fehlt, ist eine Erwähnung, dass der GC auch die Allokation übernimmt. Bei .NET und Java ist das definitiv der Fall. Das GC-Handbook gibt keine explizite Aussage, erwähnt aber immer wieder indirekt, dass auch über den GC angefordert wird.

Kennt jemand bedeutende Ausnahmen? Ansonsten würde ich das als inhärente Eigenschaft mit aufnehmen.

PS: Die konservative GC ist natürlich eine Ausnahme, fragt sich, wie relevant die [heutzutage] noch ist. -- Plankton314 (Diskussion) 14:14, 8. Dez. 2012 (CET)

so eine pathologische begriffsausweitung kann man vllt ganz unten erwähnen... oder man nennt den artikel anders (z B „automatische Speicherverwaltung“)... --Heimschützenzentrum (?) 14:37, 8. Dez. 2012 (CET)

GC ist eine automatische Speicherverwaltung. Und was steht wohl im ersten Satz der Einleitung? -- Plankton314 (Diskussion) 14:44, 8. Dez. 2012 (CET)

der ist auch in lächerlicher weise falsch... :-) --Heimschützenzentrum (?) 15:00, 8. Dez. 2012 (CET)