Discussion:
ARC für Win32, Win64?
(zu alt für eine Antwort)
Jens Lenge
2014-10-08 08:16:05 UTC
Permalink
Hallo Welt,

vor einiger Zeit war zu lesen, dass Delphi-Objekte mit ARC ausgestattet
werden sollen (oder bereits wurden). Die Meldung betraf aber IIRC nur
die neueren Mobilcompiler.

Weiß jemand, ob sowas auch für Win32 und/oder Win64 geplant ist?
Und wann ggf. damit zu rechnen ist?
Hans-Peter Diettrich
2014-10-08 12:33:18 UTC
Permalink
Post by Jens Lenge
Hallo Welt,
vor einiger Zeit war zu lesen, dass Delphi-Objekte mit ARC ausgestattet
werden sollen (oder bereits wurden). Die Meldung betraf aber IIRC nur
die neueren Mobilcompiler.
Weiß jemand, ob sowas auch für Win32 und/oder Win64 geplant ist?
Und wann ggf. damit zu rechnen ist?
Bei Embarcadero ist alles möglich :-]

Ich vermute mal, daß ARC für die Integration von Plattformen mit Garbage
Collection erfunden wurde, und dort möglicherweise unumgänglich ist. Für
eine Ausdehnung auf weitere Plattformen spricht dann die einheitliche
Code-Basis, dagegen spricht die Inkompatibilität mit altem Code.
Insbesondere die VCL scheint mir nicht so richtig zu ARC zu passen,
vielleicht einer der Gründe für das Scheitern der VCL.NET.

Mein Tipp: ARC kommt für FireMonkey, die VCL bleibt ohne ARC. Aber wie
gesagt:

Bei Embarcadero ist alles möglich :-]

DoDi
Matthias Eißing
2014-10-08 16:06:50 UTC
Permalink
Post by Hans-Peter Diettrich
Ich vermute mal, daß ARC für die Integration von Plattformen mit Garbage
Collection erfunden wurde, und dort möglicherweise unumgänglich ist.
ARC (compile-time) hat mit Garbage Collection (run-time) sehr wenig zu
tun.... außer der Einordnung in "Speichermanagement" im Allgemeinen.
--
cu://Matthias.Eißing.de
Jens Lenge
2014-10-08 16:20:46 UTC
Permalink
Post by Matthias Eißing
ARC (compile-time) hat mit Garbage Collection (run-time) sehr wenig zu
tun.... außer der Einordnung in "Speichermanagement" im Allgemeinen.
Yep. Aber die spannende Frage bleibt: Kommt das auch für "herkömmliche"
Desktop-Compiler (sprich Win32, Win64)?
Matthias Eißing
2014-10-15 08:43:50 UTC
Permalink
Post by Jens Lenge
Yep. Aber die spannende Frage bleibt: Kommt das auch für "herkömmliche"
Desktop-Compiler (sprich Win32, Win64)?
Langfristig denken wir das zu planen (Win32/64).

(Ich weiß, daß diese Aussage wachsweich ist)
--
cu://Matthias.Eiß***@iOS
Jens Lenge
2014-10-16 12:00:24 UTC
Permalink
Post by Matthias Eißing
Langfristig denken wir das zu planen (Win32/64).
(Ich weiß, daß diese Aussage wachsweich ist)
Trotzdem danke für die Info. :)

Hans-Peter Diettrich
2014-10-08 16:27:30 UTC
Permalink
Post by Matthias Eißing
Post by Hans-Peter Diettrich
Ich vermute mal, daß ARC für die Integration von Plattformen mit Garbage
Collection erfunden wurde, und dort möglicherweise unumgänglich ist.
ARC (compile-time) hat mit Garbage Collection (run-time) sehr wenig zu
tun.... außer der Einordnung in "Speichermanagement" im Allgemeinen.
Ich weiß nicht, ob wir hier über die gleiche Sache (Automatic Reference
Counting) reden. Das ist IMO eine Form von Garbage Collection, die nur
anders funktioniert als das typischerweise mit GC assoziierte mark-sweep
Verfahren. Zwar muß hierfür der Compiler die Aufrufe zum Zählen
eincompilieren, aber das Zählen und Löschen der Objekte erfolgt zur
Laufzeit (und zwar synchron, im Gegensatz zu den sonst üblichen Verfahren).

