gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: memory leak in GCL?


From: Camm Maguire
Subject: [Gcl-devel] Re: memory leak in GCL?
Date: 13 Jul 2004 12:41:35 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  I'm cc'ing this to the gcl-devel list, as Robery Boyer has
found a bug in 2.6.2 serious enough to warrant a 2.6.3.  I'm torn
between happiness and a heavy sigh :-).

Thankfully, it has already been (apparently) fixed in the just created
2.6.3pre branch.

Robert Boyer <address@hidden> writes:

> > Please apply the following:
> > +++ eval.c  2004-07-13 04:03:21.000000000 +0000
> > @@ -1356,7 +1356,7 @@
> 
> Thanks for your amazingly quick response!
> 
> I'm quite embarrassed to say that I don't know how to "apply the following".
> Never have tried patching with diff and so forth.  Furthermore, I don't know
> how you built our current /p/bin/gcl.  If and when you have time, please
> build a new /p/bin/gcl with your patch and I'll be most happy to try out
> anything you'd like.
> 

No problem.  Please try /p/bin/gcl-2.6.3pre.  I just did, and both
nqthm's pass tests without multiply-stacks, at least in the default
build.  I suspect also with ansi, but haven't checked.  Before
releasing an official 2.6.3, it would be most helpful if you could
continue your memory usage comparison to make sure we haven't missed
something else.

> > Please note in passing though that with the *optimize-maximum-pages*
> > setting on, more cells will actually be in use, though its hard to
> > believe this many more!
> 
> I'm afraid I don't understand that remark.  Regardless of whether
> *optimize-maximum-pages* is t or nil, I would have thought that immediately
> after an (si::gbc t), all unnecessary conses would have been collected, so I

You are of course correct here -- I did not see your earlier mention
that you did a (gbc t) right before the (room).  Your statements above
and below do hold when this is done.  When this is not done, and whem
*optimize-maximum-pages* is set to t, fewer gc calls are made as the
heap grows, so that at any random point, more cells will appear to be
in use.

> don't see why 2.6.2, even with *optimize-maximum-pages* equal to t, should
> show that so many conses are in use.  Am I misreading the line
> 
>   48951/48951  94.7%    1877 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> 
> when I think it says that more than 40,000 pages of conses are actually tied
> up?  Doesn't the 94.7% mean that of all the possible CONSes one could
> conceivably cram into 48951 pages, 94.7% are actually now in use?  Or does it

Yes.

> mean something utterly different, for example that 94.7% of the 48951 pages
> allocated to CONS actually have at least one cons on them, the rest being
> utterly empty.
> 

No, the first was correct.

> Anyway, if you get time to build a new /p/bin/gcl, I'll be most happy to run
> the Nqthm-1992 tests again, with *optimize-maximum-pages* equal to both T and
> NIL.
> 

OK!  Apparently, these nqthm tests exercise a function calling path
rarely used in maxima, acl2 and axiom -- at least relatively so.  This
is the reason I should have packaged the nqthm's for Debian and used
them as part of the gcl regression test suite for new releases.  I can
explain the gory details if interested, but typically, in well
optimized function calls, no lisp value stack is consumed at all --
arguments are placed on the C stack, so we rarely see this problem.
In a generic funcall to a variable function, the compiler cannot
reduce the call to a symbol-named function at compile time for this
optimization, and so must handle different types of functions
(e.g. compiled closures) at runtime, placing arguments on the lisp
value stack for this purpose.  Almost all the code we compile in this
latter category goes through 'super_funcall' which does not show this
value stack leak.  This case however triggers the first cond below,
apparently because the reults of the funcall are being discarded
(function called for side-effects?):

      (let ((*vs* *vs*) (form (caddr funob)))
           (declare (object form))
           (cond ((and (listp args)
                       *use-sfuncall*
                       ;;Determine if only one value at most is required:
                       (or
                        (eq *value-to-go* 'trash)
                        (and (consp *value-to-go*)
                             (eq (car *value-to-go*) 'var))
                        (and info (equal (info-type info) '(values t)))
                        ))
                  (c2funcall-sfun form args info)
                  (return-from c2funcall nil)))
           (unless loc
             (unless (listp args) (baboon))
             (cond ((eq (car form) 'LOCATION) (setq loc (caddr form)))
                   ((and (eq (car form) 'VAR)
                         (not (args-info-changed-vars (caaddr form) args)))
                    (setq loc (cons 'VAR (caddr form))))
                   (t
                    (setq loc (list 'vs (vs-push)))
                    (let ((*value-to-go* loc)) (c2expr* (caddr funob))))))
           (push-args args)
           (if *compiler-push-events*
               (wt-nl "super_funcall(" loc ");")
             (if *super-funcall*
                 (funcall *super-funcall* loc)
               (wt-nl "super_funcall_no_event(" loc ");")))
           (unwind-exit 'fun-val))


I introduced the failure you see here in 20030209, (revisions 1.10
-> 1.11 of eval.c for those following along) when we had to convert
all of GCL from the older varargs variable argument C calling
structure to the newer stdarg based calling sequence, as gcc abandoned
support for the former.

In general, we can do much in the hopefully near future to further
optimize closure calls, as is currently done in pcl by setting the
variable *super-funcall* above.

For those who'd like to see the test code:

(defun looper (n pred)
  (declare ((function (fixnum fixnum) t) pred))
  (declare (fixnum n))
  (loop for i from 1 to n do (funcall pred 2 3)))

(defun caller (n)
  (looper n (function (lambda (x s) (or x s)))))

Compile and then 

(caller 1000000)

Michael, if you are reading along, it is items like these which give
me a conservative attitude toward the GCL core. :-)

Take care,

> Thanks,
> 
> Bob
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]