guile-devel
[Top][All Lists]
Advanced

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

Re: gc issues


From: Michael Livshin
Subject: Re: gc issues
Date: 13 Sep 2000 17:37:42 +0300
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

Dirk Herrmann <address@hidden> writes:

> It may make sense to have a function SCM_NEW_CELL as a clean way to
> initialize a cell.  However, whether this is a solution to the problem
> depends on how scm_remember is defined.  If this is a function call, then
> it will add a noticable performance penalty because of the following
> reasons:
> 
> * Well, it's an additional function call for each new cell that is being
>   obtained.
> 
> * The compiler can't keep obj1 in a register any more, which may cause
>   additional memory accesses and makes certain optimizations impossible.
> 
> If it is a macro, then I wonder how it should look like to make sure that
> a smart compiler can't optimize it away.  But, also in that case we will
> force additional memory references and reduce the compiler's optimization
> potential.

yes, I agree (it might not have been exactly clear from the previous
reply, sorry).

> Further, I don't think conservative scanning of free cells is
> unclean.

it doesn't look very problematic.

> > would just checking read accesses be fine?  it seems the simplest
> > solution to me.  can you think of any examples where the coverage it
> > provides is insufficient?
> 
> I think you are right.  It can easily be done, and, if it turns out to be
> unsufficient, we can change it later.

all right then.  I'll wait for any other possible input for a day or
two and will implement this.

-- 
There are few personal problems which can't be solved by the suitable
application of high explosives.



reply via email to

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