Objective C Garbage Collection in 10.5

[blutaermer]

ist das schon laenger bekannt?

http://community.games4mac.de/index.php?automodule=blog&req=attach&id=71

 

[michast]

Länger ist mir das nicht bekannt, aber ich habe bereits darüber gelesen

Gruß,
Michael

 

[MatzeLoCal]

Hier geht's auch um GC. Besonders mal die Kommentare lesen.

Ich bin ja Java-Coder und lebe täglich mit der GC ... und bin kein Fan davon. Zum einen klaut sie Performance und dann kann mensch nie sicher sein, dass ein Object wirklich weg ist. Selbst

object = null;
System.gc()


gibt keine 100%-ige Sicherheit.

Wenn das bei Obj-C zur Option wird, ok... aber bitte nicht Standard.

 

[commander]

Ab einer gewissen Projektgröße ist gc ein Segen! Selbst _mit_ gc können Speicherlecks enstehen, aber doch sehr sehr sehr viel unwahrscheinlicher.

Klar, die Speicherverwaltung der VM ist etwas undurchsichtig, aber die Möglichkeit, mit Soft-/Weak-/Phantomreferenzen zu arbeiten sind doch fantastisch!

Gruß,

.commander

 

[MatzeLoCal]

Klar, die Speicherverwaltung der VM ist etwas undurchsichtig, aber die Möglichkeit, mit Soft-/Weak-/Phantomreferenzen zu arbeiten sind doch fantastisch!

Oder ein Graus.
Es war hier zum Bespiel so, dass der Hersteller unseres ApplicationServers uns ein Modul zur direkten Anbindung an ein SAP programmiert hat.
Wir kämpften über Monate mit Phantomverbindungen, weil Objekte "irgendwie" doch nicht richtig verworfen wurden, trotz nullen. Und wenn halt nur eine bestimmte Anzahl an Verbindungen bestehen darf und die geschlossenen werden nicht verworfen, dann ist das nicht so toll

 

[blutaermer]

ich hatte es nur geschrieben , weil ich im internet drauf gestossen bin und ich in erinnerung hatte, dass das manchen fehlt und somit klar ist, das leopard nicht nur bootcamp final mitbringt, sondern auch noch ein zweites feature

ansonsten habe ich von garbage collections nur eine ungefaehre ahnung - ich habe noch nie mit einer gearbeitet und wuesste nicht mal wie ich anfangen soll.

ich weiss auch nicht wo der vorteil bzw. der nachteil gegenueber den bereits vorhandenen mechanismen von Obj-C ist.

 

[MatzeLoCal]

ich weiss auch nicht wo der vorteil bzw. der nachteil gegenueber den bereits vorhandenen mechanismen von Obj-C ist.

Ganz kurz und grob.. (und auf klugscheisserisch )

Also in Objective-C (bzw. C und C++), ist der Programmierer für die Verwaltung des Speichers verantwortlich. Wird ein Object nicht mehr benötigt, gibt er den Speicher wieder frei.

Beispiel:

NSObject einObject = [NSObject alloc]; //Speicher für das Objekt wir reserviert
[einObject init]; //Objekt wird initialisiert

/*
kann auch mit
NSObject einObject = [[NSObject alloc] init];
abgekürzt werden.
*/

[einObject tuWasIchDirSage]; //die Methode "tuWasIchDirSage" des Objects wird ausgeführt
[einObject release]; //hier brauchen wir das Object nicht mehr und geben den Speicher wieder frei.

In Java dageben überwacht die GarbageCollection die ganze Zeit, ob ein Objekt bzw. der Speicher den dieses belegt, noch benötigt wird oder nicht. Der Programmierer kann zu keinem Zeitpunkt darauf Einfluss nehmen. Selbst das explizite Anstossen der GarbageCollection (die läuft nur in (un)bestimmten Abständen) kann nicht die Freigabe von Speicher garantieren

Object einObject = new Object(); //Speicher wird reserviert und Object initialisiert
einObject.tuWasIchDirSage(); //die Methode "tuWasIchDirSage" des Objects wird ausgeführt

