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 18:59:37 +0200 (MEST)

On 13 Sep 2000, Michael Livshin wrote:

> I'm not sure I get your point here.
> 
> hmm...
> 
> right now, free cells look like this: (frecell tag, link to next freecell).
> 
> i.e. the sweep phase already cleans them alright, unless they are
> double cells (so it should clean them too, no big deal).

You: right, me: stupid :-)

> if you just naively trace them, you trace a whole cluster of them
> (or whatever left of it), unless you just don't continue tracing if
> the thing pointed to from a freecell is also a freecell.  feasible, I
> guess.

Yes, that's easy.  Except someone creates chains of fresh cells :-)

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

I have thought some more about your suggestion and also have realized
that there already exists a function scm_remember.  Unfortunately, the
implementation of scm_remember as a function that takes the address of
some SCM object is not very effective, as we have discussed.

I suggest to use an alternative macro:

extern volatile SCM scm_dummy;  /* never read, only written */
#define scm_remember_object(obj) (scm_dummy = (obj))

In contrast to scm_remember, the proposed scm_remember_object does not
force the object to be stored in memory:  The object may still be kept in
a register.  scm_remember_object only guarantees that the object is kept
up to the point where scm_remember_object is called.  Immediately after
scm_remember_object the object may get lost.  (Maybe there is some asm
trick that can be used to make the compiler believe that the value is
still in use, but without adding additional operations.  This would even
be better.  But the above macro should always work.)

Then, your example can be rewritten as:

  #define SCM_NEW_CELL(cell, type, obj1) \
     do {\
       SCM_NEWCELL (cell);\
       SCM_SET_CELL_OBJECT_1 (cell, obj1);\
       SCM_SET_CELL_TYPE (cell, type);\
       scm_remember_object (obj1);\
     while (0)

This solution has a couple of advantages:
* The penalty is probably small, since no procedure call is performed,
  and since the object may still be kept in registers.
* The thread safety of the code is obvious _within_ the code, and does not
  rely on any external tricks.  Thus, as your suggestion, it _is_ cleaner.
* No need to conservatively scan free cells.
* No need to clear cell contents of double cells during sweep.

If my assumption about performance benefits of scm_remember_object
vs. scm_remember is right, then it might make sense to replace current
uses of scm_remember where this is appropriate.

Best regards
Dirk



reply via email to

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