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
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
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 leves@elte.hu:
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
Wouldn't it be a better solution to change #tempAt: to return the wrapped object instead of the temp vector?
Levente
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
2015-11-21 17:29 GMT+01:00 Levente Uzonyi leves@elte.hu:
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
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
On 21 Nov 2015, at 17:29, Levente Uzonyi leves@elte.hu 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
On Sat, 21 Nov 2015, stephane ducasse wrote:
On 21 Nov 2015, at 17:29, Levente Uzonyi leves@elte.hu 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
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 bera.clement@gmail.com 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
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Levente Uzonyi -
stephane ducasse