C++ zu Java
-
Ihr vergesst da was ganz wichtiges: die Bibliotheken
-
SirLant schrieb:
Ihr vergesst da was ganz wichtiges: die Bibliotheken
Wieso?
-
Optimizer schrieb:
Ponto schrieb:
Bashar schrieb:
Was ich als großes Problem ansehen würde, ist, dass C++ keinen GC hat.
Das Tool kann ja für alle Speicherallokationen einen der verfügbaren C++ Garbage Collectoren benutzen.
Stelle nie in Frage, was Bashar sagt. Ich stimme ihm übrigens zu.
Und was kann man mit den C++ Garbage Collectoren nicht machen. Das einzige Problem könnten finalize Methoden sein. Aber auch das ist eigentlich kein großes Problem.
-
Du scheinst nicht so wirklich Ahnung davon zu haben. Finalizer sind vermutlich das geringste Problem. Es ist in C++ nicht so ohne weiteres möglich, mit Sicherheit alle nicht referenzierten Objekte zu erkennen, außer du nimmst strengste Einschränkungen in Kauf wie z.B. dass du forderst, dass alle Klassen von deiner GC-Klasse ableiten ö.a.
Das ist auch nur die Spitze des Eisbergs.
Außerdem glaube ich sowieso nicht, dass Bashar technische Probleme gemeint hat, sondern einfach Probleme, die sich aus der unterschiedlichen Art der Programmierung ergeben, mit und ohne GC, C++ und Java.
-
Optimizer schrieb:
Stelle nie in Frage, was Bashar sagt.
Oh doch, ich bitte darum.
Ich stimme ihm übrigens zu.
Vielleicht muss ich über meine Aussage nochmal nachdenken ;->
-
Optimizer schrieb:
Du scheinst nicht so wirklich Ahnung davon zu haben. Finalizer sind vermutlich das geringste Problem. Es ist in C++ nicht so ohne weiteres möglich, mit Sicherheit alle nicht referenzierten Objekte zu erkennen, außer du nimmst strengste Einschränkungen in Kauf wie z.B. dass du forderst, dass alle Klassen von deiner GC-Klasse ableiten ö.a.
Das ist auch nur die Spitze des Eisbergs.
Außerdem glaube ich sowieso nicht, dass Bashar technische Probleme gemeint hat, sondern einfach Probleme, die sich aus der unterschiedlichen Art der Programmierung ergeben, mit und ohne GC, C++ und Java.Es geht darum, Java automatisch nach C++ zu konvertieren. Da kann man ganz leicht auf Situationen verzichten, die den Garbage Collector durcheinander bringen. Hast du dir mal den Boehm GC angeschaut. http://www.hpl.hp.com/personal/Hans_Boehm/gc/. Da muss auch nicht alles vom GC ableiten.
-
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.Bashar schrieb:
Vielleicht muss ich über meine Aussage nochmal nachdenken ;->
Wird dir nichts nützen, dann werde ich deine neue Aussage auch assimilieren.
-
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.