[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