Beim Nachschlagen bin ich eben noch über Objective-C gestolpert, damit
wäre ARC auch noch ein Kandidat für die Mac-Plattform. Weißt Du
vielleicht schon mehr zur Ausgangsfrage?

DoDi
Jens Lenge
2014-10-08 16:17:55 UTC
Permalink
Post by Hans-Peter Diettrich
Ich vermute mal, daß ARC für die Integration von Plattformen mit Garbage
Collection erfunden wurde, und dort möglicherweise unumgänglich ist.
ARC und Garbage Collection sind prinzipiell unterschiedliche Ansätze.
Ein vernünftig implementiertes ARC macht eine GC weitgehend überflüssig.
Post by Hans-Peter Diettrich
Mein Tipp: ARC kommt für FireMonkey, die VCL bleibt ohne ARC.
Hmmm... *falls* Delphi-Objekte ARC bekommen, dürfte es schwierig werden,
die VCL auszusparen, zumindest soweit Sie auf Objekten beruht.

Kompatibilitätsprobleme mit bestehendem "Altcode" sehe ich nicht, man
braucht ".Free" ja einfach nur totzulegen. Machen die Mobilcompiler IIRC
auch so und bleiben zu Altcode mit (nunmehr überflüssigen)
try-finally-Blöcken kompatibel.
Hans-Peter Diettrich
2014-10-08 16:50:16 UTC
Permalink
Post by Jens Lenge
Post by Hans-Peter Diettrich
Ich vermute mal, daß ARC für die Integration von Plattformen mit Garbage
Collection erfunden wurde, und dort möglicherweise unumgänglich ist.
ARC und Garbage Collection sind prinzipiell unterschiedliche Ansätze.
Ein vernünftig implementiertes ARC macht eine GC weitgehend überflüssig.
Ich sehe ARC nur als *ein* Verfahren, um GC zu implementieren.
Post by Jens Lenge
Post by Hans-Peter Diettrich
Mein Tipp: ARC kommt für FireMonkey, die VCL bleibt ohne ARC.
Hmmm... *falls* Delphi-Objekte ARC bekommen, dürfte es schwierig werden,
die VCL auszusparen, zumindest soweit Sie auf Objekten beruht.
Kompatibilitätsprobleme mit bestehendem "Altcode" sehe ich nicht, man
braucht ".Free" ja einfach nur totzulegen. Machen die Mobilcompiler IIRC
auch so und bleiben zu Altcode mit (nunmehr überflüssigen)
try-finally-Blöcken kompatibel.
IMO kommt man oft nicht drum herum, Schleifen (zirkuläre Referenzen)
manuell aufzubrechen bzw. mit WeakReference konstruktiv zu eliminieren.
Ich bezweifle jedenfalls, daß ein Compiler das selbständig hinbekommt,
und da kommt die VCL mit dem Child/Owner Konzept ins Spiel.

Dann sollte man statt Free besser FreeAndNil benutzen, um solche
Schleifen aufzubrechen. Das dürfte einigen Programmierern nicht
schmecken, die FreeAndNil als ein Zeichen für schlechten Programmierstil
halten.

Da man nicht viel davon merkt, wenn ARC Zombies im Speicher zurückläßt,
sind Probleme mit Altcode erst zu erkennen, wenn der Speicher überläuft
oder (bei 64 Bit Code) die Platte (Swapfile) zugemüllt wird.

