gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: FriCAS and gcl-2.7.0


From: Camm Maguire
Subject: [Gcl-devel] Re: FriCAS and gcl-2.7.0
Date: 17 Jan 2008 08:37:01 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

I think you have found a bug in GCL's gc, whcih I'll try to plug when
I get back in a week.  Does this persist with current CVS?  Also, I'm
not sure if you really mean closure data as opposed to compiled-file
function data (i.e. closure or not).  Structures cc vs. cfd.  The
latter are gc'ed when no compiled function using them is
referenceable, which is what I think is going on here.  closure
environment data similarly is referenced by an internal pointer in the
C structure, so if the function cannot be reached, the same result
will follow.  cfd data (for example constants) are shared by several
functions in the same file to conserve space.  What it sounds like
might be needed in both cases is a global gc entry pointer pointing to
the current running function.  This will add a little overhead per
call, which I hope is small.

Take care,

Waldek Hebisch <address@hidden> writes:

> I have now a workaround for garbage-collection problem -- I am
> putting all autoload stubs onto a list referenced from a global
> variable, so that garbage collector can see them.  The
> relevant fragment in 'src/interp/patches.lisp' is:
> 
> ;;; Hack to prevent gcl from garbage collecting autoload stubs
> (defvar |$autoLoadInProgressList| nil)
> 
> (defun |mkAutoLoad| (fn cname)
>    (function (lambda (&rest args)
>                  (let ((|$autoLoadInProgressList|
>                           (cons (symbol-function cname)
>                                 |$autoLoadInProgressList|))
>                       )
>                       (declare (special |$autoLoadInProgressList|))
>                       (|autoLoad| fn cname)
>                       (apply cname args)))))
> 
> 
> After that change most errors is gone (in particular all involving
> 'FREE OBJECT').  But there is stil a number of test failures.
> I am not sure if they are related to garbage collection of
> closures.  But I can not exclude this: FriCAS runtime in many
> places redefines running functions.  Typically such functions
> have names, but there is also some use of closures.
> 
> I wonder why gcl uses such strange hack for closure data: natural
> implementation would collect all such data in a vector (possibly
> in a special vector type to conserve space) and pass this vector
> as an extra argument to the closure.  Then the normal garbage
> collection would work fine.
>  
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

-- 
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]