Just as a side not on efficiency - globals are much more often read  
than written. The original goal might even be fulfilled by read-only  
variables (not sure about that). So optimizing for read is essential,  
but I have a hunch that writing could be much slower without any  
noticeable effect on performance.

- Bert -

Am 24.10.2006 um 18:07 schrieb ncellier at ifrance.com:

> 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 ?
>
>
> Nicolas
>
>
> 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 !
> http://web.ifrance.com
>