[Vm-dev] Advice Required - Live Typing - Saving local vars types

Hernan Wilkinson hernan.wilkinson at 10pines.com
Wed Jan 2 18:23:06 UTC 2019


Hi Eliot!


> Hence the solution top your problem is to use FullBlocks.  The SistaV1
> bytecode set supports full blocks, which means it is possible to use a
> separate CompiledBlock for every block in a method. In Squeak one has to
> set the Preferred bytecode set encoder class preference to
> EncoderForSistaV1 and recompile the system (the system supports up to two
> bytecode sets).
>

What is FullBlocks? could you comment on that or point to some reading?
In the meantime I'll take a look at the code.
Also, could you send me a link to read about Sista? I don't remember the
details of it.


> The support is in Squeak and fully tested there (my work image uses the
> SistaV1 bytyecode set).  Some of the support is in Pharo 7, but there is no
> preference and so no easy way to force the use of SistaV1 and Full Blocks.
> I don't know if the support has been ported to Cuis from Squeak, but it
> should not be difficult to do.
>

Not it has not... I'll ask Juan what his plan is about it.


>
>
> Well it is difficult to explain.  But a key insight is that the Decompiler
> solves exactly this problem in mapping from bytecodes back to source, and
> that the Debugger solves this problem in displaying the temporary variables
> that are in scope.  So if you have a look at the code in DebuggerMethodMap
> you should find an API that provides what you want.
>

yes yes, I have read it and that gives me all I need from the image point
of view, but the problem is in the VM


> For example, these Context methods all use the relevant API for
> linearizing temps:
>
> *Context methods for debugger access*
> *namedTempAt:* index
> "*Answer the value of the temp at index in the receiver's sequence of
> tempNames.*"
> ^self debuggerMap namedTempAt: index in: self
>
> *namedTempAt:* index *put:* aValue
> "*Set the value of the temp at index in the receiver's sequence of
> tempNames.*
> * (Note that if the value is a copied value it is also set out along the
> lexical chain,*
> *  but alas not in along the lexical chain.).*"
> ^self debuggerMap namedTempAt: index put: aValue in: self
>
> *tempNames*
> "*Answer a SequenceableCollection of the names of the receiver's
> temporary *
> * variables, which are strings.*"
>
> ^ self debuggerMap tempNamesForContext: self
>
> *tempsAndValues*
> "*Return a string of the temporary variables and their current values*"
> ^self debuggerMap tempsAndValuesForContext: self
>
> So for example if I evaluate this:
>
>     (1 to: 2) inject: 0 into: [:a :b| ^thisContext sender tempsAndValues]
>
> I get this:
>
> 'thisValue: 0
> binaryBlock: [closure] in Context class>>DoIt
> nextValue: 0
> each: 1
> '
>
> So the simplified API is provided by DebuggerMethodMap.
>
> But you want to do this in the VM.  That's a lot harder, and it makes the
> VM implementation very dependent on the specific compiler implementation.
> If you go with Full Blocks things may not be too bad.  But moving things up
> to the image level will make everything a lot easier, faster to develop,
> and extensible.
>

I try to do the least possible in the VM, in fact the changes I made are
very simple and independent of the compiler/etc. Doing it on the image side
(using meta-links for example in Pharo) is too slow and not really usable.
What I did is usable and simple, I'm working with that VM/image all the
time and works great.
I'll see what you suggest of FullBlocks and see how it can help... in the
meantime I think I'll do the option 4) explained bellow.
I'll keep you posted

Thanks!
Hernan.


>  After a lot of ideas and possibilities, I found that the method/closure
>> start pc could be use to decide the array's index to use (based on
>> something similar to what CompiledMethod>>#startpcsToBlockExtents returns).
>>  So, every time a new activation context is created (for example
>> StackInterpreter>>#activateNewClosure:outer:method:numArgs:mayContextSwitch:,
>> StackInterpreter>>#internalActivateNewMethod and so on) I can use the start
>> pc to calculate the array's index.
>>  So, let's say I have that solved too, now the problem is how can I
>> access that index from the bytecode's code?. I have the following ideas:
>> 1) Add an inst. var. to MethodContext that will have the index (or even
>> better, the local's types array). So every time a new context is created, I
>> calculate the index based on the PC and set that inst. var.
>> 2) Do the same as in 1) but adding an inst. var. to BlockClosure (better
>> than 1 because the closure is created once while the method context could
>> be created more than once for the same closure)
>> 3) Push the calculated index in the stack (as the IP, SP, etc. are
>> pushed). Based on the num. args + num. temps., calculate the position in
>> the stack of that index every time a type has to be saved.
>> 4) Have an interpreter variable as 'method' but called, let's say,
>> 'contextVarsTypes' that is set every time a new activation is created. The
>> previous contextVarsTypes value is pushed in the stack and restore from it
>> when exiting a context.
>>
>> The problem with 1) and 2) is that MethodContext and BlockClosure can not
>> be modified (at least not easily, a new image format would be needed, etc),
>> but the advantage is that I don't have to worry about that value when a
>> context is leaved.
>> Between 3) and 4) and think 4) is faster but I'm not sure that if a GC is
>> executed and the array moved (let's say contextVarsTypes points directly to
>> the types array), that contextVarsTypes will point to the new arrays
>> position in memory (will that happen? how is 'method' changed if a GC is
>> executed?)
>>
>> Which one do you think is better/faster/possible?
>> Any advice/comment on this matter will be appreciated.
>> If there is an easier/different way to solve this problem, please help me
>> :-)
>>
>> Thanks!
>> Hernan
>>
>>
>> --
>>
>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190102/ab295e71/attachment-0001.html>


More information about the Vm-dev mailing list