/*
In Java wars das jetzt schon. Kriegt die GC mit, dass das Objekt nicht mehr benötigt wird, fliegt es normalerweise aus dem Speicher. 
Der Programmierer kann der ganzen Sache noch etwas "Nachdruck" verleihen, aber obs Erfolg hat ist halt nicht sicher gestellt. Also folgendes kann noch getan werden.
*/

einObject = null; // immer gut...
System.gc(); // sollte nicht unbedingt getan werden, weil es drückt die Performance gewaltig.

"Problematisch" wird es in Sprachen ohne GC halt, wenn Objecte ihren Speicher nicht freigeben, dann spricht man von Speicherlecks. Im schlimmsten Fall ist es dann so, dass ein Programm während seiner Laufzeit immer mehr Speicher einnimmt bis es dann soweit kommt, dass aller Speicher aufgebraucht ist.

 

[blutaermer]

ok. das man objekte neu anlegen muss und wieder freigeben sollte ist klar (hat man dafuer nicht die konstruktoren und destruktoren bei c++)
die gc macht das ganze also mehr oder weniger automatisch.
aber was ist denn nun mit dem autoreleasepool unter objC? ist das dann sone semiautomatische sache, die einen so ein bisschen unter die arme greift und durchstrukturiert ?

 

[MatzeLoCal]

ok. das man objekte neu anlegen muss und wieder freigeben sollte ist klar (hat man dafuer nicht die konstruktoren und destruktoren bei c++)
die gc macht das ganze also mehr oder weniger automatisch.
aber was ist denn nun mit dem autoreleasepool unter objC? ist das dann sone semiautomatische sache, die einen so ein bisschen unter die arme greift und durchstrukturiert ?

Naja, nicht ganz. Einmal müssen Objecte "autoreleasefähig" sein und dann ist das mehr für Situationen wie unten gedacht.

- (NSString *)gibtMirEinenStringZurueck   //es wird gebeten von zweideutigkeiten abstand zu nehmen *ggg*
{
    int ergebnisEinerBerechnung = 25; //das würde natürlich berechnet werden..
    NSString * rueckgabeString = [[NSString alloc] initWithFormat:@"Der Ergebnis lautet: %d ",ergebnisEinerBerechnung]
    return rueckgabeString; 
}

Mit der Rückgabe entgleitet dem Entwickler quasi die Kontrolle über das String-Object. Und damit hier keine Speicherlecks entstehen, kümmert sich der autoreleasedPool darum.

 

[blutaermer]

also man muss seinen code autoreleasefaehig machen (das meinte ich mit durchstrukturieren) und dann wird sich ein wenig darum gekuemmert
also doch semiautomatisch: wenn man genug hand anlegt, wird der rest automatisch gemacht (hab ichs jetzt verstanden?)

 

[MatzeLoCal]

Nein, die jeweilige Klasse muss autorelease-fähig sein.

 

[MatzeLoCal]

Noch n bisserl Info falls es von Interesse is. Ich habs aber bis etz nur so überflogen...

Aber definitiv besser erklärt als von mir... ich bin noch nicht so fit in Obj-C :-c

 

[tjp]

Ab einer gewissen Projektgröße ist gc ein Segen!

Außer in zyklischen Strukturen bietet GC gegenüber SmartPointer wie man sie etwa in C++ verwendet keinen qualitativen Vorteil. Dafür programmiert man sich bei Java einen Wolf, weil man massenweise Sonderbehandlungen berücksichtigen muß, weil es kein RAII gibt.

 

[tjp]

ok. das man objekte neu anlegen muss und wieder freigeben sollte ist klar (hat man dafuer nicht die konstruktoren und destruktoren bei c++)
die gc macht das ganze also mehr oder weniger automatisch.

Ja, in C++ verwendet man dafür Konstruktoren und Destruktoren. Das hat den riesen Vorteil, daß man nicht nur Speicher so verwalten kann sondern auch andere Resourcen. Wirklich "witzig" wird es, wenn man andere Resourcen verwalten muß.

In C++ muß man nur einmal beim Design der Klasse aufpassen und dafür sorgen, daß die Guardklasse, die die Verwendung der Resource (bitte nicht nur an Arbeitsspeicher denken) sichert, beim Destruieren, die betreffende Resource freigibt. In Java muß man dagegen überall beim Verwenden der betreffenden Klasse aufpassen, daß beim Verlassen eines Codeblocks (z.B. via Exception) auch ja die belegte Resource freigegeben wird. Übersieht man das einmal hat man schon ein Resourcenleck.

