| newNil | newNil := UndefinedObject basicNew. nil becomeForward: newNil. (Array new: 1) first == newNil
In Cog it just hangs VM (under Mac)
Any ideas how to fix that?
On Mon, Dec 13, 2010 at 6:14 AM, Igor Stasenko siguctua@gmail.com wrote:
| newNil | newNil := UndefinedObject basicNew. nil becomeForward: newNil. (Array new: 1) first == newNil
In Cog it just hangs VM (under Mac)
Any ideas how to fix that?
I don't think it's worth fixing. It is advantageous for the performance of the VM to be able to embed nil in machine code without needing to mark it as a GCable object, and nil doesn't really have to change. Instead you can change the UndefinedObject class via a become. So for me it's not worth fixing and in fact I would actively encourage expecting /not/ to be able to redefine nil, true or false. For example in Cog better code is generated for conditional branches by assuming that true and false are contiguous (in current images 8 bytes apart). IMO, there are flexibilities that are so unusual they are not worth paying for, and being able to become nil, true and false are in this category.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
On 13 December 2010 20:21, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Dec 13, 2010 at 6:14 AM, Igor Stasenko siguctua@gmail.com wrote:
| newNil | newNil := UndefinedObject basicNew. nil becomeForward: newNil. (Array new: 1) first == newNil
In Cog it just hangs VM (under Mac)
Any ideas how to fix that?
I don't think it's worth fixing. It is advantageous for the performance of the VM to be able to embed nil in machine code without needing to mark it as a GCable object, and nil doesn't really have to change. Instead you can change the UndefinedObject class via a become. So for me it's not worth fixing and in fact I would actively encourage expecting /not/ to be able to redefine nil, true or false. For example in Cog better code is generated for conditional branches by assuming that true and false are contiguous (in current images 8 bytes apart). IMO, there are flexibilities that are so unusual they are not worth paying for, and being able to become nil, true and false are in this category.
I agree its not worth changing. So, the 'fix' is to replace the class, since nil is singleton anyways.
The problem i that we want to swap special objects array. And there are two approaches:
1 - create a full object memory , which is a copy of existing objects (but not everything, just selected pieces). This means that there will be two 'nils' and therefore need a working #become: for swapping.
2 - mark a set of objects for inclusion in 'new' image, and throw away the rest via stubbing. So, this approach avoids copying, but also it doesn't allows to hold two object memories in object memory at same time (host and baby one).
I advocating for a second approach. It is more simpler as to me, but at same time, it is only one way road. While with first one, potentially you could switch between two object memories at will , which opening interesting possibilities.
Btw, are there any other objects which can't freely use #become: due to some Cog intrinsics?
best Eliot
On 12/13/2010 11:52 AM, Igor Stasenko wrote:
The problem i that we want to swap special objects array. And there are two approaches:
1 - create a full object memory , which is a copy of existing objects (but not everything, just selected pieces). This means that there will be two 'nils' and therefore need a working #become: for swapping.
2 - mark a set of objects for inclusion in 'new' image, and throw away the rest via stubbing. So, this approach avoids copying, but also it doesn't allows to hold two object memories in object memory at same time (host and baby one).
There are at least two more options:
(3) Write a primitive that replaces the special objects array and includes a set of classes to be updated (this would include all the literals).
(4) A variant on the above would make all these classes be compact and have them switch implicitly by replacing the compact classes array in the splObjs.
Cheers, - Andreas
On Mon, Dec 13, 2010 at 12:01 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 12/13/2010 11:52 AM, Igor Stasenko wrote:
The problem i that we want to swap special objects array. And there are two approaches:
1 - create a full object memory , which is a copy of existing objects (but not everything, just selected pieces). This means that there will be two 'nils' and therefore need a working #become: for swapping.
2 - mark a set of objects for inclusion in 'new' image, and throw away the rest via stubbing. So, this approach avoids copying, but also it doesn't allows to hold two object memories in object memory at same time (host and baby one).
There are at least two more options:
(3) Write a primitive that replaces the special objects array and includes a set of classes to be updated (this would include all the literals).
which would give Cog the opportunity to void its code cache, hence avoiding its limitations w.r.t. nil true false and the character table.
good approach
(4) A variant on the above would make all these classes be compact and have them switch implicitly by replacing the compact classes array in the splObjs.
yes; as long as this is primitive Cog can intercept and react apropriately.
cheers Eliot
Cheers,
- Andreas
On 13 December 2010 21:30, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Dec 13, 2010 at 12:01 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 12/13/2010 11:52 AM, Igor Stasenko wrote:
The problem i that we want to swap special objects array. And there are two approaches:
1 - create a full object memory , which is a copy of existing objects (but not everything, just selected pieces). This means that there will be two 'nils' and therefore need a working #become: for swapping.
2 - mark a set of objects for inclusion in 'new' image, and throw away the rest via stubbing. So, this approach avoids copying, but also it doesn't allows to hold two object memories in object memory at same time (host and baby one).
There are at least two more options:
(3) Write a primitive that replaces the special objects array and includes a set of classes to be updated (this would include all the literals).
which would give Cog the opportunity to void its code cache, hence avoiding its limitations w.r.t. nil true false and the character table. good approach
Yep. But this requires modifying VM, which guys trying to avoid right now.
@Benjamin, i hope you watching this thread. It would be good if you leave a comment(s) , because i don't know much details about it and your current needs. And only want to help.
On Mon, Dec 13, 2010 at 11:52 AM, Igor Stasenko siguctua@gmail.com wrote:
On 13 December 2010 20:21, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Dec 13, 2010 at 6:14 AM, Igor Stasenko siguctua@gmail.com
wrote:
| newNil | newNil := UndefinedObject basicNew. nil becomeForward: newNil. (Array new: 1) first == newNil
In Cog it just hangs VM (under Mac)
Any ideas how to fix that?
I don't think it's worth fixing. It is advantageous for the performance
of the VM to be able to embed nil in machine code without needing to mark it as a GCable object, and nil doesn't really have to change. Instead you can change the UndefinedObject class via a become. So for me it's not worth fixing and in fact I would actively encourage expecting /not/ to be able to redefine nil, true or false. For example in Cog better code is generated for conditional branches by assuming that true and false are contiguous (in current images 8 bytes apart). IMO, there are flexibilities that are so unusual they are not worth paying for, and being able to become nil, true and false are in this category.
I agree its not worth changing. So, the 'fix' is to replace the class, since nil is singleton anyways.
The problem i that we want to swap special objects array. And there are two approaches:
1 - create a full object memory , which is a copy of existing objects (but not everything, just selected pieces). This means that there will be two 'nils' and therefore need a working #become: for swapping.
2 - mark a set of objects for inclusion in 'new' image, and throw away the rest via stubbing. So, this approach avoids copying, but also it doesn't allows to hold two object memories in object memory at same time (host and baby one).
Is this for the kernel project? If so, what are the requirements? When I looked at MicroSqueak one thing I couldn't come up with a good answer for was how to deal with nil, true and false while simulating MicroSqueak code in the image. One could e.g. modify the compiler to generate references to the MicroSqueak nil, true and false but then conditional branch opcodes can't be used, so one would e.g. have to simulate the bytecode. That shouldn't be too much of a problem because there shouldn't be that much code to execute. But if e.g. method wrappers could be used that would be nicer.
I advocating for a second approach. It is more simpler as to me, but at same time, it is only one way road. While with first one, potentially you could switch between two object memories at will , which opening interesting possibilities.
Btw, are there any other objects which can't freely use #become: due to some Cog intrinsics?
nil, true, false are it AFAIA. However one can't change the characterTable. One can become it, or replace its contents, but one can't assign a new array to the specialObjectsArray and expect it to continue working.
HTH Eliot
best Eliot
-- Best regards, Igor Stasenko AKA sig.
vm-dev@lists.squeakfoundation.org