[squeak-dev] Re: [Vm-dev] Re: [Pharo-project] [Preview] Branch test coverage analysis tool for Pharo 3.0 :)

Eliot Miranda eliot.miranda at gmail.com
Thu Apr 11 01:59:38 UTC 2013


On Mon, Apr 8, 2013 at 6:02 PM, Eliot Miranda <eliot.miranda at gmail.com>
 wrote:
>
> On Mon, Apr 8, 2013 at 9:32 AM, Alexandre Bergel <alexandre.bergel at me.com>
>  wrote:
>
>> What I had in mind, is something like:
>> -=-=-=-=-=-=-=-=-=-=
>> myMethodWithBranch
>> self foo.
>> v
>> ifTrue: [ ... ]
>> ifFalse: [ ... ]
>> -=-=-=-=-=-=-=-=-=-=
>>
>> -=-=-=-=-=-=-=-=-=-=
>> myMethodWithBranch
>> self foo.
>> v
>> ifTrue: [ *self checkPoint: 1.* ... ]
>> ifFalse: [ *self checkPoint: 2.* ... ].
>> *self checkPoint: 3.*
>> -=-=-=-=-=-=-=-=-=-=
>>
>> All these checkpoint will be inserted by manipulating the bytecode. You
>> can then optimize a bit by removing checkpoints that have been reached.
>> The method #checkPoint: could then use some attributes to the
>> CompiledMethod.
>>
>> This is a common technique when (i) the VM does not give you what you
>> need and (ii) when you do not want to change the VM.
>>
>
> I just implemented something to this effect for our project at Cadence.
>  It works by
> - an assembler/disassebler that can convert a method into a sequence of
> messages, one for each of its bytecodes and back
> - using the disassembler to obtain labels which occur at the start of each
> basic block
> - replacing the first bytecode in every basic block with an illegal
> bytecode, remembering the pc and its correct bytecode in the method
> properties
> - implementing a method on MethodContext which receives the unknowBytecode
> message sent by the VM when it encounters an illegal bytecode
> - the method replaces the illegal bytecode with the correct bytecode,
> removing the entry from properties, and continues
>
> The JIT refuses to compile methods that contain illegal bytecodes so this
> runs at interpreter speed until a method no longer contains illegal
> bytecodes (has been completely covered).  But the illegal bytecode is
> executed at most once for each basic block, since it is replaced
> immediately it is executed.  The information remaining in properties is
> that of the basic blocks that have not been executed.
>
> In the Squeak/Pharo bytecode set there are three unknown bytecodes, 126,
> 127 & 139.  I have a Monticello package and tests if you're interested.
>

On Mon, Apr 8, 2013 at 11:06 PM, Frank Shearar <frank.shearar at gmail.com>wrote:
...

> I most definitely am!
>
> frank


On Tue, Apr 9, 2013 at 10:19 AM, Marcel Taeumel <
marcel.taeumel at student.hpi.uni-potsdam.de> wrote:

> Me, too! :)
>

On Tue, Apr 9, 2013 at 12:32 PM, Alexandre Bergel <alexandre.bergel at me.com>
 wrote:
...

Yes please. I am interested!
>


OK, in http://ss3.gemstone.com/ss/MethodMassage are the two packages needed
to make this work in Squeak trunk.  I added Frank and Alexandre as
developers.  Marcel, I couldn't find you.  If you want to be added you'll
have to register.  BytecodeCoverageTests is the place to start looking.

I'd love to see someone use this to do fast shape change on class
redefinition.
-- 
cheers,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130410/812fc640/attachment.htm


More information about the Squeak-dev mailing list