C++ zu Java
-
Bashar schrieb:
Genauso wie alle anderen Pointer. Ich weiß nicht worauf du hinaus willst, anscheinend weißt du ja, was ein konservativer GC ist. Oder?
Ja. Darum geht es ja auch eigentlich gerade. In C++ ist es IMHO ein bisschen riskant, einfach zu vermuten, was ein Pointer ist, und was nicht. Entweder ich benutze einen Compiler, der diese Information einarbeitet und habe kein Standard C++ mehr oder ich kriege keinen "korrekten" GC hin, IMHO.
Gerade in Java ist ein GC oft aber auch als letzte Sicherheits-Instanz für andere Resourcen als RAM verantwortlich. Ich denke nicht, dass man mit einem konservativem Collector gut bedient ist.Allerdings haben wir ja nicht mit beliebigen Programmen, sondern nur mit konvertierten Java-Programmen zu tun. Die werden ganz sicher keine über Array-indizierung hinausgehende Pointerarithmetik machen ...
Da hast du nun auch wieder recht. Ich würde dir niemals widersprechen. *anbet* *räucherstäbchen anzünd*
-
interpreter schrieb:
SirLant schrieb:
Ihr vergesst da was ganz wichtiges: die Bibliotheken
Wieso?
Wenn du nen Java zu C++ Compiler hast, dann kannst du den Code zwar konvertieren, aber laufen tut er nacher trotzdem nicht, wenn du keine C++-Bibliothek mit der gleichen Schnittstelle hast
-
Ponto schrieb:
Anderseits haben wir hier immer noch den Fall, dass wir Java automatisch nach C++ umwandeln wollen. Da wird das nicht passieren. Der Code, der rauskommt wird ganz harmlos sein, genauso wie Javacode fuer C++ Verhaeltnisse immer harmlos ist.
Jup, gebe ich dir Recht
.A mark-sweep garbage collector traverses all reachable objects in the heap by following pointers beginning with the "roots", i.e. pointers stored in statically allocated or stack allocated program variables. All such reachable objects are marked. A sweep over the entire heap is the performed to restore unmarked objects to a free list, so they can be reallocated.
Also wird der wohl auf dem Stack anfangen.Damit willst du was aussagen? Mir ist gerade der Bezug nicht klar.
-
Optimizer schrieb:
A mark-sweep garbage collector traverses all reachable objects in the heap by following pointers beginning with the "roots", i.e. pointers stored in statically allocated or stack allocated program variables. All such reachable objects are marked. A sweep over the entire heap is the performed to restore unmarked objects to a free list, so they can be reallocated.
Also wird der wohl auf dem Stack anfangen.Damit willst du was aussagen? Mir ist gerade der Bezug nicht klar.
Dass der auch Zeiger auf dem Stack findet.
-
Das ist ja nicht der Punkt. Der Punkt ist, dass er nicht weiß, ob etwas ein Zeiger ist, oder einfach etwas anderes, was zufällig als eine gültige Adresse in den Heap interpretiert werden kann.
Der GC nimmt einfach mal an, dass alles, was eine gültige Adresse ist, ein Zeiger ist, weil er keine Möglichkeit hat, diese beiden Fälle zu unterscheiden. Deshalb nennt man ihn auch konservativ. Wenn finalizer jedoch eine wichtige Aufgabe zu erledigen haben, taugt ein konservativer Collector "nichts", weil dann nicht garantiert wird, dass die finalizer alle aufgerufen werden, wenn sie ausstehen würden.
-
Der Aufruf von Finalizern ist doch eh nicht garantiert.
-
Glaubst du, dass der Sun-GC ein konservativer ist? Das würde mich schocken.
Ich dachte immer, der GC ruft nur beim Programmende nicht mehr alle Finalizer auf. Das kann man aber auch noch beeinflussen mit runFinalizersOnExit() oder so ähnlich.
-
Optimizer schrieb:
30%... 90%.... welche wissenschaftlichen Studien habt ihr euch reingezogen?
Also, dass eine gewisse Ähnlichkeit vorhanden ist kann man denke ich nicht abstreiten. Prozentangaben sind in diesem Fall natürlich absoluter Humbug, genau wie ein Konverter. Ein Programm wird vielleicht mit viel Mühe an die Qualität einer OCR-Texterkennung heran kommen: Nach etlichen Jahren Entwicklungsarbeit bekommt man zwar halbwegs leserliche Texte, aber trotzdem hat man Probleme mit Tabellen, Formeln oder Bildern
.
-
Optimizer schrieb:
Glaubst du, dass der Sun-GC ein konservativer ist?
Quark.
Ich dachte immer, der GC ruft nur beim Programmende nicht mehr alle Finalizer auf.
Eben. Aber der GC wird auch nicht notwendigerweise vor Programmende aufgerufen.
-
Was ich etwas seltsam finde, ehrlich gesagt. Ich weiß, dass es so ist. Aber selbst wenn der Heap nicht bereinigt werden müsste, kann man doch locker am Ende alle finalizer aufrufen. AFAIK sind alle Objekte, die finalisierung wünschen, in einer Liste beim GC registriert. Die müsste er eigentlich nur abarbeiten.
Bei .Net wird dies auch so gemacht.EDIT: Naja, man kann es durch Funktionsaufruf eh einstellen, von daher kein Problem.
Quark.
Gut, Weltbild gerettet.
-
Diese Liste könnte man aber auch bei einem konservativen GC unterhalten.
-
Der würde aber, wenn es blöd läuft, wirklich erst am Programmende alle finalizer aufrufen. Wenn das jetzt irgendein Server-Programm ist, besteht bei statischen Variablen (oder sogar Konstanten) oder Variablen, die im Stack Trace ganz unten sind (in der Umgebung von main()), die keine Referenzen sind, aber als Referenzen interpretiert werden, die Möglichkeit, dass bestimmte Finalizer nie anlaufen.
Natürlich ist mir auch klar, dass man unmanaged Resourcen von Hand freigeben sollte.
Aber IMHO macht das nicht jeder und man kann es ja auch wirklich mal vergessen. Das ist halt der Preis von RAD, was ja heute so hipp ist.(Ich glaube, ich habe oben den längsten Satz geschrieben, den es in diesem Forum gibt.
)
Zumindest fühle ich mich mit "richtigem" GC wohler.
-
Schlechte Programme (die sich auf Finalizer verlassen) werden halt nicht ganz korrekt umgewandelt. Damit kann man doch leben
-
BTW: Wenn man Reflection implementieren kann, warum dann nicht auch einen richtigen GC? Oder hat wer was davon gesagt, dass der C++-Code dem Java-Code zum verwechseln ähnlich sein soll? Muss der C++-Code wartbar sein? Oder verstehen wir den Java->C++-Umsetzer als Compiler?
Das Pointer-Layout der Klasse könnte mit der vtable und der (um Reflection-Dinge erweiterten) rtti zusammen abgelegt werden. Naja, ich glaube aber irgendwie, das geht über das, was dem OP vorschwebte (das war doch eigentlich sowieso C++->Java oder *g*) hinaus.
-
BTW: Wenn man Reflection implementieren kann, warum dann nicht auch einen richtigen GC?
Meinst du damit, einen nicht-konservativen GC? IMHO müsste man dann gewisse Informationen in die Binaries mit einarbeiten.
Und/Oder Klassen und Stack Frames nach einem festen Prinzip layouten. Ich glaube aber nicht, dass C++ Implementierungen verpflichtet sind, Datenelemente und lokale Variablen nach einem bestimmten Prinzip anzuordnen. Ich stelle mir das kompliziert vor.
Sicherlich, ein funktionierendes Binary zu erzeugen würde bestimmt gehen, aber Standardkonformen C++ Code, ich weiß nicht.
-
mit offsetof() geht das bestimmt
-
Du wirst es schon wissen.
Damit würde man wahrscheinlich jetzt wirklich Java-Code nach (extrem schlecht wartbaren) C++ Code übersetzen können. Oder haben wir noch irgendwas ungeklärtes? (z.B. der Sinn von dem Ganzen )
-
Jetzt habe ich gerade etwas kurz gedacht. Kann man in C++ überhaupt den aktuellen Stack Trace nachvollziehen? Wie sieht es mit Thread aus?
Ne, ich glaub, so leicht wird das nicht werden.