Re: gc notes available

[Tel <telford@eng.uts.edu.au>]

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

As I asked before, if it's not too much to ask for the C user
to register each and ever write, then why do we bother with conservative
GC stack scanning when we can ask the user to register SCM variables
on the stack? If fact, if we go for SCM_ASSIGN(loc, val) then
we can throw out stack scanning then and there because the C user
is implicitly announcing the existence of a stack variable as soon
as he/she assigns anything to it.

As the world moves to C++ and operator overloading gets taken forgranted,
this sort of thing will seem a silly argument but I thought that there
was this intention to take pressure off the C user -- we can't seem
to trust them to even declare the top of the stack but we can trust
them to declare all write operations. Is my sanity leaking like an
old engine sump or is there a priority inversion occuring?

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

Oh yeah, so memmove() and memcpy() are right out. Yes, that's right
good boy users just shouldn't touch those nasty memory management routines.
What if I have a large block of SCM objects and want to insert a
new one into the middle? Do I write a loop of SCM_ASSIGN() or just
do a memmove() ?

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

Yes, I agree that this sounds useful, however then you get into
issues of deep vs shallow copy and what exactly you mean by copying
an SMOB anyhow. Guidelines are required.

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

Yes, ideally it would be nice to move things around to repack memory.
That would give scheme one solid advantage over just about every compiled
languages and would give massive improvement to the generational GC
performance. It would also be an incredible number of pointers to track.

I'm running B-trees containing approx 10000 SCM data values which are
a mix of symbols, integers and floats (and the odd string and SMOB).
I'm hoping to push this further by a factor of at least 10 before I could
consider the system getting into the workable region.

As I said above, if we really do go with SCM_ASSIGN() then we have
alrady declared every live stack value so we can even move objects that are
pointed to from the stack (dangerous but fun!)

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

Hmmm, if the user is grabbing protected slabs of memory then
what happens when one of them faults? Can the user also add hooks
to the fault handling code? This seems like a can of worms.

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

Better to just define a marking function that passes the pointer
to the SCM rather than the SCM itself. OK, in many cases it is a double
indirection but this way forcing a mark also forces declaration of all
the pointers. Besides SCM_ASSIGN has already declared pointers!

The real trick is that when you want to repack memory, you force the
SMOB to do a mark operation and you tweak each SCM while it is marking.
Naturally, any const declarations are out the window but guile pretty
much is that way at the moment. Using this means that the SMOBs are doing
the pointer tracking for you, all you have to actively track is the
stack pointers.

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

Any day dude! If you think I'm giving up my memmove, you better offer
me some REALLY good reasons. Basically, the only reason that I would
accept is an equivalent performance improvement in GC and dynamic memory
repacking.

	- Tel