The subject says it all. Does Self have the equivalent of "become:"?
Michael
On Monday 21 June 2004 21:31, Michael Latta wrote:
The subject says it all. Does Self have the equivalent of "become:"?
No, but it doesn't really need it. Note that there are two different flavors of #become: in the Smalltalk world - the swapping version and the forwarding version (if that is the right term).
The equivalent of the non-swapping version can easily (but not efficiently) done as
a _RemoveAllSlots. a _AddSlots: b.
The swapping version is just a little more complicated.
-- Jecel
However, that solution masks the fact that the _AddSlots: call may require the automatic memory allocator to re-allocate the object and perform pointer forwarding (through tables, or whatever).
At least in Squeak, the implementation I'm most familiar with, become:/becomeForward: are just re-using that machinery; perhaps wrongly, since calls to those force GC's, but that seems to be a Squeak quirk rather than a general logical condition. I don't mind exposing that functionality, being an open-implementation proponent, at least at a meta-level.
In any case, this kind of idiom is certainly needed, it's just a question of whether to expose VM functionality or re-create it via combining other primitives in a library method.
On Jun 21, 2004, at 5:55 PM, Jecel Assumpcao Jr wrote:
On Monday 21 June 2004 21:31, Michael Latta wrote:
The subject says it all. Does Self have the equivalent of "become:"?
No, but it doesn't really need it. Note that there are two different flavors of #become: in the Smalltalk world - the swapping version and the forwarding version (if that is the right term).
The equivalent of the non-swapping version can easily (but not efficiently) done as
a _RemoveAllSlots. a _AddSlots: b.The swapping version is just a little more complicated.
-- Brian T. Rice LOGOS Research and Development http://tunes.org/~water/
On Tuesday 22 June 2004 02:43, Brian Rice wrote:
However, that solution masks the fact that the _AddSlots: call may require the automatic memory allocator to re-allocate the object and perform pointer forwarding (through tables, or whatever).
This, and the other stuff you wrote, are very good points.
Without checking the VM sources, my guess is that _AddSlots: scans through the whole memory updating all pointers to the changed object. This was a key decision in the object memory design - that the heap(s) should be scanned word by word instead of object by object and field by field within the object.
This works very well with everything in RAM, but like #allInstances and friends from Smalltalk it doesn't like virtual memory.
-- Jecel
If you are scanning memory, I hope you are avoiding byte arrays! I also assume you catch references on the stack and in registers.
Michael
On Jun 22, 2004, at 7:25 AM, Jecel Assumpcao Jr wrote:
On Tuesday 22 June 2004 02:43, Brian Rice wrote:
However, that solution masks the fact that the _AddSlots: call may require the automatic memory allocator to re-allocate the object and perform pointer forwarding (through tables, or whatever).
This, and the other stuff you wrote, are very good points.
Without checking the VM sources, my guess is that _AddSlots: scans through the whole memory updating all pointers to the changed object. This was a key decision in the object memory design - that the heap(s) should be scanned word by word instead of object by object and field by field within the object.
This works very well with everything in RAM, but like #allInstances and friends from Smalltalk it doesn't like virtual memory.
-- Jecel
Yahoo! Groups Links
On Tuesday 22 June 2004 13:49, Michael Latta wrote:
If you are scanning memory, I hope you are avoiding byte arrays! I also assume you catch references on the stack and in registers.
It is very educational to turn on the spy (see option in the yellow background menu) and watch it as Self runs.
You will notice that each region fills up from the left (lower addresses) and from the right at the same time. On the left you have objects with pointer (which should be scanned) and on the right the byte arrays (which shouldn't, as you said).
Scanning the registers and stack is more complicated due to a mix of tagged and raw objects, but each method includes a mask to tell you which is which. The details vary slightly from processor to processor.
-- Jecel
Michael,
Yes it does. The _Define primitive, and better yet, the mirror define protocol. Do a find slots of *efine* starting with any mirror. Please forward this to the yahoo list, as I usually cannot get through to it.
Thank you,
- david
On Jun 21, 2004, at 5:31 PM, Michael Latta wrote:
The subject says it all. Does Self have the equivalent of "become:"?
Michael
Yahoo! Groups Links
self-interest@lists.selflanguage.org
-
Brian Rice -
David Ungar -
Jecel Assumpcao Jr -
Michael Latta