Smalltalk › Squeak › Squeak - Dev

Why is #String->String an Alias?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Chris Muller-3

Why is #String->String an Alias?

I wrote:

On Sat, Dec 14, 2013 at 4:33 PM, Chris Muller <[hidden email]> wrote:
>
> I'm trying to get a picture of our state of quality (for release) in
> terms of our tests.
>
> Here are failing tests in Trunk (as debuggable expressions):
> ... snip...
>
> 5. (MethodHighlightingTests selector: #testMethodHighlighting) debug.

Working on this one today. The root cause of the test breakage seems
to be the fact that the variable binding for String is now an Alias,
which responds "true" to #isSpecialReadBinding.

This causes LiteralVariableNode>>#sizeCodeForValue: to bypass the
guard at the top of that method, calculating a different value than it
otherwise would.

What should be done?

Frank Shearar-3

Re: Why is #String->String an Alias?

On 17 December 2013 22:27, Chris Muller <[hidden email]> wrote:

> I wrote:
>
> On Sat, Dec 14, 2013 at 4:33 PM, Chris Muller <[hidden email]> wrote:
>>
>> I'm trying to get a picture of our state of quality (for release) in
>> terms of our tests.
>>
>> Here are failing tests in Trunk (as debuggable expressions):
>> ... snip...
>>
>> 5. (MethodHighlightingTests selector: #testMethodHighlighting) debug.
>
> Working on this one today. The root cause of the test breakage seems
> to be the fact that the variable binding for String is now an Alias,
> which responds "true" to #isSpecialReadBinding.
>
> This causes LiteralVariableNode>>#sizeCodeForValue: to bypass the
> guard at the top of that method, calculating a different value than it
> otherwise would.
>
> What should be done?

(right arrow, enter)

Right. I'm not sure what should be done, but we've seen Aliases
causing trouble elsewhere. IIRC I chased a semi-wild goose finding out
that #String -> Alias -> ClassBinding pointing to String isn't the
same as a ClassBinding pointing to String.

Colin right asked why we have Aliases at all (because at the moment we
only have one Environment, hence no imports, hence no need for any
Aliases). We don't know where they came from. Attempting to Compiler
recompileAll doesn't get right of them.

frank

Nicolas Cellier

Re: Why is #String->String an Alias?

Previous version of Association>>asBinding: could have created the Alias...

By evaluating this:

Smalltalk globals instVarNamed: 'references' put: IdentityDictionary new.
Symbol rehash. "Argh this should not be necessary but I got two instances of the same Symbol"
Compiler recompileAll.
Smalltalk garbageCollect.
Alias allInstances size.

the number of Alias felt from 45 to 6 in my image, presumably some closure.

2013/12/17 Frank Shearar <[hidden email]>

On 17 December 2013 22:27, Chris Muller <[hidden email]> wrote:
> I wrote:
>
> On Sat, Dec 14, 2013 at 4:33 PM, Chris Muller <[hidden email]> wrote:
>>
>> I'm trying to get a picture of our state of quality (for release) in
>> terms of our tests.
>>
>> Here are failing tests in Trunk (as debuggable expressions):
>> ... snip...
>>
>> 5. (MethodHighlightingTests selector: #testMethodHighlighting) debug.
>
> Working on this one today. The root cause of the test breakage seems
> to be the fact that the variable binding for String is now an Alias,
> which responds "true" to #isSpecialReadBinding.
>
> This causes LiteralVariableNode>>#sizeCodeForValue: to bypass the
> guard at the top of that method, calculating a different value than it
> otherwise would.
>
> What should be done?

(right arrow, enter)

Right. I'm not sure what should be done, but we've seen Aliases
causing trouble elsewhere. IIRC I chased a semi-wild goose finding out
that #String -> Alias -> ClassBinding pointing to String isn't the
same as a ClassBinding pointing to String.

Colin right asked why we have Aliases at all (because at the moment we
only have one Environment, hence no imports, hence no need for any
Aliases). We don't know where they came from. Attempting to Compiler
recompileAll doesn't get right of them.

frank

Nicolas Cellier

Re: Why is #String->String an Alias?

Bingo, by instrumenting basicNew with self name == #Alias ifTrue: [self haltOnce], I got my first Alias during update 228, with previous version of Association>>asBinding: (said like that it sounds like sexually transmitted infection).

Once in the references, an Alias is sticky. If you recompile, you just propagate the Alias in each and every reference to the global...

2013/12/18 Nicolas Cellier <[hidden email]>

Previous version of Association>>asBinding: could have created the Alias...

By evaluating this:

Smalltalk globals instVarNamed: 'references' put: IdentityDictionary new.
Symbol rehash. "Argh this should not be necessary but I got two instances of the same Symbol"
Compiler recompileAll.
Smalltalk garbageCollect.
Alias allInstances size.

the number of Alias felt from 45 to 6 in my image, presumably some closure.

2013/12/17 Frank Shearar <[hidden email]>

On 17 December 2013 22:27, Chris Muller <[hidden email]> wrote:
> I wrote:
>
> On Sat, Dec 14, 2013 at 4:33 PM, Chris Muller <[hidden email]> wrote:
>>
>> I'm trying to get a picture of our state of quality (for release) in
>> terms of our tests.
>>
>> Here are failing tests in Trunk (as debuggable expressions):
>> ... snip...
>>
>> 5. (MethodHighlightingTests selector: #testMethodHighlighting) debug.
>
> Working on this one today. The root cause of the test breakage seems
> to be the fact that the variable binding for String is now an Alias,
> which responds "true" to #isSpecialReadBinding.
>
> This causes LiteralVariableNode>>#sizeCodeForValue: to bypass the
> guard at the top of that method, calculating a different value than it
> otherwise would.
>
> What should be done?

(right arrow, enter)

Right. I'm not sure what should be done, but we've seen Aliases
causing trouble elsewhere. IIRC I chased a semi-wild goose finding out
that #String -> Alias -> ClassBinding pointing to String isn't the
same as a ClassBinding pointing to String.

Colin right asked why we have Aliases at all (because at the moment we
only have one Environment, hence no imports, hence no need for any
Aliases). We don't know where they came from. Attempting to Compiler
recompileAll doesn't get right of them.

frank

Chris Muller-3

Re: Why is #String->String an Alias?

On Tue, Dec 17, 2013 at 7:35 PM, Nicolas Cellier
<[hidden email]> wrote:
> Bingo, by instrumenting basicNew with self name == #Alias ifTrue: [self
> haltOnce], I got my first Alias during update 228, with previous version of

Where did you put that in relation to the primitive call?

Bert Freudenberg

Re: Why is #String->String an Alias?

On 19.12.2013, at 22:53, Chris Muller <[hidden email]> wrote:

> On Tue, Dec 17, 2013 at 7:35 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> Bingo, by instrumenting basicNew with self name == #Alias ifTrue: [self
>> haltOnce], I got my first Alias during update 228, with previous version of
>
> Where did you put that in relation to the primitive call?

I don't think you can do it without adding a new method:

Behavior>>basicNew
self name == #Alias ifTrue: [self haltOnce].
^ self actualBasicNew

But what I'd actually do is this:

Alias class>>basicNew
self haltOnce.
^ super basicNew

Then you would only have to check for "self name == #Alias" if Alias had subclasses.

- Bert -

Chris Muller-3

Re: Why is #String->String an Alias?

On Thu, Dec 19, 2013 at 4:03 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 19.12.2013, at 22:53, Chris Muller <[hidden email]> wrote:
>
>> On Tue, Dec 17, 2013 at 7:35 PM, Nicolas Cellier
>> <[hidden email]> wrote:
>>> Bingo, by instrumenting basicNew with self name == #Alias ifTrue: [self
>>> haltOnce], I got my first Alias during update 228, with previous version of
>>
>> Where did you put that in relation to the primitive call?
>
> I don't think you can do it without adding a new method:
>
> Behavior>>basicNew
> self name == #Alias ifTrue: [self haltOnce].
> ^ self actualBasicNew
>
> But what I'd actually do is this:
>
> Alias class>>basicNew
> self haltOnce.
> ^ super basicNew
>
> Then you would only have to check for "self name == #Alias" if Alias had subclasses.

Alias doesn't exist yet in the image, somewhere the update process
bring it in and creates instances of it.

Trying to chase that down, so I put the basicNew override in ClassDescription.