[Vm-dev] tempVectors use case and current issues

[Nicolas Cellier]

Hi Denis,
Special bytecodes don't have to be changed: just don't use them and replace
by regular sends at bytecode generation (with a special compiler, or some
IR translater). All can be done at image side then. Or did I miss something?

Le jeu. 28 mars 2019 à 20:05, Denis Kudriashov <dionisiydk at gmail.com> a
écrit :

>
> Hi.
>
> I found interesting case where tempVectors can be used in remote
> scenarios. The store into remote temp can be really remote (not just about
> outer context).
> I played with following example:
>
> | temp |
> temp := 10.
> remote evaluate: [temp := temp + 1].
> temp.
>
>
> For the moment forget about remote thing and look into it as a normal
> local case:
> temp var here is managed indirectly through tempVector. You can see it
> using expression after first assignment:
>
> thisContext at: 1 "=>#(10)"
>
>
> So the value in fact is stored in the array instance and read from it.
> But because of optimization it happens out of the array control. No #at:
> and #at:put: messages are sent during this code. VM magically changes the
> state of this array (there are special bytecodes for this).
>
> Now my remote use case. Imagine that vm actually sends #at: and #at:put:
> messages to tempVector. Then remoting engine can transfer temp vector (as
> part of context) as a proxy. So on remote side the block [temp := temp + 1]
> will actually ask the sender (client) for the value and for the storage. So
> all block semantics will be supported. Temp in remote outer context will be
> modified. I think it would be super cool if such transparency would be
> possible.
>
> I played with this example using Seamless in Pharo. It already works in
> the way I described but due to VM optimization it does not provide expected
> behavior. And worse than that it actually corrupts transferred proxy
> because in place of array the proxy instance is materialized.
>
> This leads us to the issue with safety of tempVector operations. Following
> example shows how we can affect the state of tempVector using reflection:
>
> | temp |
> temp := 10.
> (thisContext at: 1) at: 1 put: 50.
> [temp := temp + 1] value.
> temp. "==>51"
>
> It is cool that we can do it. But there is no any safety check in the VM
> level over tempVector object:
>
> | temp |
> temp := 10.
> thisContext at: 1 put: Object new.
> [temp := temp + 1] value.
> temp.
>
>
> It breaks with DNU: #+ is sent to nil. Temp became nil.
>
>
> | temp |
> temp := 10.
> thisContext at: 1 put: #() copy.
> [temp := temp + 1] value.
> temp.
>
>
> Sometimes it breaks with same error. Sometimes it returns random number.
> I guess in these cases VM breaks memory boundary of tempVector.
>
> And two exotic cases:
>
>
> | temp |
> temp := 10.
> (thisContext at: 1) beReadOnlyObject.
> [temp := temp + 1] value.
> temp.
>
>
> It silently return 11. It does not break read only protection. But no
> error is signalled.
>
> | temp |
> temp := 10.
> (thisContext at: 1) become: #() copy.
> [temp := temp + 1] value.
> temp.
>
>
> It returns #().  (In Pharo  #() + 1 = #()  ).
> I use become to check how forwarding is working in that case. (it works
> fine when array has correct size)
>
> How we can improve this behavior? How it would effect performance?
> My proposal is to send real messages to tempVector when it is not an array
> instance. Then image will decide what to do.
>
> Best regards,
> Denis
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190328/81823020/attachment.html>