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.


>
> This is something I wanted to do for year in Hapao...
>
> Alexandre
>
>
>
> On Apr 7, 2013, at 3:21 AM, Clément Bera <bera.clement at gmail.com> wrote:
>
> I don't know. The main problem is that the AST-interpreter is not fast
> enough. The best solution for speed would be to improve it as they do in
> this paper : http://dl.acm.org/citation.cfm?id=2384587 (their
> ast-interpreter is faster than a byte code interpreter).
>
> Another solution would be to execute some method with the vm and other one
> with the ast-interpreter, but it is quite some work.
>
>
> 2013/4/7 Alexandre Bergel <alexandre.bergel at me.com>
> Would it be possible to annotate the method with some checkpoints within
> the method? This should be fast enough I guess.
>
> Alexandre
>
>
> On Apr 6, 2013, at 10:35 AM, Clément Bera <bera.clement at gmail.com> wrote:
>
> > This is exactly that. The tree coverage tool is a subclass of
> AST-interpreter, which adding to the interpretation marks the nodes. And
> then I use this marking to color the source code. And I use as you said RB
> ast.
> >
> > This is why I implemented it in a few hours, I had already an
> AST-interpreter, so I've just created a quick subclass and a spec UI.
> >
> >
> > 2013/4/6 Frank Shearar <frank.shearar at gmail.com>
> > So if you don't mind me being very loose with terminology, you
> > interpret (RB) ASTs, and the act of interpreting marks the nodes in
> > these ASTs, which you can then use to colour source?
> >
> > frank
> >
> > On 6 April 2013 11:00, Clément Bera <bera.clement at gmail.com> wrote:
> > > Actually, it is quite different than Jejak.
> > >
> > > Implementation wise, Jejak used Opal so I guess it relies on bytecode
> > > modification to do its analysis where my tool relies on ast
> annotations.
> > >
> > > This implies some difference in features. It seems that Jejak record
> all
> > > calls, all values and all assignments in a method (which is byte code
> level
> > > feature), whereas I record for each ast node if it was interpreted or
> not
> > > (which is ast level feature). I guess there would be a little
> difference in
> > > the use cases.
> > >
> > >
> > > 2013/4/6 Frank Shearar <frank.shearar at gmail.com>
> > >>
> > >> On 6 April 2013 07:47, Stéphane Ducasse <stephane.ducasse at inria.fr>
> wrote:
> > >>>
> > >>> Clement built in a couple of hours the following nice branch
> > >>> analysecoverage tools :)
> > >>> It is dead slow but cool.
> > >>
> > >>
> > >> By "branch coverage tool" do you mean Jejak?
> > >>
> > >> frank
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Clément Béra
> > > Mate Virtual Machine Engineer
> > > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
> >
> >
> >
> >
> > --
> > Clément Béra
> > Mate Virtual Machine Engineer
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>
> --
> Clément Béra
> Mate Virtual Machine Engineer
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130408/de515bbb/attachment.htm