[Openmcl-devel] Memory managemet Objective C and Clozure
Willem Rein Oudshoorn
woudshoo at xs4all.nl
Tue Sep 14 10:48:54 PDT 2010
I have a few questions about how the memory management of CCL and
Objective C work together. Hopefully it is already somewhere fully
documented, in that case, please point me to the right location
(A quick google search and reading the manual did not yield much.)
Let me rephrase the questions into a hypothesis and consequences.
If someonw can help me confirm or refute this I would appreciate it.
Hypothesis A:
1. The objective C runtime does not know anything about
the lisp garbage collector
2. The lisp GC and Objective-C bridge do NOT care about
the objective C runtime memory managment.
Consequence/Questions:
1. An object created in lisp by:
? (#/init (#/alloc)))
Is a memory leak, as soon as the GC collector collects the
lisp 'wrapper' of the object, all references on the lisp side
are gone, but #/release is not called on the objective C
instance.
[Nitpicking, it is possible that the Objective C runtime
holds one copy of an NS-Object and reuses it. In that case
of course it does not leak. But for argument sake assume the
objective C runtime creates a fresh copy of the object
everytime.]
2. The same hold true for
? (make-instance 'ns:ns-object)
This will leak
3. The same holds true for:
? (defclass test (ns:ns-object)
()
(:metaclass ns:+ns-object))
? (make-instance 'test)
This will leak
4. The following, with *v* an Objective C class instance
e.g. ns-text-field is a bad idea:
? (defclass test (ns:ns-object)
((text :accessor text :initform "Hallo"))
(:metaclass ns:+ns-object))
? (objc:defmethod (#/controlTextDidChange: :void)
((self test) (notification :id))
; do something with (text self)
)
? (#/setDelegate: *v* (make-instance 'test))
Because the instance of 'test will be garbage collected
without the knowledge of objectice C runtime. The AppKit
framework will happily call methods on the delegate
which in the lisp world does not exist anymore.
(of course this also leaks according to point 2.)
Kind regards,
Wim Oudshoorn.
More information about the Openmcl-devel
mailing list