[Vm-dev] Spur Object 64 bit format

[Eliot Miranda]

Hi Clément,


On Tue, Nov 12, 2013 at 3:56 AM, Clément Bera <bera.clement at gmail.com>wrote:

>
> Hey,
>
> By the way as you are talking about Immediate objects tags and Spur's
> object representation, I read on other VMs reports that it is faster in
> overall performance to have pointers tagged with the xxx1 and SmallIntegers
> tagged with xxx0, because SmallIntegers arithmetics is then much faster.
>

I'm sure that was true 20 years ago when register operations were about the
same speed as memory operations.  But now that memory operations are at
least an order of magnitude slower I suspect that adjusting the tags (all
register operations) are in the noise.  But I agree it *would* be
interesting to measure.

Is it possible to modify that easily in Cog to try ? Do you have to edit
> only a few methods such as #longAt:, #integerValueOf: and SmallInteger
> primitives ?
>

You'd have to modify the isImmediate:/isNonImmediate:, isIntegerObject:,
isNonIntegerObject:, and
storePointer:ofObject:withValue:/fetchPointer:ofObject: methods, and then
the code generated by the CogObjectRepresentation subclass, and modify the
bootstrap to produce an image with the new tagging.  The VM is factored so
that this isn't horribly difficult.  But it's work.  Perhaps it would be a
good student project?


> Another thing, I read in a java VM report that only 1% of objects needs a
> hash (other objects hash are unused), so their hash implementation took
> only 2 bits in the header, being:
> 01 -> no hash
> 10 -> hash is the object's address
> 11 -> hash is in a header extension
> Therefore, on first access to the hash, hash bits switches from 01 to 10,
> and the GC on objects with 10 switches the hash bits from 10 to 11 and add
> a header extension with the old address of the object. But I know I'm not
> teaching you anything there.
>

That's clever. Yes you are :-).  Thanks.


> What I would like to know is why did you choose in Spur to have a 22bits
> hash in the header over this implementation, and will the hash in Spur be
> calculated at each instantiation or lazily ?
>

 I chose the 22 bit hash scheme because it is part of the idea of having
class indices.  Notice that an object's class index is 22 bits also.  The
point here is that a class's hash is its class index.  So to instantiate a
class one copies the class's hash into the instance's class index, avoiding
searching the class table to find the class's index.  Perhaps this isn't
the most optimal approach but it is coherent, and worked well for 64-bit
VisualWorks.

The hash calculation is lazy.  The hash field is 0 when instantiated.  Hence

Behavior>>identityHash
"Answer a SmallInteger whose value is related to the receiver's identity.
This method must not be overridden.
Primitive. Fails if the receiver is not a Behavior. Essential.
See Object documentation whatIsAPrimitive.

Do not override."

<primitive: 175>
self primitiveFailed

InterpreterPrimitives>>primitiveBehaviorHash
| hashOrError |
self assert: ((objectMemory isNonImmediate: self stackTop)
 and: [self addressCouldBeClassObj: self stackTop]).
hashOrError := objectMemory ensureBehaviorHash: self stackTop.
hashOrError >= 0
ifTrue: [self pop: argumentCount + 1 thenPushInteger: hashOrError]
ifFalse: [self primitiveFailFor: hashOrError negated]

SpurMemoryManager>>ensureBehaviorHash: aBehavior
| newHash err |
<inline: true>
self assert: (coInterpreter addressCouldBeClassObj: aBehavior).
(newHash := self rawHashBitsOf: aBehavior) = 0 ifTrue:
[(err := self enterIntoClassTable: aBehavior) ~= 0 ifTrue:
[^err negated].
 newHash := self rawHashBitsOf: aBehavior.
 self assert: (self classAtIndex: newHash) = aBehavior].
^newHash


> Thanks for any answers,
>
> Regards, Clement
>

cheers!


>
>
>
> 2013/11/12 Henrik Johansen <henrik.s.johansen at veloxit.no>
>
>>
>>
>> On 12 Nov 2013, at 11:55 , Henrik Johansen <henrik.s.johansen at veloxit.no>
>> wrote:
>>
>> nterest ~= time and: [skills]
>>
>>
>> OT: I swear, missing parenthesis will be the death of me!
>>
>>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131112/0bf359e8/attachment-0001.htm