guile-devel
[Top][All Lists]
Advanced

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

Re: gc issues


From: Dirk Herrmann
Subject: Re: gc issues
Date: Wed, 13 Sep 2000 11:46:16 +0200 (MEST)

On 13 Sep 2000, Michael Livshin wrote:

> how about the following addition to the API (untested):
> 
> #define SCM_NEW_CELL(cell, type, obj1) \
>    do {\
>      scm_remember (&(obj1));\
>      SCM_NEWCELL (cell);\
>      SCM_SET_CELL_OBJECT_1 (cell, obj1);\
>      SCM_SET_CELL_TYPE (cell, type);\
>    while (0)
> 
> and something similar for doublecells, of couse.
> 
> then the above code would look like:
> 
> SCM make_foo_from_bar (SCM bar)
> {
>   SCM foo;
> 
>   SCM_NEW_CELL (foo, scm_tc_foo, bar);
> }
> 
> looks cleaner too, don't you think?

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.

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


But, there is a completely different problem with regards of conservative
scanning of free cells:  Free cells that are conservatively scanned are
very likely to actually hold references into the heap:  A free cell has,
at some time, been a non-free cell that got collected.  Thus, if not
cleaned, the cell elements will hold the old contents, which are likely to
be SCM values.  Conservative scanning of free cells will thus more
probably inhibit garbage from getting collected.

A solution could be to fill the free cells during sweep with SCM_BOOL_F or
some other immediate value.  This, however, will also lead to a time
penalty:  During sweep, there is one additional write operation for each
single cell, and three additional write operations for each double cell.

If we were thinking of going the way of conservative marking, we should
probably rather go a different way:  Re-introduce the scm_tc_allocated
type, and only have _those_ cells conservatively scanned.  This will, as
we had it for some time now, also lead to a time penalty, but the penalty
is one write access for each cell, independent of whether its a single or
double cell, and, since a fresh cell's type tag will soon be overwritten
anyway, the corresponding memory region will already be in the cache.

BTW:  When re-introducing scm_tc_allocated, we could do it in a better
way, namely not have it always written to a fresh cell, but let the code
which uses the fresh cell decide about using it.  Then, if some code
obtains a cell which will not hold any SCM objects, it does not need to
initialize the cell type with scm_tc_allocated.

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

Best regards
Dirk



reply via email to

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