[Vm-dev] Re: [Pharo-project] identityHash bits not incremented for new objects?

David T. Lewis lewis at mail.msen.com
Wed Aug 3 15:21:17 UTC 2011


On Wed, Aug 03, 2011 at 04:54:09PM +0200, Henrik Johansen wrote:
> 
> On Aug 2, 2011, at 5:09 51PM, David T. Lewis wrote:
> 
> > On Tue, Aug 02, 2011 at 03:31:30PM +0200, Henrik Johansen wrote:
> >> 
> >> Please include a comment with that. :)
> >> Like this has shown, it's rather hard to know wtf to do when you can't unambiguously read what its actually intended to test from the code itself. 
> > 
> > Henry, FYI Igor has found a small but important bug in the VM. There is
> > some additional follow up discussion on the vm-dev list that you can read
> > starting here:
> > 
> >  <http://lists.squeakfoundation.org/pipermail/vm-dev/2011-August/009006.html>
> > 
> > Dave
> 
> I saw, and it does eliminate the common case where two small objects get the same identityHash.
> Though, it doesn't really _ensure_ that  two subsequently allocated objects will have different identityHashes, does it?
> IE. if an object is allocated with size which increases (freeStart >> someInt) by 4096, won't you still see the next object getting the same identityHash?
> 
> Not to mention power-of-two sized objects will have a _really_ low number of different hashes. (though none subsequently equal)
> Hence my question if this is really an important property to require of the VM.
> Considering the amount of times I've seen complaints of Set performance due to bad hashing under Cog (in other words, 0), I don't think so.
> 
> Like Nicolas, I am rather skeptic to the comment  saying the values are "well-distributed and fairly random" (which is both true and false, depending on how you interpret "distributed" and "random") though, and would like it if it additionally pointed out edge-cases like above.
> 

I can't comment on that, I just wanted to give credit to Igor for
a good bug catch :)

> Cheers,
> Henry
> 
> PS. 
> What's the state of NewObjectMemory usage in VMMaker?
> When I loaded it, I couldn't find definition/initialization of HashMaskUnshifted, in
> VMMaker.oscog those were in VMSqueakV3ObjectRepresentationConstants/ObjectMemory respectively.

For NewObjectMemory, StackInterpreter, etc you should use only the oscog
VMMaker branch blessed by Eliot (or the related development updates
from Igor or others). I have made a preliminary effort to bring some
of this into VMMaker trunk, primarily updating it to work with the
64bit/32bit object memory support in VMMaker trunk (e.g. using
'self bytesPerWord' rather than BytesPerWord). But this is not suitable
for general use and you definitely cannot yet produce a working
interpreter with it, so please use Eliot's oscog branch if you are
building a StackInterpreter or Cog.

As always, VMMaker trunk uses the Interpreter and ObjectMemory classes
to produce a standard interpreter VM compatible with the Subversion
trunk platform sources, and with generated code suitable for 32bit
and 64bit images.

Dave



More information about the Vm-dev mailing list