This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gc notes available


Tel <telford@eng.uts.edu.au> writes:
[snip: costs of memprotect write barrier, etc]

> > The only weirdness here is: what if someone doesn't know they're
> > mutating an object?  What if they've just got a pointer to an SCM, and
> > they're storing something in it?  What if they've just got a void *,
> > and they're copying bytes from another void * into it?  I think the
> > answer here is that whoever gave them that pointer must have had the
> > real SCM, and it's the SCM holder's job to make sure the write barrier
> > gets called appropriately.  Thus:
> > 
> > 	frob (SCM_CDRLOC (pair));
> > 	scm_write_barrier (pair, SCM_NEWEST);
> > 
> > SCM_NEWEST would be a magic value which tells the write barrier, "I
> > don't know what I stored; I may or may not have pointers to younger
> > objects now."
> 
> bleah!

Pretty much my sentiments ;) I think that most of this can be handled
inside of system procedures that aren't visible to the user. It will
require something along the lines of SCM_ASSIGN(loc, obj), instead of
loc=obj in c code, but this isn't an enormous requirement for user
code. My view on the write barrier in reply eventually became:

> The only weirdness here is: what if someone doesn't know they're
> mutating an object?  What if they've just got a pointer to an SCM, and
> they're storing something in it?  

In this case, I think that a function or macro that does
SCM_ASSIGN(loc, val) should be used. I don't think this is bad, and if
they aren't using the write barrier, it can just expand into loc=val
The one break that we do get with is that we don't have to worry too
much about our possible roots being inside an object, it just means a
little special care to remove those roots when the object dies (which
won't be a problem, because they've registered their memory with us).

> What if they've just got a void *,
> and they're copying bytes from another void * into it?  

The simplest possible answer: They shouldn't do that! Is there any
really good reason that we should be allowing (or rather, endorsing)
this sort of thing? I've been trying to think of one since you brought
this up, and I'm stumped.

For bonafide objects, they should have a copying function; for
strictly c arrays and structs, we don't have to care what they are
doing. Where they get values from should be doing work to make sure
that that area is under our protection, but we shouldn't (and can't)
stop people from doing (stupid, IMO) things like memcpy'ing the data
of an smob. I don't really think this is a big constraint, either,
since anyone who goes around, copying from void * to void * without
knowing what they're copying is likely going to get bitten very
quickly.

The changes I can see that will be required to support a sane
interface (this outside of the write barrier itself):

1) SCM_ASSIGN(SCM x, val); this [is described earlier (sorry 'bout
   that Jim, I messed this up in the email)]

2) smobs will have to add a copy(SCM from) function. Not big (I'd
   think most smobs would have something like this), but it means
   there's a sane way of getting at things from the end user's point
   of view.

3) (if a copying/moving collector is enabled) smobs need a
   relocate(SCM current, SCM new) (not strictly necessary, but it
   shouldn't be an entirely big deal to have it, and it could be
   useful)

4) (if using a memprotect based barrier) scm_malloc_protected,
   scm_realloc_protected, scm_free_protected: like the scm_must_xxx
   functions, these providing a chunk that will be stored in a mem
   protected region. Also, a scm_register_mem(SCM cell, void
   *prot_chunk); might prove useful, but not strictly necessary.

5) smobs need a possible_pointers function, that can communicate to us
   where we can find pointers. This is closely related to mark, and
   shouldn't be difficult to provide. (really hairy smobs might make
   life painful here).

6) a lynch mob, for everyone who wants the unlimited freedom to copy
   unknown objects from void * to void * without breaking anything ;)
   

Except for the lynch mob, these seem fairly doable, won't require an
awful lot of modification to existing smobs (the details of write
protection shouldn't be too sticky inside the smobs).


-- 
Greg, slowly catching up on the list, and spending too much time
      playing with garnet (anyone want to port it to guile? >;)