C++ zu Java
-
Ich glaube hier entsteht so langsam eine neue Religion...oder ein Mythos? Oder gar ein Fetisch? Der Basharismus.....mmmh klingt sogar ganz gut. :p
-
CarstenJ schrieb:
Ich glaube hier entsteht so langsam eine neue Religion...oder ein Mythos? Oder gar ein Fetisch? Der Basharismus.....mmmh klingt sogar ganz gut. :p
Götzendienst?
-
Optimizer schrieb:
Der entdeckt auch nicht alle unreferenzierten Objekte. Steht sogar im ersten Satz schon drin.
Im übrigen wäre diese Ableitung noch das kleinste Problem. Der GC muss auch bei Funktionsaufrufen wissen, wo im Stack Frame Pointer zu finden sind.
Da ich diese Informationen auch von Bashar hab, zweifelst du sie besser nicht an.Und wo liegt das Problem genau im Stack?
-
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
-
Optimizer schrieb:
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
Das ist das normale Argument gegen GC in C++. Aber, wer das macht, hat es nicht anders verdient.
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.
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.
-
Optimizer schrieb:
Sag mir halt, wie du im Stack Pointer in den Heap erkennst, ohne irgendeine bestimmte Vorgabe über den Aufbau des Stack Frames zu machen.
Genauso wie alle anderen Pointer. Ich weiß nicht worauf du hinaus willst, anscheinend weißt du ja, was ein konservativer GC ist. Oder?
Und sag mir bitte bei der Gelegenheit auch gleich noch, wie ein GC erkennt, dass es zwar keinen Zeiger auf dein Objekt gibt, aber du früher mal die Adresse genommen hast, mit 73 multipliziert, mit 0xfe548701 geXORt hast und die Adresse jederzeit wieder herstellen und damit auf das Objekt zugreifen kannst.
Gar nicht. Das ist eine Schwachstelle, die jeder GC hätte. BZW einer der Gründe, warum C++ im gegenwärtigen Zustand auf keinen Fall einen richtigen GC bekommen kann. Dazu müssten solche Aktionen zunächst vom Standard als illegal eingestuft werden.
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 ...
-
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.