Having a specific class for temp vectors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Having a specific class for temp vectors

Clément Béra
 
Hello everyone,

This is the second time I have issues with temp vectors. They are internal to the runtime but are exposed to the programmer. The problem is that the runtime have expectations with the temp vectors that the programmer could break, crashing the VM.

The first thing in Spur is that temp vectors can through the become primitive be a forwarding object, which crashes the VM as remote temporary variable stores do not check if the temp vector is a forwarder.

The second thing, now that I am working with immutability (VW's immutability), is that temp vectors could be marked as immutable and the runtime does not check at each remote temp store if it is immutable.

What I would like is to have a specific subclass of Array, likely to be called TempVector, and have temp vectors be an instance of TempVector instead of Array. Then the VM could easily check is an object is a temp vector and fail the become primitive or the setImmutability primitive.

I think this should be exposed in the image. It would mean having the TempVector class in the special object array.

What do you think ?

Clement

Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Levente Uzonyi-2
 
On Sat, 21 Nov 2015, Clément Bera wrote:

> This is the second time I have issues with temp vectors. They are
internal to the runtime but are exposed to the programmer. The problem is
that the runtime have expectations with the temp vectors that the
programmer could break, crashing the VM.

Is it possible to mangle the temp vectors unintentionally?
The only scenario I can imagine right now is when someone accesses these
Arrays via #allInstances and #allObjects.
Unless there are other ways to access them, I wouldn't change them and
wouldn't add VM checks either.
There are so many practically unavoidable ways to make the VM crash by
the programmer that I don't think it'd be worth patching this one.

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Clément Béra
 
There is one way using reflective APIs on Contexts. 

(thisContext tempAt: 1) for example.

If you think it doesn't matter then I won't bother fixing these details. I wonder if it matters.

2015-11-21 13:52 GMT+01:00 Levente Uzonyi <[hidden email]>:
 
On Sat, 21 Nov 2015, Clément Bera wrote:

This is the second time I have issues with temp vectors. They are
internal to the runtime but are exposed to the programmer. The problem is that the runtime have expectations with the temp vectors that the programmer could break, crashing the VM.

Is it possible to mangle the temp vectors unintentionally?
The only scenario I can imagine right now is when someone accesses these Arrays via #allInstances and #allObjects.
Unless there are other ways to access them, I wouldn't change them and wouldn't add VM checks either.
There are so many practically unavoidable ways to make the VM crash by the programmer that I don't think it'd be worth patching this one.

Levente

Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

stephane ducasse-2
In reply to this post by Clément Béra

Hi clement

bringing more stability is good to me.
Reducing the number of ways we can break the system is nice. Especially when the solution is simple.

Stef

On 21 Nov 2015, at 12:46, Clément Bera <[hidden email]> wrote:

> Hello everyone,
>
> This is the second time I have issues with temp vectors. They are internal to the runtime but are exposed to the programmer. The problem is that the runtime have expectations with the temp vectors that the programmer could break, crashing the VM.
>
> The first thing in Spur is that temp vectors can through the become primitive be a forwarding object, which crashes the VM as remote temporary variable stores do not check if the temp vector is a forwarder.
>
> The second thing, now that I am working with immutability (VW's immutability), is that temp vectors could be marked as immutable and the runtime does not check at each remote temp store if it is immutable.
>
> What I would like is to have a specific subclass of Array, likely to be called TempVector, and have temp vectors be an instance of TempVector instead of Array. Then the VM could easily check is an object is a temp vector and fail the become primitive or the setImmutability primitive.
>
> I think this should be exposed in the image. It would mean having the TempVector class in the special object array.
>
> What do you think ?
>
> Clement
>

Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Levente Uzonyi-2
In reply to this post by Clément Béra
 
Wouldn't it be a better solution to change #tempAt: to return the wrapped
object instead of the temp vector?

Levente
Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Levente Uzonyi-2
 
I checked how the implementation actually works, and I came to the
conclusion that using a separate class might be a good idea, because
there's no easy way to tell if an Array returned by #tempAt: is a temp
vector with some temporaries or just a regular array in a temporary
variable. This means that returning the wrapped objects would
probably require a lot more changes.

I'd still refrain from the additional changes which would introduce some
overhead in the methods you listed. Why?
For #become:, I understand the reason why you'd want it to add the check,
but there are so many other cases to handle (e.g.: "true become: false")
if you want to make #become: safer.
For immutability, I don't see the reason for the restriction. What if I,
as the programmer, want to do a little hack, and overwrite the value of a
temporary variable of a given block. That should work IMHO. So making the
array immutable is fine, making the user unable to make it mutable is
not.

Levente

On Sat, 21 Nov 2015, Levente Uzonyi wrote:

>
> Wouldn't it be a better solution to change #tempAt: to return the wrapped
> object instead of the temp vector?
>
> Levente
>
Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Clément Béra
 


2015-11-21 17:29 GMT+01:00 Levente Uzonyi <[hidden email]>:

I checked how the implementation actually works, and I came to the conclusion that using a separate class might be a good idea, because there's no easy way to tell if an Array returned by #tempAt: is a temp vector with some temporaries or just a regular array in a temporary variable. This means that returning the wrapped objects would probably require a lot more changes.

I'd still refrain from the additional changes which would introduce some overhead in the methods you listed. Why?
For #become:, I understand the reason why you'd want it to add the check, but there are so many other cases to handle (e.g.: "true become: false") if you want to make #become: safer.
For immutability, I don't see the reason for the restriction. What if I, as the programmer, want to do a little hack, and overwrite the value of a temporary variable of a given block. That should work IMHO. So making the array immutable is fine, making the user unable to make it mutable is not.

Well the problem is that if you make a temp vector immutable, remote temp accessing use unchecked temp vector access that mutate the temp vector even if it is immutable. So basically at:put: would fail on the temp vector but access though the remote temp bytecode would still mutate it.
 


Levente


On Sat, 21 Nov 2015, Levente Uzonyi wrote:


Wouldn't it be a better solution to change #tempAt: to return the wrapped object instead of the temp vector?

Levente


Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

stephane ducasse-2
In reply to this post by Levente Uzonyi-2


On 21 Nov 2015, at 17:29, Levente Uzonyi <[hidden email]> wrote:

> I checked how the implementation actually works, and I came to the conclusion that using a separate class might be a good idea, because there's no easy way to tell if an Array returned by #tempAt: is a temp vector with some temporaries or just a regular array in a temporary variable. This means that returning the wrapped objects would probably require a lot more changes.
>
> I'd still refrain from the additional changes which would introduce some overhead in the methods you listed. Why?
> For #become:, I understand the reason why you'd want it to add the check, but there are so many other cases to handle (e.g.: "true become: false") if you want to make #become: safer.
> For immutability, I don't see the reason for the restriction. What if I, as the programmer, want to do a little hack, and overwrite the value of a temporary variable of a given block. That should work IMHO. So making the array immutable is fine, making the user unable to make it mutable is not.

I think that a language implementation should support reasonable extensions with good reason (I do not see a good scenario for overwriting the value of a temp in a block - do you have a real example in mind) and language implementors should get space for optimisation.

>
> Levente
>
> On Sat, 21 Nov 2015, Levente Uzonyi wrote:
>
>>
>> Wouldn't it be a better solution to change #tempAt: to return the wrapped object instead of the temp vector?
>>
>> Levente
>>

Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Levente Uzonyi-2
 
On Sat, 21 Nov 2015, stephane ducasse wrote:

>
>
> On 21 Nov 2015, at 17:29, Levente Uzonyi <[hidden email]> wrote:
>
>> I checked how the implementation actually works, and I came to the conclusion that using a separate class might be a good idea, because there's no easy way to tell if an Array returned by #tempAt: is a temp vector with some temporaries or just a regular array in a temporary variable. This means that returning the wrapped objects would probably require a lot more changes.
>>
>> I'd still refrain from the additional changes which would introduce some overhead in the methods you listed. Why?
>> For #become:, I understand the reason why you'd want it to add the check, but there are so many other cases to handle (e.g.: "true become: false") if you want to make #become: safer.
>> For immutability, I don't see the reason for the restriction. What if I, as the programmer, want to do a little hack, and overwrite the value of a temporary variable of a given block. That should work IMHO. So making the array immutable is fine, making the user unable to make it mutable is not.
>
> I think that a language implementation should support reasonable extensions with good reason (I do not see a good scenario for overwriting the value of a temp in a block - do you have a real example in mind) and language implementors should get space for optimisation.

>From the debugger you can change the value of all variables, including
temporaries, which should stay that way.
What Clement suggest would make the VM slower, not faster, due to the
additional checks.

Levente

>
>>
>> Levente
>>
>> On Sat, 21 Nov 2015, Levente Uzonyi wrote:
>>
>>>
>>> Wouldn't it be a better solution to change #tempAt: to return the wrapped object instead of the temp vector?
>>>
>>> Levente
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Having a specific class for temp vectors

Levente Uzonyi-2
In reply to this post by Clément Béra
 
On Sat, 21 Nov 2015, Clément Bera wrote:

> Well the problem is that if you make a temp vector immutable, remote
temp accessing use unchecked temp vector access that mutate the temp
vector even if it is immutable. So basically at:put: would fail on the
temp vector but access though the remote temp bytecode
would still mutate it.

I've misunderstood your original proposal about immutability. You don't
want to let the programmer be able to make a temp vectors immutable, and
that's acceptable.

Levente