Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])

Klaus D. Witzel klaus.witzel at cobss.com
Tue Sep 11 12:55:25 UTC 2007


For name/assoc binding there was nothing which seems to depend on  
Association>>#=, say when doing

  Morph compileAllFrom: Morph

except when Dictionary>>#scanFor: is used (for storing bindings). But  
these (bindings) are by name, not by value, so there seems to be no need  
for treating them with #=.

Only #scanFor: is reported by Goya to do Association>>#= (and all I did  
run was browsers and other tools and #compileAllFrom:, in stock images).

Another observation (which might/not have something to do with  
Association>>#=) is

  Association allSubInstances select: [:assoc | (assoc key isKindOf:  
Association) or: [assoc value isKindOf: Association]]

In 3.7/3.8 there are two class vars of CompiledMethod which are  
associations of associations, namely TempNameCache and BlockNodeCache  
(ignoring the ->->'s of the VB-Regex package which is not in 3.9).

Can someone tell the class var refs for TempNameCache and BlockNodeCache  
in 3.8 (stock #6665), here it barks because of problems with source code  
access ... strange.

In 3.9 TempNameCache disappeared (mantis turns up two entries on search  
string TempNameCache) but BlockNodeCache's still in 3.9, albeit unused and  
with value nil->nil. Since class builder doesn't like to remove  
BlockNodeCache the following sent it to limbo

  CompiledMethod classPool removeKey: #BlockNodeCache

BTW google knows about

- http://www.google.com/search?q=Squeak+BlockNodeCache

but Mantis doesn't turn up entries when searching for BlockNodeCache.

Will do more search for call sites with Association>>#= in 3.9, later.  
Hints/ideas on what to look at, except perhaps compilation/name binding,  
would help. TIA.

(cc'ed Marcus)

/Klaus

On Tue, 11 Sep 2007 09:40:17 +0200, I wrote:

> Hi Andreas,
>
> the addition of Association>>#hash seems to date back to 3.7; haven't  
> found it in 3.6.
>
> If you have a maschine with some spare time (I put my Notebook's CPU in  
> slow motion mode), you might want to look at
>
>   MessageTally spyOn: [Unicode compileAllFrom: Unicode]
>
> The example was choosen because there Association>>#hash in call site  
> Dictionary>>#scanFor: bites the CPU and so MessageTally has something to  
> report about. But #bindingOf: (=> #associationAt:) seems to be fast  
> enough to *not* appear in that report (may vary per CPU).
>
> The above is just about the #hash part, will instrument my Goya VM and  
> search for effective call sites of Association>>#= some time during the  
> week.
>
> (cc'ed Marcus)
>
> /Klaus
>
> On Tue, 11 Sep 2007 07:36:56 +0200, Andreas wrote:
>
>> Klaus D. Witzel wrote:
>>> on Sun, 09 Sep 2007 11:26:58 +0200, you wrote:
>>>> Revert Association>>= to what it used to be and everything will be  
>>>> fine (Association>>= is really, really badly broken; it causes  
>>>> problems all over the places and this is one of them).
>>>  That's a very, very good one, thanks for reminding us of that open  
>>> issue.
>>>  Since the compiler machinery (BytecodeGenerator) already uses  
>>> #literalEqual: and I want Decompiler to use the same comparision for  
>>> literals, it'll be easy to put #literalEqual: into Association without  
>>> touching its current #= implementation. In a later step it's perhaps  
>>> possible to really, really revert #= in Association.
>>
>> I only wish I knew *why* this got changed in the first place. Both,  
>> #hash and #= have Marcus' initials on it - can someone perhaps ask him  
>> why that change was needed or desirable? I'm afraid there may be some  
>> non-obvious users of that change but since I can't track down exactly  
>> where this happened I really don't know where to even start looking.
>>
>> Cheers,
>>    - Andreas
>>
>>
>
>
>
>





More information about the Squeak-dev mailing list