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