<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I must admit that I've had a hard time figuring out the correct approach to take for Ralph's 2a/2b case, but here's the way I now think about it. Comments and corrections always appreciated.</div><div><br></div><div>When an instance of a class defined in Lisp that derives from an Objective-C class is gc'ed, all that means is that there are no more lisp references to it. There may still be references from other Objective-C objects that Lisp does not manage or know about. Therefore, it would be improper for the GC to physically deallocate an Objective-C object; and in fact in the tests I've run, it does not do so.</div><div><br></div><div>So it would also not be proper to call ccl::terminate-when-unreachable on such an instance and release values in slots for that object in a ccl::terminate method that is called during GC <i><u>unless you are absolutely sure that there are no non-Lisp references to the object</u>. </i>And even in that case, the object itself will not be deallocated, unless it is released somewhere, so that should also be done in that terminate method. If you're not absolutely sure that there are only Lisp references to the object, then the dealloc method for the object is the proper place to release Objective-C objects in slots (of any type, not just :foreign-type).</div><div><br></div><div>An alternative choice for memory management for objects that might be referenced from both Lisp and other Objective-C objects is to use the ccl::terminate functionality. If the object is created via a make-instance call within Lisp, then its reference count is effectively 1. Rather than doing a #/retain for each assignment of that object within Lisp, we will simply use that initial reference count to indicate that <i><u>some</u></i> Lisp object references it and decrement that count when the object is GC'ed. Any objective-C objects to which this instance is passed as an argument may choose to retain and release it as well, but we don't need to be concerned about that. This might be implemented by something like the following:</div><div><br></div><div>(defclass my-class (ns:ns-object)</div><div> ((slot-a :foreign-type :id :reader slot-a))</div><div> (:metaclass ns:+ns-object))</div><div><br></div><div>(defmethod initialize-instance :after ((self my-class) &key &allow-other-keys)</div><div> (ccl::terminate-when-unreachable self))</div><div><br></div><div>(defmethod (setf slot-a) ((new-value ns:ns-object) (self my-class))</div><div> (unless (eq (slot-a self) new-value)</div><div> (#/release (slot-a self ))</div><div> (setf (slot-value self 'slot-a) (#/retain new-value)))</div><div> new-value)</div><div><br></div><div>(defmethod ccl::terminate ((self my-class))</div><div> (#/release self))</div><div><br></div><div>(objc:defmethod (#/dealloc :void) ((self my-class))</div><div> (#/release (slot-a self))</div><div> (call-next-method))</div><div><br></div><div>This results in the reference count being balanced for all Lisp accesses. If the object is passed to Objective-C methods, they will presumably take care of doing proper retains and releases. The object's dealloc method is then only called when there are no more references from anywhere and it, in turn, is responsible for #/releasing Objective-C objects retained in its slots.</div><div><br></div><div>There is a hole in this process if the object is created by some Objective-C process (say by loading a NIB file that uses an instance of that class for something). In that case there is some Objective-C object that owns the object and it will, at some time in the future, release the object. If the GC determined that there were no Lisp references to the object, the ccl::terminate method would be called and it would prematurely release the object ... bad news for the Objective-C owner that might then use the reference. </div><div><br></div><div>So you can use the code above only for objects that are created in Lisp processes (i.e. you as the developer do a (make-instance ...) for it somewhere) and referenced from both Lisp and Objective-C objects. In effect, "Lisp" is the owner of the object.</div><div><br></div><div>For objects that are created by Objective-C methods and referenced only from Objective-C objects, don't use the ccl::terminate-when-unreachable and ccl::terminate methods; just rely on standard reference counting to take care of it. As before, objects retained in its slots should be released in the #/dealloc method.</div><div><br></div><div>For objects that are created by Objective-C methods (and therefore have an owner that will eventually release it) and referenced by both Objective-C and Lisp objects (any Lisp object can hold a reference to an Objective-C object; it doesn't have to be a :foreign-type slot) you have three choices:</div><div><br></div><div>Choice 1: </div><div>You can choose to <u><i>not</i></u> use the ccl::terminate method and make sure that all Lisp references make proper #/retain and #/release calls just as they would for any other Objective-C object. For only a few Lisp references to the object this is probably preferred. </div><div><br></div><div>Choice 2:</div><div>If there may be lots of Lisp references in lots of places that make doing #/retain and #release correctly problematic (e.g. in lists that are copied or sorted or whatever), then you have to think about whether any of the Lisp references might outlast the reference of the Objective-C owner object that created the referenced object in the first place. If not, then you can just treat all the Lisp references as weak references and forget about them. </div><div><br></div><div>Choice 3: </div><div>But if you might want to use the reference from a Lisp object sometime after the creating owner has released it, then you'll want to make sure that it is retained for use by Lisp. To do that you might consider using the ccl::terminate-when-unreachable and ccl::terminate methods as described above, but with a twist. Do a single #/retain of the object at the time of the very first Lisp reference to the object. In effect, that says that Lisp is now an owner of the object. Then the corresponding #'release will be done when GC determines that there are no more Lisp references. One way to do this would be by adding something like (#/retain self) to the initialize-instance :after method, but you'll also want to make sure that you make an actual lisp reference to the object at that same point so that GC won't immediately invoke the ccl::terminate method which would prematurely #/release it. And of course that reference would have to be eliminated before GC would call the ccl::terminate method on it.</div><div><br></div><div>There may be other holes here that I'm not seeing ... Yes, memory management like this is a pain.</div><div><br></div><div>For completeness, we can also talk about a few cases where releases of Objective-C references are not necessary (if I am wrong about any of these, please correct):<div><br></div><div>1. Weak Objective-C references: objective-C slot that contains values known to be retained by some well-defined owner</div><div>Example: A NIB file defined in IB specifies references of various sorts between objects, some of which are Lisp instances (created when the nib is loaded) with objective-C slots that hold the reference. Since the nib owner is responsible for retaining and releasing all such objects it isn't necessary to do so for each slot. Of course if some other objective-C slot in one of these objects will later reference a dynamically created Objective-c object then previously discussed rules will apply.</div><div><br></div><div>2. Objective-C objects created using class convenience constructors. (I make significant use of these in my contrib stuff.) As per <a href="http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.pdf">http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.pdf</a></div>"Many classes provide methods of the form +className... that you can use to obtain a new instance of<br>the class. Often referred to as “convenience constructors”, these methods create a new instance of the class,<br>initialize it, and return it for you to use. You do not own objects returned from convenience constructors, or<br>from other accessor methods."<div><br></div></div><div>Paul</div><div><div><br>On Sep 24, 2010, at 9:08 AM, Raffael Cavallaro wrote:<br><br><blockquote type="cite">I think it would be useful to know the best way to deal with the life cycle of cocoa objects. Possibly the various situations can be enumerated and memory management best practices outlined for each. <br><br>Most importantly, please correct anything here that is wrong (i.e., likely to lead to a memory leak or outright crash), and please add any common situations that I've overlooked.<br><br>1. containing lisp class (i.e., not having ns:ns-object as its metaclass) with an objective-c slot.<br><span class="Apple-tab-span" style="white-space:pre"> </span>- call ccl::terminate-when-unreachable on the containing lisp instance in its intitialize-instance method<br><span class="Apple-tab-span" style="white-space:pre"> </span>- do necessary deallocation (#/release, etc.) of objective-c slots in a ccl:terminate method on the containing lisp class<br><br>2. containing Objetive-c class (with ns:ns-object as its metaclass) with a:<br>2a. lisp slot<br><span class="Apple-tab-span" style="white-space:pre"> </span>- assume this lisp slot is taken care of by the gc?<br>2b. objective-c slot<br><span class="Apple-tab-span" style="white-space:pre"> </span>option 1:<br><span class="Apple-tab-span" style="white-space:pre"> </span>- call ccl::terminate-when-unreachable on the containing objective-c instance in its intitialize-instance method<br><span class="Apple-tab-span" style="white-space:pre"> </span>- do necessary deallocation (#/release, etc.) of objective-c slots in a ccl:terminate method on the containing objective-c class<br><span class="Apple-tab-span" style="white-space:pre"> </span>option 2:<br><span class="Apple-tab-span" style="white-space:pre"> </span>- do necessary deallocation of objective-c slots in the containing objective-c class's #/dealloc method.<br><span class="Apple-tab-span" style="white-space:pre"> </span>option 3 ?:<br><span class="Apple-tab-span" style="white-space:pre"> </span>- for objective-c objects owned/managed by a custom window class, do necessary deallocation in the custom window's #/close method<br><br>3. Shared objective-c resources<br><span class="Apple-tab-span" style="white-space:pre"> </span>- put the shared resource into a special var and let it live for the duration of the program (it's memory will be reclaimed when the app quits)<br><br>comments and corrections most welcome.<br><br>warmest regards,<br><br>Ralph<br><br><br><br>Raffael Cavallaro<br><a href="mailto:raffaelcavallaro@me.com">raffaelcavallaro@me.com</a><br><br><br><br><br><br>_______________________________________________<br>Openmcl-devel mailing list<br>Openmcl-devel@clozure.com<br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote><br></div></div></body></html>