Sprache 'D' fertiggestellt - wie geht's weiter ?

[Gast]

Apollon schrieb:

rüdiger schrieb:

Zeus schrieb:

Optimizer schrieb:

Was mich bei D äußerst stutzig macht, ist btw. der konservative GC. Gibt es in der Sprache keine eigenen Zeiger-Typen für Objekte auf dem GC-Heap? Wenn nicht, dann wird der GC wahrscheinlich nie richtig geil werden und das ist schlimmer, als wenn sie ihn weggelassen hätten...

Jetzt bitte ich mal um erklärung, warum du ein besonderen Zeiger willst. O.O

Weil der GC wissen muss, was ein Zeiger ist und was nicht.

Dafuer muss man Zeiger aber nicht zwangsweise auszeichnen. Ein GC kann es auch selbst rausfinden.

Nein, er kann nur konservative Annahmen machen, was ein Zeiger sein könnte. Es kann aber auch irgendeine Bit-Kombination zufällig (und sooo unwahrscheinlich wäre das schon nicht) auch ein gültiger Zeiger sein. Was du mit "selber rausfinden" meinst, beschreibt genau einen konservativen GC. Mach' dir keine Hoffnung - ein konservativer GC wird nie geil sein. Er braucht sehr lange um alle möglichen Zeiger zu identifizieren, er arbeitet ungenau ( = lässt Objekte stehen, entfernt Objekte die über Pointer-Arithmetik noch erreichbar wären) und ist noch ein zweites mal langsam, weil er den Heap nicht kompaktieren kann. Denn dazu müsste er Objekte verschieben und die Zeiger darauf anpassen können, was nicht möglich ist, wenn er Zeiger nicht zweifelsfrei identifizieren kann.

[mikey]

Ich weis zwar nicht, von was ihr da gerade redet, aber egal

Ich hab zu dem Thema mal einen kleinen Artikel auf meiner Homepage verfasst.
Könnt ihr euch mal gerne durchlesen ---> www.cpp-world.de

Zu finden unter den News.

Aja, und was ist ein GC ??

Grüße,

mikey.

[Julian__]

ich glaub
Garbage Collector
oder?
.. geraten, die erste gc-abkürzung die mir eingefallen ist.

mfg,
julian

[mikey]

Ohje, ich glaub da muss jetzt Wikipedia herhalten ...

[Apollon]

Es stimmt schon und ist mir bekannt. Ich habe mal einen GC fuer C implementiert. Aber...

Optimizer schrieb:

[...] er arbeitet ungenau ( = lässt Objekte stehen, entfernt Objekte die über Pointer-Arithmetik noch erreichbar wären) [...]

Genau das tuht er nicht. Er laesst Objekte stehen, falls ein Bitmuster zufaellig als gueltige Adresse durchgeht, auch wenn es das nicht ist, aber dass er gueltige Objekte entfernt ist mir neu.

Optimizer schrieb:

Er braucht sehr lange um alle möglichen Zeiger zu identifizieren [...]

So lange nun auch nicht. Es reicht aus, wenn man lediglich den Codebereich scannt. Von da an sind die Objektgroessen, auf die potentielle Zeiger verweisen, bekannt.

EDIT: 5 Stunden lang postet keiner und wenn ich einen Beitrag verfasse, kommen sie daher und quetschen sich dazwischen. Mein Beitrag bezog sich auf Optimizer.

[Gast]

Apollon schrieb:

Es stimmt schon und ist mir bekannt. Ich habe mal einen GC fuer C implementiert. Aber...

Optimizer schrieb:

[...] er arbeitet ungenau ( = lässt Objekte stehen, entfernt Objekte die über Pointer-Arithmetik noch erreichbar wären) [...]

Er laesst Objekte stehen, falls ein Bitmuster zufaellig als gueltige Adresse durchgeht, auch wenn es das nicht ist, aber dass er gueltige Objekte entfernt ist mir neu.

Natürlich entfernt er ein Objekt nicht, wenn ein Zeiger direkt darauf verweist. Du hast die relevante Stelle sogar mitzitiert.

So lange nun auch nicht. Es reicht aus, wenn man lediglich den Codebereich scannt.

Und die Stacks und den Heap, wenn man den Zeigern folgt. Ich weiß nicht genau, was du mit Code-Bereich meinst. Wenn du das Segment meinst, in dem sich der Programmcode befindet, wie soll das ausreichen?

Die Frage nach der Möglichkeit stellt sich ja nicht. Ich traue dem GC schon zu brauchbar zuverlässig zu arbeiten, aber richtig geil wird er nie sein vor allem vom Performance-Standpunkt aus. Das wird einfach nur die Gerüchte wieder anheizen ("Ich hab das einmal mit und einmal ohne GC gemacht, der GC ist ja soooo langsam" - natürlich ist er das, wenn er schlecht ist). Der richtige Weg bzgl. GC wäre so wie in C++/CLI (auch wenn ich die Sprache sonst nicht mag). So denke ich, dass man nur die Feature-List weiter füllen wollte.

[Blue-Tiger]

Optimizer schrieb:

Der richtige Weg bzgl. GC wäre so wie in C++/CLI (auch wenn ich die Sprache sonst nicht mag). So denke ich, dass man nur die Feature-List weiter füllen wollte.

