[Vm-dev] Spur Object 64 bit format

stephane ducasse stephane.ducasse at gmail.com
Thu Nov 14 11:26:45 UTC 2013


Thanks for the answer.

Clement I love your questions :)
Stef

On Nov 12, 2013, at 7:33 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 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/20131114/96f2de9f/attachment-0001.htm


More information about the Vm-dev mailing list