Re: [Lush-users] loosing memory in compiled code
Ralf Juengling <[email protected]> Tue, 21 Feb 2006 11:28:56 -0800 (PST)
| Newsgroups | gmane.lisp.lush.devel |
|---|---|
| Message-ID | <[email protected]> |
[... Still trying to cook up a simple piece of code that exhibits
the problem. Meanwhile...]
On Thu, 16 Feb 2006, Yann LeCun wrote:
> This looks indeed like an over-locking bug. Everything that's
> allocated in compiled code (and not returned) is allocated on the
> stack, so that can't cause memory leaks.
I don't believe that. ;-) Let's look at some code:
(defclass A Object
((-idx2- (-double-)) m) )
(defmethod A A (n)
((-int-) n)
(setq m (double-matrix n n) ))
(defmethod A do ()
(let ((mc (idx-copy m)))
(idx-transpose mc '(0 1))
(idx-copy mc m)
() ))
(defun iterate (m n)
;; iterate m times with an nxn matrix
(let ((a (new A n)))
(for (i 1 m)
(==> a do))))
(dhc-make ()
(A A do)
)
In method (A . do) a temporary copy mc of m gets created. This copy
is not returned. The size of mc (of the data block the storage points
to) is not known until runtime, so it need to be allocated dynamically.
> Things that might be returned
> (directly or through side effects) are allocated for good and handled
> by src/lisp_c.c.
The code in src/lisp_c.c distinguishes between dynamically
allocated objects that "belong to C" vs. objects that "belong to Lisp".
Why this disinction--after all lisp_c is part of the interpreter?
Looking at the example aboive, is there a difference in "ownership" of
the instance variable m depending on whether the class constructor
is compiled or not? How exactly is the memory for m handled in each
case?
> Exactly what happens inside src/lisp_c.c is a great
> mystery to everyone except Great Guru Leon Bottou.
I guess Leon could write a book about it. Perhaps we could create
some kind of documentation of this beast by using a Wiki? I (and Yann?)
could start with some exegesis of lisp_c and Leon adds his twelve
cents and gives the final blessing...
Ralf
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642