Ist jetzt zwar OT, aber: wie arbeitet der GC unter C++/CLI und was ist der Unterschied zu der Art, wie er in D arbeitet?

[Apollon]

Optimizer schrieb:

Apollon schrieb:

Es stimmt schon und ist mir bekannt. Ich habe mal einen GC fuer C implementiert. Aber...

Optimizer schrieb:

[...] er arbeitet ungenau ( = lässt Objekte stehen, entfernt Objekte die über Pointer-Arithmetik noch erreichbar wären) [...]

Er laesst Objekte stehen, falls ein Bitmuster zufaellig als gueltige Adresse durchgeht, auch wenn es das nicht ist, aber dass er gueltige Objekte entfernt ist mir neu.

Natürlich entfernt er ein Objekt nicht, wenn ein Zeiger direkt darauf verweist. Du hast die relevante Stelle sogar mitzitiert.

Ja. Die Pointer-Arithmetik. Da aber beim Allozieren die Groesse mitvermerkt wird, sehe ich vorerst kein Problem. Aber vermutlich ist dir da mehr bekannt als mir.

Optimizer schrieb:

So lange nun auch nicht. Es reicht aus, wenn man lediglich den Codebereich scannt.

Und die Stacks und den Heap, wenn man den Zeigern folgt. Ich weiß nicht genau, was du mit Code-Bereich meinst. Wenn du das Segment meinst, in dem sich der Programmcode befindet, wie soll das ausreichen?

Naja. Ausreichen ist vielleicht falsch ausgedrueckt. Das scannen des Codebereiches (Ja. Das Segment wo sich der Programmcode befindet) ist insofern ausreichend, als dass es ausreicht diesen Bereich zu scannen. Die Zeiger die man darin findet verweisen auf Objekte bekannter Groessen. Da reicht es aus den Bereich Adresse + Groesse zu scannen, um zu entscheiden ob sich da weitere Verweise befinden.

Ob der GC von D nun "geil" ist oder nicht, kann und will ich nicht beurteilen. Ich weiss nur, dass konservative GCs recht gute Dienste leisten und in der Praxis auch eingesetzt werden. AFAIK hat Firefox einen fuer JS, vielleicht auch fuer mehr.

Blue-Tiger schrieb:

Optimizer schrieb:

Der richtige Weg bzgl. GC wäre so wie in C++/CLI (auch wenn ich die Sprache sonst nicht mag). So denke ich, dass man nur die Feature-List weiter füllen wollte.

Ist jetzt zwar OT, aber: wie arbeitet der GC unter C++/CLI und was ist der Unterschied zu der Art, wie er in D arbeitet?

Optimizer hats schon angedeutet. Referenzen werden als solche kenntlich gemacht. Durch zusaetzliche Information, Eintraege in Tabellen, etc.. Dies beschleunigt das Wiederfinden von Zeigern und somit das markieren von gueltigen Objekten. Nachteil: zusaetzliche Information muss gespeichert werden.

[THX 1138]

Für C++ braucht man keinen GC, für saubere Ressourcenverwaltung gibt es doch RAII Klassen. GCs sind doch was für Faulpelze und Feiglinge :p

@gurkenesser: fuck you!

[mikey]

Für C++ braucht man keinen GC, für saubere Ressourcenverwaltung gibt es doch RAII Klassen. GCs sind doch was für Faulpelze und Feiglinge

LOL

[groovemaster]

Doktor Prokt schrieb:

Vielleicht sollten wir mal einen C++ vs. Common Lisp Flame aehh Thread eroeffnen. Mal sehen, ob C++ danach noch steht..

Common Lisp? Ist das nicht die Sprache mit den 1001 Klammern?

[Helium]

Apollon schrieb:

Ob der GC von D nun "geil" ist oder nicht, kann und will ich nicht beurteilen. Ich weiss nur, dass konservative GCs recht gute Dienste leisten und in der Praxis auch eingesetzt werden. AFAIK hat Firefox einen fuer JS, vielleicht auch fuer mehr.

Ja klar funktionieren sie und werden auch in der Praxis eingesetzt und sie sind auch nicht schlecht. Aber willst du mir jetzt erklären, das Mark-and-Sweep Collectoren so gut sind, wie generationale kopierende Garbage Collectoren? Wohl kaum.

Ich weiß nicht wirklich, worauf du hinaus willst.

[Apollon]

Helium schrieb:

Apollon schrieb:

Ob der GC von D nun "geil" ist oder nicht, kann und will ich nicht beurteilen. Ich weiss nur, dass konservative GCs recht gute Dienste leisten und in der Praxis auch eingesetzt werden. AFAIK hat Firefox einen fuer JS, vielleicht auch fuer mehr.

Ja klar funktionieren sie und werden auch in der Praxis eingesetzt und sie sind auch nicht schlecht. Aber willst du mir jetzt erklären, das Mark-and-Sweep Collectoren so gut sind, wie generationale kopierende Garbage Collectoren? Wohl kaum.

Watt? Wer bist Du denn? Nein. Im Ernst. Wieso sollte ich Dir war erklaeren? Ich habe lediglich an der Diskussion teilgenommen. Und behauptet, dass konservative GCs so gut wie "generationale kopierende" GCs sind habe ich nirgends. Ich habe lediglich gesagt, dass GCs nicht im Voraus wissen muessen, was ein Verweis ist und was nicht.