Die Wahrscheinlichkeit Resourcenlecks zu programmieren ist somit in Java größer.

 

[commander]

Oder ein Graus.
Es war hier zum Bespiel so, dass der Hersteller unseres ApplicationServers uns ein Modul zur direkten Anbindung an ein SAP programmiert hat.
Wir kämpften über Monate mit Phantomverbindungen, weil Objekte "irgendwie" doch nicht richtig verworfen wurden, trotz nullen. Und wenn halt nur eine bestimmte Anzahl an Verbindungen bestehen darf und die geschlossenen werden nicht verworfen, dann ist das nicht so toll

Das klingt aber eher nach einem OS - Problem - ich habe das auf einem Win 2000 Rechner beobachtet - da wurden teilweise die nativen Sockets nicht mehr (schnell genug) freigegeben... unter Linux konnte ich das noch nie beobachten.

Oft geben die bekannten Profiler Auskunft über solche Schieflagen - oder man überschreibt (termporär) die finalize() Methode des Objekts - dann weiß man exakt, wann der GC zuschlägt.

Klar, es handelt sich bei GC um einen impliziten Vorgang, den man nicht direkt beeinflussen kann, und das bringt Schwierigkeiten mit sich. In einem komplexen EJB - Projekt mit zig Modulen und 50+ Entwicklern ist es mir jedoch immer noch lieber mich auf einen solchen Automatismus zu verlassen als auf den einzelnen Entwickler. Und bisher haben wir keinerlei Probleme damit - das wäre sicherlich anders, wenn jeder Entwickler selbst dafür Verantwortung tragen müsste.

Gruß,

.commander

 

[MatzeLoCal]

Das klingt aber eher nach einem OS - Problem - ich habe das auf einem Win 2000 Rechner beobachtet - da wurden teilweise die nativen Sockets nicht mehr (schnell genug) freigegeben... unter Linux konnte ich das noch nie beobachten.

Dieses Argument darf ich hier leider nicht mehr anbringen.

Aber das war es schon so, dass die Objekte sich einfach nicht "zerstören" liesen. Und wie ich gestern und heute erfahren musste, ist das wohl immer noch so.. allerdings nur beim beenden des ApplicationServers und da ist das ganze wohl auch eher Schlamperei vom Entwickler, denn während die SAP-Connections beendet sind, versucht ein "Profil" immer noch über die zu senden und das endet dann in einer Endlosschleife..

 

[MacApple]

Nein, die jeweilige Klasse muss autorelease-fähig sein.

Jede Klasse, die von NSObject abgeleitet ist, ist das ja automatisch.

MacApple

 

[tjp]

Das klingt aber eher nach einem OS - Problem

Das hört sich eher danach an, daß da jemand nicht sauber Resourcen freigibt, weil er der Meinung ist in Java könne man RAII wie in C++ verwenden. Das geht aber nicht.

 

[commander]

Das hört sich eher danach an, daß da jemand nicht sauber Resourcen freigibt, weil er der Meinung ist in Java könne man RAII wie in C++ verwenden. Das geht aber nicht.

Sorry, aber das ist absoluter Quatsch. Kein Mensch würde heutzutage an der Java Standard-API vorbei eine Ressource wie ein Socket selbst ziehen - es ist klar, dass, wenn man vergisst, sowas wie Streams zu closen etc., die Ressource nicht mehr freigegeben werden kann, aber das hat mit RAII überhaupt nix zu tun. Entweder man verwendet kurzlebige Objekt, die native Ressourcen ziehen - dann kann man den GC vertrauen, oder man handelt das zentral.

Aber: Heutige Programmierung kümmert sich um solche Basics doch nur noch in absoluten Ausnahmefällen - normalerweise ist sowas durch die verwendeten (gerade in Java sehr gut abgehangenen Libraries und Container) vollkommen gekapselt - und ich bin absolut sorgenfrei was das Aufräumen von Objekten (und eventuellen nativen Ressourcen) angeht.

Gruß,

.commander