[squeak-dev] Re: UI lockup in Squeak 4.1

Rob Withers reefedjib at yahoo.com
Wed Jul 14 19:20:09 UTC 2010


--------------------------------------------------
From: "Chris Muller" <asqueaker at gmail.com>
Sent: Wednesday, July 14, 2010 12:30 PM
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1

> I'm not sure if this is the same context of the issue you had, but..
> this seems like a good time to reflect on #becomeForward:.
>
> Until 5 or 6 years ago, we only had Object>>#becomeForward: (and not
> #becomeForward:copyHash:).  #becomeForward: would mutate the
> identityHash of the argument to be that of the receiver, causing any
> identity-hashed collections it might be residing in to need to be
> rehashed.
>
> Unfortunately, mutating the identityHash of important objects such as
> an important Symbol in the SymbolTable (like, #at: !!); there was no
> time to rehash the SymbolTable or anything else before the system
> needed it, couldn't find it, and locked up.
>
> So we added Object >> #becomeForward:copyHash: so that false could be
> passed as the second argument, causing it not to mutate the
> identityHash of the target.
>

Chris,

I am using both #becomeForward: and #becomeForward:copyHash:.  One thing I 
noted you said: "#becomeForward: would mutate the identityHash of the 
argument to be that of the receiver, causing any identity-hashed collections 
it might be residing in to need to be rehashed."

The first time I read it as if you were causing the rehashing to occur, but 
on second reading you only said that Sets and Dictionaries are in need to be 
rehashed.  I.e. it is up to the application programmer to cause the rehash.

Mine is a slightly different situation, concerned with hashed locations 
where the receiver WAS, which is now the target with a different hash.  Here 
is the appropriate code snippet in my system:
	rehashables := self collectRehashableCollections.
	context isSmallInteger
		ifTrue: [self becomeForward: context copyHash: false]
		ifFalse: [self becomeForward: context].
	rehashables do: [:each | each rehash].

Therefore, I need to rehash collections holding the receiver.

collectRehashableCollections

	| level1 level2 sets level3 dictionaries |
	level1 := Utilities pointersTo: self except: #(Array with: self).
	level2 := level1
		inject: OrderedCollection new
		into: [:coll :elem |
			coll addAll: (Utilities pointersTo: elem except: #(Array with: self with: 
elem)).
			coll].
	sets := level2 select: [:elem | elem isKindOf: Set].
	level3 := level2
		inject: OrderedCollection new
		into: [:coll :elem |
			coll addAll: (Utilities pointersTo: elem except: #(Array with: self with: 
elem)).
			coll].
	dictionaries := level3 select: [:elem | elem isKindOf: Dictionary].

	^ sets, dictionaries

Rob

> - Chris
>
> On Wed, Jul 14, 2010 at 3:31 AM, Rob Withers <reefedjib at yahoo.com> wrote:
>> I found the problem!
>>
>> Of course, it was my code causing this.  I was doing the equivalent of:
>>
>>     Object new becomeForward: nil.
>>
>> and this was nilling out the contents of that KnownEnvironments 
>> dictionary.
>> I tested with the above code, without my code, and indeed it caused the
>> problem.  I am now avoiding both SmallIntegers and nil when using
>> #becomeForward:
>>
>> Thanks for everyone's help in this matter!
>>
>> Rob
>> From: Eliot Miranda
>> Sent: Tuesday, July 13, 2010 5:03 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1
>>
>>
>> On Tue, Jul 13, 2010 at 1:53 PM, Rob Withers <reefedjib at yahoo.com> wrote:
>>>
>>>> From: Eliot Miranda
>>>> Sent: Tuesday, July 13, 2010 4:11 PM
>>>> To: The general-purpose Squeak developers list
>>>> Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > On Tue, Jul 13, 2010 at 12:59 PM, Rob Withers <reefedjib at yahoo.com> >
>>>> > wrote:
>>>> >
>>>> > Hi Eliot,
>>>> >
>>>> >
>>>> > I already found it.
>>>> >
>>>>
>>>> Doh!
>>>>
>>>> >  It is this method, when the result of the dictionary lookup is nil 
>>>> > for
>>>> > > 'en', and it recursively calls localeID: with 'en'.
>>>> >
>>>> >
>>>> > LanguageEnvironment class>>#localeID: localeID
>>>> > ^self knownEnvironments at: localeID ifAbsent: [self localeID:
>>>> > (LocaleID
>>>> > isoLanguage: 'en')]
>>>> >
>>>>
>>>>
>>>> which clearly needs to read something like
>>>>  LanguageEnvironment class>>#localeID: localeID
>>>>    ^self knownEnvironments
>>>>        at: localeID
>>>>        ifAbsent: [self knownEnvironments at: (LocaleID isoLanguage:
>>>> 'en')]
>>>>
>>>
>>> The problem is that something changed the entry for 'en' from
>>> Latin1Environment to nil.  So the absent block will still fail, although
>>> this time as an Error and not a recursive, memory-growing loop.
>>>
>>> I had in mind:
>>> LanguageEnvironment class>>#localeID: localeID
>>>
>>>   ^self knownEnvironments
>>>       at: localeID
>>>       ifAbsent: [
>>>           | env id |
>>>           env := Latin1Environment new.
>>>           id := LocaleID isoString: 'en'.
>>>           env localeID: id.
>>>           self knownEnvironments at: id put: env.
>>>           ^ env].
>>
>>
>> LanguageEnvironment class>>#localeID: localeID
>>    ^self knownEnvironments
>>        at: localeID
>>        ifAbsent: [self knownEnvironments
>>                             at: (LocaleID isoLanguage: 'en')
>>                             ifAbsentPut:
>>                                 [Latin1Environment new
>>                                     localeID: (LocaleID isoString: 'en');
>>                                     yourself]]
>>
>> No?
>>>
>>>
>>>>
>>>> > I start the image with an intact KnownEnvironments.   Something 
>>>> > somehow
>>>> > > nils out the entries after I > > > have run for awhile.   ??????
>>>> >
>>>>
>>>> So guard against resetKnownEnvironments?
>>>
>>> I had a 'self halt' and it never got called.
>>>
>>> I have no idea how it was nilling out the entries.
>>
>> Are there any senders of knownEnvironments and removeKey: et al?  Do you
>> have changes to Dictionary grow code which causes a bug on rehash? 
>> etc...
>>>
>>> Rob
>>>
>>>
>>>
>>
>> ________________________________
>>
>>
>>
>>
> 



More information about the Squeak-dev mailing list