DoDi
Jens Lenge
2014-10-08 17:21:25 UTC
Permalink
Post by Hans-Peter Diettrich
Ich sehe ARC nur als *ein* Verfahren, um GC zu implementieren.
Ok, kommt auf die Sichtweise an. Kann u. U. auch als "statische
deterministische GC" durchgehen. ;)
Post by Hans-Peter Diettrich
IMO kommt man oft nicht drum herum, Schleifen (zirkuläre Referenzen)
manuell aufzubrechen bzw. mit WeakReference konstruktiv zu eliminieren.
Ich bezweifle jedenfalls, daß ein Compiler das selbständig hinbekommt,
und da kommt die VCL mit dem Child/Owner Konzept ins Spiel.
Ja, da könnten Fallstricke lauern. BTW: Ist denn die VCL bei den
Mobilcompilern komplett außen vor? Sonst müssten die Jungs das doch
schon hinbekommen haben.
Hans-Peter Diettrich
2014-10-09 03:08:16 UTC
Permalink
Post by Jens Lenge
Post by Hans-Peter Diettrich
Ich sehe ARC nur als *ein* Verfahren, um GC zu implementieren.
Ok, kommt auf die Sichtweise an. Kann u. U. auch als "statische
deterministische GC" durchgehen. ;)
Wie würdest Du denn GC definieren, damit ARC *nicht* drunterfällt?
Post by Jens Lenge
Post by Hans-Peter Diettrich
IMO kommt man oft nicht drum herum, Schleifen (zirkuläre Referenzen)
manuell aufzubrechen bzw. mit WeakReference konstruktiv zu eliminieren.
Ich bezweifle jedenfalls, daß ein Compiler das selbständig hinbekommt,
und da kommt die VCL mit dem Child/Owner Konzept ins Spiel.
Ja, da könnten Fallstricke lauern. BTW: Ist denn die VCL bei den
Mobilcompilern komplett außen vor? Sonst müssten die Jungs das doch
schon hinbekommen haben.
Kai Neahnung, meine neueste Version ist XE und damit spiele ich auch nur
etwas herum. Mein Handy liegt seit Jahren praktisch unbenutzt herum, und
programmieren läßt es sich schon garnicht, damit habe ich weder Bedarf
noch Möglichkeiten, mich mit Programmen für Mobiles zu befassen.
Attraktiv wäre für mich neben Windows nur noch Linux, und dafür reicht
mir Lazarus.

DoDi
Jens Lenge
2014-10-09 07:12:27 UTC
Permalink
Post by Hans-Peter Diettrich
Wie würdest Du denn GC definieren, damit ARC *nicht* drunterfällt?
ARC = Statisches und deterministisches Freigeben, Zeitpunkte stehen zur
compilezeit weitgehend fest

GC = Dynamisches search & destroy zur Laufzeit (nach welcher Strategie
auch immer)

Sind IMO eher konkurrierende Ansätze für Speichermanagement. Aber ich
will da nicht wirklich um Begrifflichkeiten streiten; wichtig ist nur,
ob und wann wir das im real existierenden Win32/Win64-Delphi nutzen
können. Mobil ist für uns weitgehend out of scope.
Hans-Peter Diettrich
2014-10-09 17:02:06 UTC
Permalink
Post by Jens Lenge
Post by Hans-Peter Diettrich
Wie würdest Du denn GC definieren, damit ARC *nicht* drunterfällt?
ARC = Statisches und deterministisches Freigeben, Zeitpunkte stehen zur
compilezeit weitgehend fest
Das stimmt so nicht. Wann die letzte Referenz auf ein Objekt
verschwindet, hängt vom Ablauf des Programms ab, genau wie bei jeder
anderen GC Methode. Nur wird bei ARC genau zu diesem Zeitpunkt das
Objekt auch zerstört (synchron), während sich andere Methoden damit Zeit
lassen (asynchron) und sich das Programm dann in einem undefinierten
Zustand befindet.
Post by Jens Lenge
GC = Dynamisches search & destroy zur Laufzeit (nach welcher Strategie
auch immer)
Eine dynamische Suche läßt sich auch mit ARC kombinieren, um z.B. nach
zyklischen Verweisen zu suchen. Da so eine Suche Zeit kostet, wird sie
nur bei Bedarf (Speichermangel) oder Gelegenheit (OnIdle) durchgeführt,
sonst könnte auch mark-sweep nach jeder Löschung einer Referenz
durchgeführt werden.
Post by Jens Lenge
Sind IMO eher konkurrierende Ansätze für Speichermanagement.
...die alle zur Aufgabe haben, Leichen (garbage) aus dem Speicher zu
klauben (collection).
Post by Jens Lenge
will da nicht wirklich um Begrifflichkeiten streiten;
Das führt auch nicht wirklich weiter ;-)

