[squeak-dev] The Trunk: Tests-eem.96.mcz

Levente Uzonyi leves at elte.hu
Sun Oct 24 05:04:55 UTC 2010


On Sat, 23 Oct 2010, Eliot Miranda wrote:

> Hi Levente,
>
> On Sat, Oct 23, 2010 at 8:44 PM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Sun, 10 Oct 2010, commits at source.squeak.org wrote:
>>
>>  Eliot Miranda uploaded a new version of Tests to project The Trunk:
>>> http://source.squeak.org/trunk/Tests-eem.96.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Tests-eem.96
>>> Author: eem
>>> Time: 9 October 2010, 5:50:13.075 pm
>>> UUID: 8800404e-9468-4032-bee6-fe8400f7334a
>>> Ancestors: Tests-eem.95
>>>
>>> Reduce DecompilerTest failures to three legitimate failures.
>>> Do so by restricting tests to base classes in 4.1, by using
>>> deocmpileWithTempNames: to eliminate temp orderig issues, and by adding a
>>> few expected failures (but eliminating many more).
>>>
>>
>> I still get 5 errors. Methods which have a variable declared in an
>> optimized loop's block and that variable is also used by a real block have
>> to be recompiled. I came up with the following script:
>>
>> #(
>>        (Command veryDeepFixupWith:)
>>        (Installer reportFor:page:on:)
>>        (Player veryDeepFixupWith:)
>>        (PNGReadWriter processInterlaced)
>>        (SHMCClassDefinition withAllSuperclasses)
>>        (SHMCClassDefinition allInstVarNames)) do: [ :each |
>>                Smalltalk at: each first ifPresent: [ :class |
>>                        (class includesSelector: each second) ifTrue: [
>>                                class recompile: each second ] ] ].
>>
>> This is ok for the release and images with unloaded packages (core), but
>> it's not sufficient for images which have external packages loaded. Is there
>> a way to detect such methods without decompiling all methods in the image?
>>
>
> Yes, but I don't think it's much easier that the decompile approach.  The
> fix would be to use the VariableScopeFinder visitor in the decompiler to
> localize temps to optimized blocks.  I guess doing this always, rather than
> only when there's a conflict would be ok (it would certainly be easier to
> code).  What do you think?

I think we are talking about different things, though I may be wrong. I 
found that some methods need to be recompiled, because the modified 
decompiler cannot decompile them with temp names anymore. All of these 
methods followed the pattern I descibed. To fix these, I'd like to add a 
postscript to an MC package, that recompiles these methods. To do this 
properly, I need some code, that can detect all such methods in the image.
I tried to avoid the decompilation of all methods, because I assumed 
(based on earlier recompilations) that it will be very slow (10-30 
minutes), but it's surprisingly. So I came up with the following:

CompiledMethod allInstances
 	do: [ :method |
 		[ method decompileWithTemps ]
 			on: AssertionFailure, Error
 			do: [
 				Transcript ensureCr; nextPutAll: 'Recompiling '; show: method; cr.
 				method methodClass recompile: method selector ] ]
 	displayingProgress: 'Recompiling...'

It finishes in 30 seconds on my machine using Cog, so I think it'll be 
fast enough.


Levente

>
> best
> Eliot
>
>
>>
>>
>> Levente
>>
>>
>> snip
>>
>>
>



More information about the Squeak-dev mailing list