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


Jim Blandy <jimb@red-bean.com> writes:

> Here's an excerpt from a message I just sent Greg Harvey.  I have some
> tentative problems with using memory protection:

I haven't followed the gc discussion and I haven't read the gc notes,
but I like to test my common sense...

> -----
> 
> I actually think that memory protection will be much slower than doing it
> all in software.  Here are the steps involved in handling a page
> fault:
> 
>     1) The kernel gets the page fault, puts together a signal context,
>        and invokes the handler.
>     2) The handler does the bookkeeping which is the real point of the
>        exercise.
>     3) Now the handler has to actually do the write.  In order for
>        that write to succeed without causing yet another page fault,
>        you have to somehow:
> 	a) unprotect the page
> 	b) do the write
> 	c) re-protect the page, to catch the next write
> 
> So you're talking signal handling overhead, and at least two system
> calls.

[ compared to just a function call when making write barriers explicit. ]

But the assumption is that the page faults will be quite rare, no?
MOst mutations occur in the youngest generation, and the older
generations are static so that they don't need to be treated at every
gc turn.

We would incur the function call overhead at every *potential*
mutation of a older generation, not only at the *actual* mutations.

I don't know how much control the ususal OS allows, but wouldn't it be
possible to mmap a heap at two addresses, once with write protection
and once without.  The page fault handler could then use the csecond,
unprotected region to perform the write.  Hopefully, this wouldn't
even knock out the caches.

> Notice also that the handler can't really find the SCM object
> being modified; it only gets the address being written to, and
> probably the value being written to it.

I think the value is good enough.  Not the modified object needs to be
in the root set, but the object that has a new reference to it.