Es wäre allerdings ein Verkaufsargument, wenn Delphi künftig auch mit GC
werben könnte.
Post by Jens Lenge
wichtig ist nur,
ob und wann wir das im real existierenden Win32/Win64-Delphi nutzen
können. Mobil ist für uns weitgehend out of scope.
Dann hoffe ich für uns beide, daß ARC zumindest abschaltbar wird!

DoDi
Jens Lenge
2014-10-09 18:07:48 UTC
Permalink
Post by Hans-Peter Diettrich
Post by Jens Lenge
ARC = Statisches und deterministisches Freigeben, Zeitpunkte stehen
zur compilezeit weitgehend fest
Das stimmt so nicht. Wann die letzte Referenz auf ein Objekt
verschwindet, hängt vom Ablauf des Programms ab, genau wie bei jeder
anderen GC Methode.
Es ist in vielen Fällen (insbesondere bei lokalen Objekten mit genau
einer Referenz) bereits zur Compilezeit exakt bekannt und kann von
halbwegs optimierenden Compilern diret mit einkompiliert werden. Dass
das nicht alle Fälle abdeckt ist klar, manches geht natürlich erst zur
Laufzeit.
Post by Hans-Peter Diettrich
Eine dynamische Suche läßt sich auch mit ARC kombinieren, [...]
Ja.
Post by Hans-Peter Diettrich
Es wäre allerdings ein Verkaufsargument, wenn Delphi künftig auch mit GC
werben könnte.
Definitiv.
Post by Hans-Peter Diettrich
Dann hoffe ich für uns beide, daß ARC zumindest abschaltbar wird!
Hmmm... mir fällt auf Anhieb (außer evtl. Kompatibilität mit Altcode?)
kein Szenarios ein, in dem man das wollen würde.
Hans-Peter Diettrich
2014-10-10 12:49:03 UTC
Permalink
Post by Jens Lenge
Post by Hans-Peter Diettrich
Post by Jens Lenge
ARC = Statisches und deterministisches Freigeben, Zeitpunkte stehen
zur compilezeit weitgehend fest
Das stimmt so nicht. Wann die letzte Referenz auf ein Objekt
verschwindet, hängt vom Ablauf des Programms ab, genau wie bei jeder
anderen GC Methode.
Es ist in vielen Fällen (insbesondere bei lokalen Objekten mit genau
einer Referenz) bereits zur Compilezeit exakt bekannt und kann von
halbwegs optimierenden Compilern diret mit einkompiliert werden.
IMO überschätzst Du da, was ein Compiler mit erträglichem
Laufzeitaufwand sicher ermitteln kann. Was wenn eine Methode des Objekts
z.B. die Referenz in eine Liste einträgt?

Aus diesem Grund werden ja sogar anonyme Prozeduren als Methoden einer
(ebenfalls anonymen) Klasse implementiert, die dann (notfalls als
Interface) mit ARC verwaltet wird.

Bei C++ ist das Zerstören lokaler Instanzen der Standard, dafür braucht
man kein ARC, sondern eher ein "static" Attribut, das die Speicherklasse
(stack) und damit die Lebensdauer solcher Objekte bestimmt. Damit
könnten Programme sogar schneller werden, wenn beim Erzeugen und Löschen
von Objekten nicht jedesmal der Speichermanager (heap) bemüht werden
muß. In solchen Fällen habe ich desöfteren schon Object statt Class
benutzt, heute kämen dafür Records (mit Methoden) in Frage, die der
Entwickler wahlweise in den Stack oder Heap legen kann.
Post by Jens Lenge
Dass
das nicht alle Fälle abdeckt ist klar, manches geht natürlich erst zur
Laufzeit.
Wo siehst Du überhaupt ein Problem, wenn in Deinem Beispiel am Ende des
Unterprogramms noch eine Überprüfung der Referenzen durchgeführt wird,
bevor das Objekt tatsächlich gelöscht wird? Das befreit den Compiler von
einer detaillierten und möglicherweise fehlerhaften Analyse, und hat
keinen spürbaren Einfluß auf Speicherbedarf und Laufzeit.
Post by Jens Lenge
Post by Hans-Peter Diettrich
Dann hoffe ich für uns beide, daß ARC zumindest abschaltbar wird!
Hmmm... mir fällt auf Anhieb (außer evtl. Kompatibilität mit Altcode?)
kein Szenarios ein, in dem man das wollen würde.
Alte Gewohnheiten lassen sich nicht so einfach ändern, und die
Verwendung von automatischer Speicherverwaltung befreit den Entwickler
keineswegs vom Mitdenken - er muß sich nur *andere* Gedanken über seine
Objekte machen, und ggf. das gewohne Free() durch Finalize() ersetzen.

