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
|