Efficient thread-local shared variables

ncellier at ifrance.com ncellier at ifrance.com
Tue Oct 24 16:07:38 UTC 2006

Yes, despite very confusing names i used, you understood me well, "key" was to be replaced with any variable name lying in the pool dictionary.

Thank you for these explanations.

I understand that having mutable literals would break VW JIT.
It may be worse if we use a trick to share a literal reference between two methods (the getter and setter), and that trick is not recognized at JIT level...

In order to use traditional compiler optimizations, you could maybe use a class var for each pool dictionary entry in your anonymous class instead of a literal reference.
This way, no use to flush the VM cache whenever the value changes...

Compared to traditional global variable access that directly adresses the association (with value or value:), this cost a first method call to get the thread-dependent pool dictionary and an additional method lookup to get/set the value.

Could such kind of method lookup be reduced by an inlining cache a la strongtalk ?


Le Mardi 24 Octobre 2006 16:17, vous avez écrit :
> On Oct 24, 2006, at 12:18 PM, ncellier at ifrance.com wrote:
> > So you have to share the first literal between read and write
> > access methods ?
> > like pseudo byte code:
> > key
> >   ^(literalAt: 1) value
> >
> > key: aValue
> >   ^(literalAt: 1) value: aValue
> Your code confuses me, but you seem to be talking about implementing
> Association behavior. In my scheme CompiledMethods come closest to
> this role.
> So getting to the 'association' could be implemented on the anonymous
> class as
> associationAt: aSymbol
>    ^self compiledMethodAt: aSymbol
> then CompiledMethod could implement
> key
>    ^self selector
> value
>    ^self localAt: 1
> Changing the value is something I haven't needed/tried yet because in
> VW matters are complicated by the JIT cache that would (might?) need
> to be flushed. This requires me getting to the class that holds this
> CompiledMethod. Conceptually:
> value: anObject
>    self localAt: 1 put: anObject.
>    self classThatImplementsMe flushVMMethodCashesFor: self selector.
> Overall I'm not too keen on modeling full dictionary behavior because
> my 'dictionary' is already different in that it is reified as two
> objects (the anonymous class and its singleton instance), the class
> can be regarded as a mirror-like accessor to the dictionary for doing
> 'meta' queries like getting to an 'association' and for altering the
> dictionary contents. The singleton instance is used for lookup only
> (any support methods implemented on it would clash with keys you
> might want to use, currently only #doesNotUnderstand: is implemented
> on my anon class).
> One of my pet peeves about St is that #doesNotUnderstand: should be
> implemented on he class side so it doesn't pollute the object's
> selector namespace...
> R
> -

iFRANCE, exprimez-vous !

More information about the Squeak-dev mailing list