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] |
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? >;)