DoDi
Jens Lenge
2014-10-11 14:16:05 UTC
Permalink
Post by Hans-Peter Diettrich
IMO überschätzst Du da, was ein Compiler mit erträglichem
Laufzeitaufwand sicher ermitteln kann.
Nein. Ich zielte wie geschrieben auf den Fall, dass eine Anzahl von
Objekten ausschließlich lokal innerhalb einer Prozedur erzeugt und
verwendet wird. Hier wird jeder halbwegs moderne Compiler die
Desktruktoraufrufe am Ende der Prozedur fest mit einkompilieren.

Numerische und logische Operationen, deren Operaden und Ergebnis zur
Compilerzeit bereits eindeutig feststehen, werden von aktuellen
Compilern in der Regel zuverlässig wegoptimiert.
Post by Hans-Peter Diettrich
Was wenn eine Methode des Objekts z.B. die Referenz in eine Liste einträgt?
Dann hast Du einen anderen Fall als den geschilderten. :)
Aber auch dann wird jedes Objekt deterministisch genau dann freigegeben,
wenn die letzte Referenz verschwindet.
Post by Hans-Peter Diettrich
Bei C++ ist das Zerstören lokaler Instanzen der Standard, dafür braucht
man kein ARC, sondern eher ein "static" Attribut, das die Speicherklasse
(stack) und damit die Lebensdauer solcher Objekte bestimmt.
C++ braucht dafür kein ARC, weil Objekte dort keine impliziten Pointer
sind (vergleichbar etwa mit Records in Delphi).
Post by Hans-Peter Diettrich
Wo siehst Du überhaupt ein Problem, wenn in Deinem Beispiel am Ende des
Unterprogramms noch eine Überprüfung der Referenzen durchgeführt wird,
bevor das Objekt tatsächlich gelöscht wird? Das befreit den Compiler von
einer detaillierten und möglicherweise fehlerhaften Analyse, und hat
keinen spürbaren Einfluß auf Speicherbedarf und Laufzeit.
Wiese sollte ich da ein Problem sehen? Genauso funktioniert ARC. Ich war
im Schritt dahinter: Dort, wo das Ergebnis der Überprüfung zur
Compilezeit bereits feststeht, kann der Compiler sie bereits zur
Compilezeit wegoptimieren und wird das in den einfachen Fällen auch tun.
Post by Hans-Peter Diettrich
Alte Gewohnheiten lassen sich nicht so einfach ändern, und die
Verwendung von automatischer Speicherverwaltung befreit den Entwickler
keineswegs vom Mitdenken - er muß sich nur *andere* Gedanken über seine
Objekte machen, [...]
Stimmt natürlich. Trotzdem wäre es schön, auf die (dann) haufenweise
überflüssigen try-finally-Blöcke verzichten zu können, die den Code
unübersichtlich zerklüften.
Hans-Peter Diettrich
2014-10-11 22:17:40 UTC
Permalink
Post by Hans-Peter Diettrich
IMO überschätzst Du da, was ein Compiler mit erträglichem
Laufzeitaufwand sicher ermitteln kann.
Nein. [...]
Doch. Aber ich verzichte auf weitere Erklärungen, angesichts Deines
profunden Unwissens um das Thema, Delphi, C++ usw. :-(

DoDi
Jens Lenge
2014-10-12 18:18:42 UTC
Permalink
Post by Hans-Peter Diettrich
Nein. [...]
Doch. Aber ich verzichte auf weitere Erklärungen, angesichts Deines
profunden Unwissens um das Thema, Delphi, C++ usw. :-(
DoDi
Von mir aus. Ich erinnere mich noch gut an Dein profundes Unwissen über
C++ beim Thema Mehrfachvererbung und virtuelle Funktionen, da kann ich
auf weitere Ausführungen an dieser Stelle gut verzichten. :(
Lesen Sie weiter auf narkive:
Loading...