John M McIntosh <johnmci at mac.com> wrote:
> >  If an object is in old space, or if it has a non-0 identity hash, then
> >  that
> >  identity hash is permanent. Otherwise, a permanent hash has not yet
> >  been assigned.
> 
> No I don't think this is workable due to combinations of  
> deferred-hash/hash VM & images.

Actually, this issue is the reason for leaving alone 0-hashes that show
up in old space.  If a 0 hash is in old space, you assume it really
means a hash of 0, not that the hash hasn't been assigned yet.  If you
load an image that has 0 hashes, you assume they come from an old
non-lazy hashing VM, and you leave them alone.

Keep in mind that when you load a snapshot, all the objects go into old
memory.  Also, when you save a snapshot, a garbage collection happens
that forces every surviving object into old space.  Thus, if you use
this approach, the on-disk snapshot always contains real hashes.  Looked
at another way, snapshots are old space.


> What I
> had suggested before is tagging the image using one of the free words  
> in the header, then use
> a prim call at startup to decided if the image sets need to be  
> rehashed, because the image is
> contaminated with identitityhash = 0.

I saw that.  It  can work, but it means that you need special
image-level code and you need to have different image versions. 
Wouldn't it be nice to avoid this?

The only cost of using the new-space-only approach is that there will be
tenured objects whose hash is not used but whose hash is computed
anyway.  This cost should be pretty low, because tenures don't happen
very often under normal usage.

There are a number of advantages:

	1. All VM's work with all images.  Period.

	2. There is no need for additional image-level code to rehash things,
nor for load-up time to be slower due to executing the rehashes.

	3. There is no need for VM-level code to deal with old images that
don't have the code.


Lex