Re: Protecting CONS cells from modification

[Greg Harvey <Greg.Harvey@thezone.net>]

Telford Tendys <telford@eng.uts.edu.au> writes:

> Just writing down a thought as it comes to me...
> 
> If a given block of cons cells get scanned during
> a garbage collection cycle, at the end of GC you
> could take a CRC value for that block of CONS cells
> and store it out of the way somewhere.
> 
> First thing next GC, you take a CRC of the same
> block and if it is different there must have been
> a set-cdr! or similar somewhere so you need to rescan,
> if not then you can safely assume that the block
> have not been touched.
> 
> OK, I know that it is vaguely possible that multiple
> bits in the block of cells could change and result in
> identical CRC values but that is very unlikely.
> Thus, you get yet another method of checking for modification
> to CONS cells which is not as intrusive as SCM_ASSIGN
> and faster and more portable than using the MMU chip.
> 
> It won't work if any of those CONS cells are SMOBs or
> vectors either, can't win em all!
> 

umm... ouch! This is probably performance down the crapper for a good
crc function. Even worse, it's correctness down the crapper, and we'll
still have to scan for vectors and smobs. We absolutely, positively
have to make sure that we get all pointers into a generation, and I
don't think this will cut it.

No offense, but I don't think this one's a keeper.

-- 
Greg